A secret mv between vaults unlocks both vaults before taking the lock (closes #189)
check / check (push) Waiting to run

A move between two vaults unlocked them while holding the state directory
lock, and unlocking can ask for a passphrase, so every other changing
command waited at that prompt. moveSecretCrossVault now checks the move,
refusing an existing destination secret without --force, unlocks both
vaults, and only then takes the lock. Under the lock, it checks that the
destination vault still has the long-term key it unlocked, and
copySecretAndRemoveSource checks the move again before it copies. A move
within a vault takes the lock in moveSecretWithinVault, so MoveSecret
takes none itself. The error for a vault created again with another key,
shared with secret unlocker add, now ends "nothing was changed".

Model: opus-5-5
This commit was merged in pull request #190.
This commit is contained in:
2026-10-15 10:49:06 +02:00
parent fac2753819
commit 4c47b233bb
4 changed files with 318 additions and 71 deletions
+5 -4
View File
@@ -440,10 +440,11 @@ in a CI job, the command fails and names the variable to set.
A command that changes anything locks the state directory, through its file
`lock`, and another such command waits until the lock is released.
`secret init`, `secret vault create`, `secret unlocker add`, and `secret add`,
`secret import` and `secret generate secret` with `--force`, ask for the
mnemonic or passphrase before they take the lock, so a prompt of theirs left
open in one terminal holds up no command in another.
`secret init`, `secret vault create`, `secret unlocker add`, `secret mv` from
one vault to another, and `secret add`, `secret import` and
`secret generate secret` with `--force`, ask for the mnemonic or passphrase
before they take the lock, so a prompt of theirs left open in one terminal holds
up no command in another.
## Security Features