Item 9 of 15 of #168: "Derive every key from the one secret in one place". Starts when #314 is squash-merged to next.
Today (next at 989da78)
The signing key is the raw HMAC key in internal/signature, and goes through HKDF with four different salts in three places: internal/session/session.go (hashKeySalt, blockKeySalt), internal/encurl/encurl.go (urlKeySalt) and internal/handlers/csrf.go (csrfKeySalt). It is also the password compared on login. A newcomer finds out what the secret protects by searching for SigningKey.
Definition of done
One function in internal/seal, whose package comment already covers HKDF key derivation, derives each named key from the signing key once at startup, with the salts declared together beside it.
The session manager, the encrypted-URL generator and the CSRF protection each receive the derived key they need, not the signing key; hashKeySalt, blockKeySalt, urlKeySalt and csrfKeySalt are no longer declared in those packages.
The raw signing key stays the HMAC key for signed URLs, since README.md documents that algorithm for clients, and stays the login password.
README.md says in one place what the signing key protects and that the other keys are derived from it.
A test shows the derived keys differ from each other and from the signing key.
Approval and tests
sneak asked for each main recommendation of #168 to be its own issue, built before 1.0, one at a time in the order listed (#168 (comment)). That instruction is his approval of this item. Existing tests change only as this item needs: they follow code that moves or is renamed, and the tests of code this item removes go with it; no other assertion is weakened or dropped.
Model: opus-5-5
Item 9 of 15 of https://git.eeqj.de/sneak/pixa/issues/168: "Derive every key from the one secret in one place". Starts when https://git.eeqj.de/sneak/pixa/issues/314 is squash-merged to `next`.
## Today (`next` at `989da78`)
The signing key is the raw HMAC key in `internal/signature`, and goes through HKDF with four different salts in three places: `internal/session/session.go` (`hashKeySalt`, `blockKeySalt`), `internal/encurl/encurl.go` (`urlKeySalt`) and `internal/handlers/csrf.go` (`csrfKeySalt`). It is also the password compared on login. A newcomer finds out what the secret protects by searching for `SigningKey`.
## Definition of done
- One function in `internal/seal`, whose package comment already covers HKDF key derivation, derives each named key from the signing key once at startup, with the salts declared together beside it.
- The session manager, the encrypted-URL generator and the CSRF protection each receive the derived key they need, not the signing key; `hashKeySalt`, `blockKeySalt`, `urlKeySalt` and `csrfKeySalt` are no longer declared in those packages.
- The raw signing key stays the HMAC key for signed URLs, since `README.md` documents that algorithm for clients, and stays the login password.
- `README.md` says in one place what the signing key protects and that the other keys are derived from it.
- A test shows the derived keys differ from each other and from the signing key.
## Approval and tests
sneak asked for each main recommendation of https://git.eeqj.de/sneak/pixa/issues/168 to be its own issue, built before 1.0, one at a time in the order listed (https://git.eeqj.de/sneak/pixa/issues/168#issuecomment-153513). That instruction is his approval of this item. Existing tests change only as this item needs: they follow code that moves or is renamed, and the tests of code this item removes go with it; no other assertion is weakened or dropped.
Model: opus-5-5
clawbot
added this to the 1.0.0 milestone 2026-10-21 12:50:41 +02:00
clawbot
self-assigned this 2026-10-21 12:50:41 +02: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.
Item 9 of 15 of #168: "Derive every key from the one secret in one place". Starts when #314 is squash-merged to
next.Today (
nextat989da78)The signing key is the raw HMAC key in
internal/signature, and goes through HKDF with four different salts in three places:internal/session/session.go(hashKeySalt,blockKeySalt),internal/encurl/encurl.go(urlKeySalt) andinternal/handlers/csrf.go(csrfKeySalt). It is also the password compared on login. A newcomer finds out what the secret protects by searching forSigningKey.Definition of done
internal/seal, whose package comment already covers HKDF key derivation, derives each named key from the signing key once at startup, with the salts declared together beside it.hashKeySalt,blockKeySalt,urlKeySaltandcsrfKeySaltare no longer declared in those packages.README.mddocuments that algorithm for clients, and stays the login password.README.mdsays in one place what the signing key protects and that the other keys are derived from it.Approval and tests
sneak asked for each main recommendation of #168 to be its own issue, built before 1.0, one at a time in the order listed (#168 (comment)). That instruction is his approval of this item. Existing tests change only as this item needs: they follow code that moves or is renamed, and the tests of code this item removes go with it; no other assertion is weakened or dropped.
Model: opus-5-5