Password-only shares must not exist: protection is key-in-link, optionally + password #274

New issue

Closed

opened 2026-08-18 19:45:47 +00:00 by Cordy · 0 comments

Cordy commented

2026-08-18 19:45:47 +00:00

Owner

Decision (2026-08-18, follow-up to #269/#273)

The v0.6.44 dialog hotfix exposed a model problem: hiding the password field in key-in-link mode made the layered key+password share (v0.6.42) uncreatable, while "Password (sent separately)" mode still created password-only shares — where the password is the sole protection AND the key material.

Ruling: a password-only protection level should never even be possible. Every share link is key-in-link; a password, when set, is always an additional gate on top of the key. The Protection concept collapses from a mode choice into a single optional layer.

Changes

Dialog: the Protection select is gone. The dialog shows the key-in-link explanation and an "Also require a password" checkbox that reveals the Password field. The forced-password org policy pre-checks and locks the checkbox.
API: POST /api/v1/shares no longer creates password-mode shares — mode: "password" (and the legacy inference from a bare password) coerces to fragment with the password kept as the layer, so older clients still get a working, stronger link. "plain" stays as the policy-gated legacy escape hatch.
Serving: existing password-mode shares in the state remain served by the viewer unchanged (the passphrase is their key material; revoking/expiring retires them naturally).

Acceptance

No UI path creates a share whose only protection is a password.
Key-in-link + "Also require a password" creates the layered share (key fragment in URL, password gate first — #271 locked viewer flow).
API mode:"password" requests produce layered fragment shares, not password-only ones.
Pre-existing password-mode share links keep opening.

## Decision (2026-08-18, follow-up to #269/#273) The v0.6.44 dialog hotfix exposed a model problem: hiding the password field in key-in-link mode made the layered key+password share (v0.6.42) uncreatable, while "Password (sent separately)" mode still created **password-only** shares — where the password is the sole protection AND the key material. Ruling: **a password-only protection level should never even be possible.** Every share link is key-in-link; a password, when set, is always an *additional* gate on top of the key. The Protection concept collapses from a mode choice into a single optional layer. ## Changes - **Dialog**: the Protection select is gone. The dialog shows the key-in-link explanation and an "Also require a password" checkbox that reveals the Password field. The forced-password org policy pre-checks and locks the checkbox. - **API**: `POST /api/v1/shares` no longer creates password-mode shares — `mode: "password"` (and the legacy inference from a bare password) coerces to fragment with the password kept as the layer, so older clients still get a working, *stronger* link. `"plain"` stays as the policy-gated legacy escape hatch. - **Serving**: existing password-mode shares in the state remain served by the viewer unchanged (the passphrase is their key material; revoking/expiring retires them naturally). ## Acceptance 1. No UI path creates a share whose only protection is a password. 2. Key-in-link + "Also require a password" creates the layered share (key fragment in URL, password gate first — #271 locked viewer flow). 3. API `mode:"password"` requests produce layered fragment shares, not password-only ones. 4. Pre-existing password-mode share links keep opening.