Blossom-Anhänge unterliegen nicht den Gruppenrechten

[usekaneo]

Sicherheitslücke, die durch die invite-only-Entscheidung (CON-22) scharf wird.

Nachgesehen am 2026-09-09: scripts/dev-blossom.mjs prüft die Autorisierung nur beim Upload (kind 24242, t=upload, Signatur über den Hash). Der Lesepfad GET /<sha256> hat keinerlei Prüfung — wer die URL oder den Hash kennt, lädt die Datei, ohne npub, ohne Mitgliedschaft, ohne AUTH.

Da die Anhang-URLs im Seitentext stehen, heißt das für einen privaten Space: der Text ist geschützt, die Bilder und Dateien sind es nicht. Blossom kennt das NIP-29-Gruppenmodell nicht.

Mögliche Wege, zu entscheiden:

1. Blossom-Server prüft beim GET eine Autorisierung (t=get, BUD-01 sieht das vor) und fragt die Mitgliedschaft beim Relay ab — bindet den Dateiserver an das Relay
2. Anhänge vor dem Upload verschlüsseln, Schlüssel im Revisionstext — schützt auch gegen den Betreiber des Dateiservers, macht Vorschaubilder und Verlinkung aber aufwendig
3. Bewusst akzeptieren und offen dokumentieren, dass Anhänge nicht dem Gruppenschutz unterliegen — vertretbar nur, wenn die UI beim Anhängen darauf hinweist

Betrifft auch den Produktivbetrieb: Für CON-4 muss klar sein, welcher Blossom-Server unter welchen Regeln läuft.

Betroffen: scripts/dev-blossom.mjs, src/nostr/blossom.ts, docs/09-security-privacy.md

---

_{Task: d6hwjvhykh50bgb3qfjlg010}

[usekaneo]

CON-26

[usekaneo]

**** commented:

Technical refinement (2026-09-12)

Scope: make Blossom attachments obey the NIP-29 group boundary for private spaces. This pins down what is actually broken, why the obvious fix does not work as-is, the options with their real cost, and a concrete plan. The route decision is still open — recommendation at the end.

1. Verified behaviour, and where

Upload path (scripts/dev-blossom.mjs:66-88) checks a BUD-01/BUD-11 token via checkAuth (:39-55): kind 24242, verifyEvent, t=upload, expiration, and x only if present (:51). It does not check created_at, server, or require x — the hash binding is optional today.

Read path (:90-108): no check at all. Whoever has the hash or URL gets the bytes — no npub, no membership, no AUTH. That is the hole.

No group association exists anywhere in the flow:

• The client's upload token carries only t, x, expiration (src/nostr/blossom.ts:47-56) — no h tag.
• The stored URL is bare http://host/<sha256> (:78); server-side there is only <hash> and <hash>.type (:77-78), no hash→group record.

Why "the URL is secret" is not a guarantee: a sha256 is derivable from content, so for any guessable file (a stock image, a template document) the hash is guessable too — and CORS is Access-Control-Allow-Origin: * on every response including GET (:26-31), so any origin can fetch it. For a private space the text is protected and every attachment in it is not. The docs name the gap (docs/04-permissions-nip29.md:117-119, docs/09-security-privacy.md:58-65); what is inconsistent is that it collides with the invite-only promise (docs/04:79-96).

2. Three hard constraints that shape any fix

2a. The read path cannot simply require a header. Browsers do not send Authorization on <img src> or <a href>. BUD-11 defines t=get for GET /<sha256>, and BUD-01 explicitly allows 401 there ("Authorization is required and missing or invalid. See BUD-11") — so a gated GET is spec-legal, but the moment it is gated, inline images stop rendering. Two ways out:

• the app fetches each blob with Authorization and renders an object URL — touches the two image sites (MarkdownImage in src/ui/Markdown.tsx, ImageWidget in src/ui/markdown-live.ts), plus link/download paths; or
• Blossom mints short-lived pre-signed URLs the app embeds. (A scoped t=get token in a query param is non-standard and leaks via logs/referrers; a minted path segment is preferable.)

