Ask for the mnemonic and passphrase before taking the state directory lock (closes #152)
check / check (push) Canceled after 0s
check / check (push) Canceled after 0s
init, vault create, unlocker add, and add, import and generate secret with --force asked for the mnemonic or passphrase, or unlocked the vault, while holding the state directory lock, so every other command that changes anything waited at the prompt. They now ask and unlock first and lock after. What they checked before asking is checked again under the lock: unlocker add fails if the vault was removed meanwhile and refuses a GPG key added meanwhile. A forced add of a secret that another command created meanwhile lets go of the lock, gets the key, and takes the lock again. secret.CreatePGPUnlocker now takes the vault, already unlocked; SetMnemonic and SetUnlockPassphrase, used only by it, are gone. Not done: secret move between vaults still unlocks both under the lock; the issue does not name it. Model: opus-5-5
This commit is contained in:
@@ -235,9 +235,9 @@ func processMnemonicForVault(
|
||||
// vault: one wrapping ErrInvalidVaultName when it is not a valid vault name,
|
||||
// and one wrapping ErrVaultExists when that vault already exists. Creating an
|
||||
// existing vault again would replace its keys, and its secrets could no
|
||||
// longer be decrypted. CreateVault checks this before writing anything; the
|
||||
// commands that create a vault also check it before they ask for the
|
||||
// mnemonic or passphrase, holding the state directory lock.
|
||||
// longer be decrypted. The commands that create a vault check it before they
|
||||
// ask for the mnemonic or passphrase, and CreateVault checks it again, under
|
||||
// the state directory lock, before writing anything.
|
||||
func CheckNewVaultName(fs afero.Fs, stateDir string, name string) error {
|
||||
err := ValidateVaultName(name)
|
||||
if err != nil {
|
||||
|
||||
Reference in New Issue
Block a user