Plain-language summary: Four of five Harbor clients encrypt attached files when you encrypt a
note. The CLI does not — and the CLI is the tool we tell people to run to fix notes that saved as
plaintext.
Found by the investigation on #1260.
| Client |
Re-encrypts attachment bytes on seal? |
| Web |
Yes — web/src/lib/notes/sealNote.ts:90 |
| macOS / iOS |
Yes — HarborCore/Sources/HarborBlobs/AttachmentReencryptor.swift |
| Android |
Yes — app/src/main/java/my/harbor/app/crypto/NoteMove.kt |
| Windows |
Yes — HarborCore/Crypto/AttachmentReencryptor.cs |
| CLI |
No — cmd/notes_convert.go:552 |
The CLI's own help is honest about it: "It does not encrypt the BYTES of attached files… the
attachments themselves are stored as they were, and can still be downloaded and read in full."
That warning is a stopgap, not a fix — and it is on the command we recommend as the remedy for
harbor-swift#817, harbor-android#236, harbor-windows#221 and harbor-webclipper#91.
Note this is not a design question. The HRBC2 envelope, the client-side pipeline and the
server's POST /notes/:id/attachments/swap endpoint all exist and ship in four clients. This is a
coverage gap on one.
What to do
Implement download → wrap in HRBC2 → re-upload under the new hash → rewrite refs → call the swap
endpoint, matching what the other four clients do. Or, if that is too large for now, make
harbor notes encrypt refuse a note that has attachments and say why — a refusal is honest,
a silent partial seal is not.
Say which you chose and why in the PR.
Acceptance criteria
Related
- #1260 (investigation) · app.harbor.my#1277 (server-side fix that closes the search leak for the
CLI too — but the file bytes stay readable until this ships)
Plain-language summary: Four of five Harbor clients encrypt attached files when you encrypt a
note. The CLI does not — and the CLI is the tool we tell people to run to fix notes that saved as
plaintext.
Found by the investigation on #1260.
web/src/lib/notes/sealNote.ts:90HarborCore/Sources/HarborBlobs/AttachmentReencryptor.swiftapp/src/main/java/my/harbor/app/crypto/NoteMove.ktHarborCore/Crypto/AttachmentReencryptor.cscmd/notes_convert.go:552The CLI's own help is honest about it: "It does not encrypt the BYTES of attached files… the
attachments themselves are stored as they were, and can still be downloaded and read in full."
That warning is a stopgap, not a fix — and it is on the command we recommend as the remedy for
harbor-swift#817,harbor-android#236,harbor-windows#221andharbor-webclipper#91.Note this is not a design question. The HRBC2 envelope, the client-side pipeline and the
server's
POST /notes/:id/attachments/swapendpoint all exist and ship in four clients. This is acoverage gap on one.
What to do
Implement download → wrap in HRBC2 → re-upload under the new hash → rewrite refs → call the swap
endpoint, matching what the other four clients do. Or, if that is too large for now, make
harbor notes encryptrefuse a note that has attachments and say why — a refusal is honest,a silent partial seal is not.
Say which you chose and why in the PR.
Acceptance criteria
attachments with a clear message. No third option.
--helptext matches the new behaviour — the current warning must not outlive it.Related
CLI too — but the file bytes stay readable until this ships)