vault create on an existing vault re-keys it, making every secret in it undecryptable #70

New Issue

2026-10-03T15:02:35+02:00

clawbot commented

2026-10-03 15:02:35 +02:00

secret vault create <name> does not check whether the vault already exists, and neither does secret init, which calls the same vault.CreateVault for default. Run against an existing vault, it takes the next free derivation index for the mnemonic (the vault's own index counts as taken), overwrites the vault's pub.age and vault-metadata.json with the new key, and the command then replaces its passphrase unlocker. The secrets already in the vault stay encrypted to the old key, so secret get fails for every one of them, with the mnemonic and with the unlocker. Nothing warns, and the command reports success.

Reproduced on next (d52b4f1) in an empty state directory with SB_SECRET_MNEMONIC and SB_UNLOCK_PASSPHRASE set: secret init; echo -n hunter2 | secret add db/pass; secret vault create default succeeds and moves the vault's derivation index from 0 to 1; secret get db/pass then fails with "no identity matched any of the recipients". The values can still be recovered by deriving the old index by hand, which the tool offers no way to do.

Suggested fix: vault.CreateVault refuses an existing vault directory, with a test that the existing vault's files are unchanged afterwards.

Model: opus-5-5

`secret vault create <name>` does not check whether the vault already exists, and neither does `secret init`, which calls the same `vault.CreateVault` for `default`. Run against an existing vault, it takes the next free derivation index for the mnemonic (the vault's own index counts as taken), overwrites the vault's `pub.age` and `vault-metadata.json` with the new key, and the command then replaces its passphrase unlocker. The secrets already in the vault stay encrypted to the old key, so `secret get` fails for every one of them, with the mnemonic and with the unlocker. Nothing warns, and the command reports success. Reproduced on `next` (`d52b4f1`) in an empty state directory with `SB_SECRET_MNEMONIC` and `SB_UNLOCK_PASSPHRASE` set: `secret init`; `echo -n hunter2 | secret add db/pass`; `secret vault create default` succeeds and moves the vault's derivation index from 0 to 1; `secret get db/pass` then fails with "no identity matched any of the recipients". The values can still be recovered by deriving the old index by hand, which the tool offers no way to do. Suggested fix: `vault.CreateVault` refuses an existing vault directory, with a test that the existing vault's files are unchanged afterwards. Model: opus-5-5

clawbot commented

2026-10-04 19:58:55 +02:00

Same defect as #74, fixed on next by #82: vault.CreateVault refuses an existing vault before writing anything, and a test shows the vault's files unchanged and its secrets still readable. Closing as a duplicate.

Model: opus-5-5

Same defect as https://git.eeqj.de/sneak/secret/issues/74, fixed on `next` by https://git.eeqj.de/sneak/secret/pulls/82: `vault.CreateVault` refuses an existing vault before writing anything, and a test shows the vault's files unchanged and its secrets still readable. Closing as a duplicate. Model: opus-5-5

clawbot closed this issue

2026-10-04 19:58:55 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/secret#70