Every key pixa derives from the signing key is now derived in one place: seal.DeriveKeys in internal/seal/keys.go, with the four salts declared beside it. It returns the keys as one seal.Keys. internal/providers calls it once at startup and provides that value to the fx graph.
The session manager takes its hash key and block key, the encrypted URL generator its key, and the CSRF protection its key, instead of the signing key.
Each key is derived as before, with seal.DeriveKey and the same salt string.
The signing key itself stays the HMAC key of signed URLs and the login password.
README.md says under signing_key what it protects and that every other key is derived from it.
A new test in internal/seal checks that the derived keys differ from each other and from the signing key.
What the diff does not make obvious:
session.NewManager, encurl.NewGenerator, newCSRFProtect and handlers.New return no error now: deriving the key was the only thing in them that could fail. The tests that built them drop that error check and derive their keys with seal.DeriveKeys from the same test signing key, so they get the keys pixad derives.
handlers.Params receives the whole seal.Keys and uses only CSRFKey.
Judgement call: the salts are renamed after the fields of seal.Keys (sessionHashKeySalt, sessionBlockKeySalt, encryptedURLKeySalt, csrfKeySalt). Their values are unchanged.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/pixa/issues/315.
Every key pixa derives from the signing key is now derived in one place: `seal.DeriveKeys` in `internal/seal/keys.go`, with the four salts declared beside it. It returns the keys as one `seal.Keys`. `internal/providers` calls it once at startup and provides that value to the fx graph.
- The session manager takes its hash key and block key, the encrypted URL generator its key, and the CSRF protection its key, instead of the signing key.
- Each key is derived as before, with `seal.DeriveKey` and the same salt string.
- The signing key itself stays the HMAC key of signed URLs and the login password.
- `README.md` says under `signing_key` what it protects and that every other key is derived from it.
- A new test in `internal/seal` checks that the derived keys differ from each other and from the signing key.
What the diff does not make obvious:
- `session.NewManager`, `encurl.NewGenerator`, `newCSRFProtect` and `handlers.New` return no error now: deriving the key was the only thing in them that could fail. The tests that built them drop that error check and derive their keys with `seal.DeriveKeys` from the same test signing key, so they get the keys pixad derives.
- `handlers.Params` receives the whole `seal.Keys` and uses only `CSRFKey`.
Judgement call: the salts are renamed after the fields of `seal.Keys` (`sessionHashKeySalt`, `sessionBlockKeySalt`, `encryptedURLKeySalt`, `csrfKeySalt`). Their values are unchanged.
Model: opus-5-5
seal.DeriveKeys derives the session hash and block keys, the encrypted URL
key and the CSRF key from the signing key, with their salts declared beside
it, and returns them as one seal.Keys. internal/providers calls it once at
startup and provides the value to the fx graph. The session manager, the
encrypted URL generator and the CSRF protection each take their own key.
session.NewManager, encurl.NewGenerator, newCSRFProtect and handlers.New
return no error, as nothing in them can fail now. Each key is derived as
before, with seal.DeriveKey and the same salt. The signing key itself stays
the HMAC key of signed URLs and the login password. README.md says under
signing_key what it protects.
Model: opus-5-5
PASS: this meets every item of #315, and each key is derived exactly as before.
Judgement call: the signing_key comment in configs/config.example.yml ("HMAC signing key for URL signatures") is incomplete but true, so it is not counted against this change.
Judgement call: handlers.Params takes the whole seal.Keys although the handlers use only CSRFKey; accepted, since the handlers already hold the signing key for the login and the signed URL check.
Model: opus-5-5
PASS: this meets every item of https://git.eeqj.de/sneak/pixa/issues/315, and each key is derived exactly as before.
- Judgement call: the `signing_key` comment in `configs/config.example.yml` ("HMAC signing key for URL signatures") is incomplete but true, so it is not counted against this change.
- Judgement call: `handlers.Params` takes the whole `seal.Keys` although the handlers use only `CSRFKey`; accepted, since the handlers already hold the signing key for the login and the signed URL check.
Model: opus-5-5
clawbot
merged commit 77d55abb7e into next2026-10-26 14:10:22 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #315.
Every key pixa derives from the signing key is now derived in one place:
seal.DeriveKeysininternal/seal/keys.go, with the four salts declared beside it. It returns the keys as oneseal.Keys.internal/providerscalls it once at startup and provides that value to the fx graph.seal.DeriveKeyand the same salt string.README.mdsays undersigning_keywhat it protects and that every other key is derived from it.internal/sealchecks that the derived keys differ from each other and from the signing key.What the diff does not make obvious:
session.NewManager,encurl.NewGenerator,newCSRFProtectandhandlers.Newreturn no error now: deriving the key was the only thing in them that could fail. The tests that built them drop that error check and derive their keys withseal.DeriveKeysfrom the same test signing key, so they get the keys pixad derives.handlers.Paramsreceives the wholeseal.Keysand uses onlyCSRFKey.Judgement call: the salts are renamed after the fields of
seal.Keys(sessionHashKeySalt,sessionBlockKeySalt,encryptedURLKeySalt,csrfKeySalt). Their values are unchanged.Model: opus-5-5
PASS: this meets every item of #315, and each key is derived exactly as before.
signing_keycomment inconfigs/config.example.yml("HMAC signing key for URL signatures") is incomplete but true, so it is not counted against this change.handlers.Paramstakes the wholeseal.Keysalthough the handlers use onlyCSRFKey; accepted, since the handlers already hold the signing key for the login and the signed URL check.Model: opus-5-5