2b. The Blossom server has no membership oracle it can use for free. 39002 is relay-signed and, for a private group, the relay silently filters unauthenticated readers and checks membership, not merely authentication (docs/04:98-110). A t=get token proves a pubkey signed something; it does not prove NIP-29 membership, and NIP-42 AUTH is challenge-bound to the relay connection and not transferable to another service. A per-space check therefore requires the Blossom server to authenticate to the relay with a key the relay accepts (a service member added to the group), or to have the media sit behind the relay so no second oracle is needed.

2c. BUD is a global sha256 namespace. The same bytes uploaded to two spaces are one blob (GET /<sha256>, no group in the path). Any per-space rule needs a hash→group mapping and a policy for a blob referenced from several spaces (union, or a per-space namespace).

3. Options and their real cost

Option 1 — enforce at the file boundary (recommended target).

• 1a. Own the ACL in the Blossom layer. Record hash → group(s) at upload (read h from the token; add it client-side), require t=get on GET, and answer membership by querying 39002 through a relay-authenticated connection held by a service identity. Client renders via fetch→object URL. Cost: small server check; medium client change (two image sites + link/download + object-URL cache); one service key that must be a member of every space (add it where groups are created/metadata edited — src/nostr/moderation.ts:98-133, addMember :135); and a real server for production, since the shipped script is dev-only — a stock Blossom server would need a thin authorizing proxy or a patch. (That is exactly CON-4's "which Blossom server runs under which rules".)
• 1b. Move media into the relay, the Buzz way. PUT /media/upload (BUD-02) and GET /media/{sha256}.{ext} (BUD-01) on the relay, community resolved from the host, #h checked against the host-derived community. No second oracle, no service key. Caveat measured from Buzz's own NOSTR.md: this is community scope, not channel scope — any member of the community can read any blob (private channel member lists are channel-scoped; media is not). Since our deployment is one relay = one company and spaces are groups, that is coarser than per-space. Real cost is CON-24: groups_relay (Rust) has no media endpoints and would have to be patched, or we move to buzz-relay (Go).

Option 2 — encrypt before upload. Key in the revision text. Removes the read-ACL problem and also protects against the file-server operator. Cost: every image is JS-decrypted (same client work as 1a), no inline <img> without a decrypted object URL, no range requests, key-in-text is a new format decision, and foreign Nostr clients can never render the images. Only worth it if the operator is not trusted — but docs/09:20-27 already accepts that the operator reads everything.

Option 3 — accept and document honestly. Cheapest; makes docs/09 and the attach UI truthful ("attachments are not covered by the group boundary"). Acceptable only as an explicit, labeled state, never as the shipped answer for invite-only spaces — it contradicts the reason CON-22 exists.

4. Recommendation

Target 1a (per-space ACL in the Blossom layer), because it preserves the per-space boundary the product promises, whereas 1b/Buzz is community-scoped. Sequence:

• Phase A (now, local): make scripts/dev-blossom.mjs enforce the read rule for real; add the h tag + hash→group sidecar; add the client fetch→object-URL path; tests. Makes the local system honest and gives the tests a target.
• Phase B (CON-4): decide the production file server. A stock Blossom server needs an authorizing proxy in front; if we adopt buzz-relay under CON-24, media moves inside the relay and the per-space check becomes community scope (a deliberate downgrade to record then).
• Interim if 1a ships later than the next release: ship option 3's wording (attach-time warning + docs) so nothing claims a guarantee it does not have.

5. Concrete work items

Server (scripts/dev-blossom.mjs)

• PUT /upload: require x (currently optional, :51); read h from the token and persist <hash>.group; reject uploads without a group once the rule is on.
• GET /<sha256> (:90-108): accept Authorization: Nostr <b64url> with t=get, validate x/server scoping, then check the requester against the group's 39002; 401 when the token is missing/invalid, 403 when the pubkey is not a member. Keep the GET /<sha256> root path (BUD-01).
• Note a BUD-11 detail: tokens are base64url without padding, while both current sides use standard base64 (btoa client-side, Buffer.from(..., 'base64') server-side). Fix both when the token becomes load-bearing.
• Hold a relay connection with the service identity and cache 39002 with a short TTL; document the NIP-42/AUTH flags (the private-group silent filtering that already bit us — AGENTS.md).
• Blob referenced from several spaces: store the group set; allow a read if the requester is a member of any referencing group.

Client (src/nostr/blossom.ts)

• Add ['h', groupId] (plus optional ['server', host]; x made mandatory by the server change) to the upload token; thread the group id from PageEditor.
• Add a fetch→object-URL helper used by MarkdownImage and ImageWidget; keep the stored Markdown as the plain URL (attachmentMarkdown, :103-110) so the format does not change.
• The read check lives server-side; the client only needs to send a valid t=get token signed with the same signer.

Docs: docs/09 (replace the "attachments are not covered" caveat with the implemented rule), docs/04:117-119, docs/02:31-41, NOSTR.md:75,95; docs/08/CON-4 for which server runs where.

6. Open questions to settle before coding

1. Scope: per-space or per-community? 1a = per-space; 1b/Buzz = per-community (any member of the relay reads any blob). Per-space is what "invite-only space" implies — confirm.
2. Service identity. Which key acts as the Blossom service member, who holds it, and is it auto-added to every new space (createGroupAndWait)? Losing it breaks all attachment reads.
3. Foreign hosts. A page can reference an image on any host (docs/09:45-65); those can never be protected. Should the attach UI warn when an attachment is not on our server?
4. Multi-space blobs — union, or namespace blobs per space (changes the URL shape and gives up dedup)?
5. Pre-signed URLs vs fetch→object URL for inline rendering. Fetch is simpler and needs no new URL scheme; pre-signed keeps native <img> but adds a minting endpoint and token lifetimes.

7. Acceptance

• A non-member (no token, or a valid t=get token from a non-member) gets 401/403 on GET /<sha256>; a member gets 200; a member of another space is denied under per-space scope.
• A private space's page renders its own attachments inline in the editor and read view through the new path; light/dark and resize behaviour unchanged.
• scripts/dev-blossom.mjs refuses an upload token without x/h, and the client always sends both.
• Unit tests: checkAuth (base64url, missing/wrong t, expired, x mismatch, server mismatch) and the membership decision (member / non-member / unknown group / unknown hash); a DOM test that MarkdownImage goes through the authenticated fetch.
• docs/09 no longer says attachments are outside the group boundary; if option 3 is chosen instead, it says so plainly and the attach UI warns.
• npm run typecheck && npm run lint && npm test && npm run build pass.

[usekaneo]

**** commented:

Implementation opened: PR #75 (branch con-26-attachment-group-rights, not merged).

Route taken: the refinement's option 1a — the group boundary is enforced in the Blossom layer, per space.

What landed:

• scripts/blossom-acl.mjs (BUD-11 token validation, unit-tested) and scripts/dev-blossom.mjs (upload files the blob under its h group and binds it by x; GET/HEAD requires a t=get token whose key is a member of the blob's group). Membership is queried from the relay's 39002 as a service identity; without one the server fails closed (--insecure-reads for the old behaviour).
• src/nostr/attachment-access.ts: the app signs the read token, fetches protected blobs and draws object URLs (<img src> cannot send Authorization). Foreign hosts unchanged.
• scripts/dev-group-seed.sh creates BLOSSOM_SEC and adds it to the group; VITE_BLOSSOM_SERVICE_PUBKEY is added when a space is created in the app.
• Docs 02/04/07/08/09/13 and NOSTR.md updated; docs/09 now states what is and is not covered, and points the production server decision at CON-4/CON-24.

Gates: typecheck, lint, test (239 files / 2226 tests) and build all pass. The read path was additionally smoke-tested (fail-closed without a service key, upload validation) and end-to-end verification against the live relay is in the PR's manual test plan.

[usekaneo]

**** commented:

UI test pass — 2026-09-16, PR #75, 73aad04

Tested against the running app (:5273) and scripts/dev-blossom.mjs --port 3355 --relay ws://localhost:8081, with four real identities: a group member, a signed-in non-member, a signed-out reader, and the Blossom service key. All cases pass. Merge-ready from the UI side. Two observations below that are worth a decision but do not block.

Two groups on the dev relay made the whole matrix reachable: engineering (private/closed/restricted) and signed-out-test (public/open). The public one is what allows the case the ticket describes — the page text is readable, the attachment is not.

Server (scripts/blossom-acl.mjs + dev-blossom.mjs)

Request	Result
upload token without x	401 an x tag is required ✓
upload token without h	400 the upload token carries no h tag (group) ✓
upload token without t	401 t tag must be "upload" ✓
upload, complete token	200 ✓
read, no Authorization	401 Authorization header is missing ✓
read, t=get token, non-member	403 not a member of this attachment's group ✓
read, t=get token, member	200 ✓
read, token with t=upload	401 t tag must be "get" ✓
read, server started without service key	503 no Blossom service identity configured… ✓
read, server started with --insecure-reads	200 without any token ✓

Both failure modes announce themselves at startup, loudly and in words:
reads are REFUSED: set BLOSSOM_SERVICE_NSEC (or add BLOSSOM_SEC to scripts/.dev-keys) and
READS ARE UNPROTECTED (--insecure-reads): anyone with the hash can fetch a blob.

Client

Case	Result
Member, image in the editor	loads as a blob: URL, naturalWidth 240 — the token fetch and object URL work while editing ✓
Member, image in the read view	same, blob: URL, image drawn ✓
Member, PDF link	click is intercepted; the outgoing fetch carries an Authorization header ✓
Foreign host image (upload.wikimedia.org)	plain https://… src, no token, loads normally ✓
Non-member, signed in, public page	page text renders; attachment request → 403; the <img> is left with no src ✓
Signed out, public page	page text renders; the <img> has no src, so no request is made at all ✓
Reload	every navigation re-signs a token, re-fetches and re-creates the object URL ✓

The #width fragment

The resize drag gesture itself could not be triggered in the test browser (the handle is display:none until .cm-md-image-selected, which needs a real caret placement). What the ticket actually turns on was verified directly instead:

• isProtectedAttachment and protectedHash return the same answer for …/<hash> and …/<hash>#width=120 — the fragment does not disturb blob identification.
• A page published with #width=120 stores it verbatim: the kind 1818 event on the relay reads ![mit breite](http://localhost:3355/a3a343…#width=120).
• In the read view that image loads as a blob: URL and is drawn at 120px with naturalWidth 240 — so the width is applied on the protected path, not just on foreign images.

Two observations

1. Upload does not check membership. A valid token with t, x and h uploads successfully under any group, whether or not the signer is a member — verified with a freshly generated key against h=engineering. The same key then gets 403 on reading it back, so this is storage abuse rather than disclosure, and the read boundary this ticket is about holds. Still: on a real deployment it lets any key fill the disk and file blobs under someone else's group. Worth naming explicitly in docs/09-security-privacy.md, or closing.

2. A blocked attachment is a silent gap. For a non-member or signed-out reader, the <img> renders with no src and only its alt. Nothing leaks and nothing is requested, which is the right failure — but the reader sees empty space where the author put a picture, with no hint that it is a permission boundary rather than a broken page. A short inline note ("attachment visible to members only") would cost little.

Testing note for whoever repeats this

A newly added member does not get through immediately: the relay's 39002 lags the 9000, and dev-blossom.mjs caches a negative membership answer for 5 seconds (a positive one for 30). A 403 right after nak group put-user means "wait a few seconds and retry", not a defect — it cost me one false alarm.

Not covered

The resize drag gesture (see above), and the interaction between a protected attachment and CON-44's CSP — connect-src there forbids http://localhost:3355, which is filed against CON-44.