Skip to content

feat(credentials): encrypt the vault at rest - #120

Closed
ralyodio wants to merge 1 commit into
fix/one-vault-xdgfrom
fix/vault-encrypted-at-rest
Closed

feat(credentials): encrypt the vault at rest#120
ralyodio wants to merge 1 commit into
fix/one-vault-xdgfrom
fix/vault-encrypted-at-rest

Conversation

@ralyodio

@ralyodio ralyodio commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

Stacked on #119. Base is fix/one-vault-xdg, so this diff shows only the encryption work. Merge #119 first and this retargets to master on its own.

Why

The vault holds the target's prior values so a bad rotation can be undone — the one place raw credentials touch disk. It was written as plain JSON:

{ "STRIPE_LIVE_KEY": "sk_live_…", "DATABASE_URL": "postgres://user:pass@…" }

…protected by nothing but mode 0600. A permission bit stops another user on the same box. It does nothing about a backup, a synced home directory, a lifted disk, or any process running as the owner — and those are precisely the cases where a credential store is worth reading.

What

Each run is sealed to this machine's identity:

  • fresh DEK per write, payload sealed with it
  • DEK sealed to the identity public key (crypto_box_seal)
  • opens with the secret key in identity.json and nothing else
{ "version": 2, "wrappedKey": "", "sealed": { "nonce": "", "ciphertext": "" } }

Key names go inside the ciphertext too. Knowing an endpoint holds STRIPE_LIVE_KEY is worth something on its own, so the whole bag is sealed, not just the values.

A DEK per run, not one per store. Reusing a key would make a single compromise open every rollback ever captured, and there is nothing to gain — the wrapped DEK travels in the file.

Compatibility

  • Plaintext vaults still open. Refusing them would strand the rollback data they exist to hold; a vault reader that cannot read yesterday's vault takes away the thing the vault is for. version: 2 distinguishes them.
  • The store's vault methods become async. All three callers were already inside async functions in engine.ts, so this is three awaits.
  • A missing identity gives a real error — "restore <path> to roll this run back" — rather than a decode failure out of libsodium. The operator needs to know the rollback is recoverable, and by restoring what.

The tradeoff, stated plainly

The vault is now only as recoverable as identity.json. Lose that file and old rollback data is unreadable. That is the point — it is what makes the file useless to anyone who copies it — but it does mean the identity key is now load-bearing for rollback, not just for team vault access. #119's migration exists partly so that key stops getting stranded in directories nobody knew about.

Tests

New src/vault-encryption.test.ts, 7 tests. Against the base commit, 3 fail — including the one that matters, "does not write the secret to disk in the clear". The other 4 are guards that must hold either way (round-trip, 0600, legacy plaintext, missing-vault).

plugin-credential-sharing 52 pass · cli 44 pass · npm run build:cli clean.

🤖 Generated with Claude Code

The vault holds the target's prior values so a bad rotation can be undone
— the one place raw credentials touch disk. It was written as plain JSON
at mode 0600, and a permission bit is all that was protecting it. That
stops another user on the same box. It does nothing about a backup, a
synced home directory, a lifted disk, or any process running as the
owner, and those are the cases where a credential store is worth reading.

Each run is now sealed to this machine's identity: a fresh DEK per write,
the payload sealed with it, the DEK sealed to the identity public key. So
the file opens with the secret key in identity.json and nothing else. The
key names go inside the ciphertext along with the values — knowing that
an endpoint holds STRIPE_LIVE_KEY is worth something by itself.

A DEK per run rather than one for the store: reusing a key would make a
single compromise open every rollback ever captured, and there is nothing
to gain by it, since the wrapped DEK travels in the file.

Plaintext vaults written before this still open. Refusing them would
strand the rollback data they exist to hold, and a vault reader that
cannot read yesterday's vault takes away the thing the vault is for.

The store's vault methods become async, which the three callers in the
engine already sat inside async functions to accommodate.

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

github-actions Bot commented Aug 1, 2026

Copy link
Copy Markdown

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.

@ralyodio
ralyodio deleted the branch fix/one-vault-xdg August 1, 2026 05:53
@ralyodio ralyodio closed this Aug 1, 2026
@ralyodio

ralyodio commented Aug 1, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #121 — this one was auto-closed when its base branch fix/one-vault-xdg was deleted on merging #119. Same commit, rebased onto master.

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.

1 participant