Skip to content

docs: tweaks the ingress docs to have headings - #105

Merged
ChrisJBurns merged 1 commit into
mainfrom
tweak-ingress-docs
Apr 7, 2025
Merged

ChrisJBurns merged 1 commit into
mainfrom
tweak-ingress-docs

Conversation

@ChrisJBurns

Copy link
Copy Markdown
Collaborator

.. and lovely shell syntax highlighting :)

.. and lovely shell syntax highlighting :)

Signed-off-by: ChrisJBurns <29541485+ChrisJBurns@users.noreply.github.com>
@ChrisJBurns
ChrisJBurns merged commit 59eb14e into main Apr 7, 2025
@ChrisJBurns
ChrisJBurns deleted the tweak-ingress-docs branch April 7, 2025 14:11
rdimitrov added a commit that referenced this pull request Sep 14, 2026
* Derive secrets encryption key with Argon2id

The encrypted secrets provider derived its AES-256-GCM key from the user's
password with a single unsalted SHA-256. That password is human-chosen and
doubles as a recovery credential, so an attacker holding a copy of the
secrets file could try billions of guesses per second against it. The file
travels in ways the OS keyring does not — backups, disk images, synced home
directories — which is exactly the case this protects.

Derive the key with Argon2id and a per-file random salt instead. The salt
goes in a new file header; the cost parameters stay in code, selected by the
header's format version, so nothing attacker-controllable reaches Argon2id's
memory allocation.

Files written before the header existed are detected by the absent magic
prefix, read with the old key, and rewritten on open. Migrating on open
rather than on the next write matters: a file that is only ever read would
otherwise keep the weaker derivation indefinitely, which is the common case
for workload credential injection.

Derivation is memoised for the process. A provider is constructed for nearly
every operation that touches a secret, including once per API request, and
Argon2id is deliberately expensive — without the memo the memory hardness
that protects the file at rest would become a denial of service vector
against the server.

A thv binary predating the header cannot read a migrated file.

Fixes CodeQL alert #105 (go/weak-sensitive-data-hashing)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Document upgrade, rollback and backup boundary

Review feedback on the Argon2id migration. The constructor's godoc did not
say that opening an existing store can rewrite it, nor that the password
argument is no longer a derived key — a caller still passing sha256(password)
compiles and then fails to decrypt.

The architecture doc gains the operational guidance the change actually
needs: stop older local thv processes before the first access with a new
binary, since migration happens on open and an older process loses secret
access afterwards; an older binary's "password is incorrect" hint does not
mean corruption, so resetting the keyring is the wrong first move; and
migration upgrades only the live file, so pre-migration backups stay
cheaply crackable and the password recovered from one still opens the
migrated file.

Add the two suggested tests: a failed migration leaves the legacy
ciphertext readable and untouched, and concurrent derivations through the
memo agree.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants