5 Commits

Include renames

Author	SHA1	Message	Date
clawbot	682bf751e7	Read secret environment variables once per command, then unset them (closes #60) ... init and vault create put the mnemonic into the process environment for vault.CreateVault to read back, so every program they ran, gpg included, inherited it, and SB_SECRET_MNEMONIC and SB_UNLOCK_PASSPHRASE were read at 13 places and never unset. Each command that may need them now reads both once, in its RunE, into locked buffers on the CLI Instance, and unsets them at once. The buffers are passed down: vault.CreateVault takes the mnemonic, a Vault carries Mnemonic and UnlockPassphrase, and the PGP, keychain and Secure Enclave unlocker constructors take both. Nothing below the command reads the environment. README warns against both variables. Model: opus-5-5	2026-10-04 11:30:08 +00:00
clawbot	4ed77902d1	Keep secret get values in locked memory (closes #37) ... Vault.GetSecret and Vault.GetSecretVersion return the decrypted value as a *memguard.LockedBuffer instead of copying it into an ordinary []byte that nothing wiped. Every caller destroys the buffer, and `secret get` writes its bytes straight to stdout, still with no trailing newline. Instance.Print, which formatted through fmt and had no other callers, is removed, and so is a debug log line in `get --version` that held the plaintext value. Model: opus-5-5	2026-10-04 11:16:23 +02:00
clawbot	fb4481b4f7	Refuse to create a vault that already exists (closes #74) ... vault.CreateVault now checks for the vault before writing anything and fails with "vault NAME already exists" (vault.ErrVaultExists). secret init and secret vault create call it while holding the state directory lock, so two creates at once cannot both pass the check. Before, either command over an existing vault replaced its metadata, passphrase unlocker and longterm.age, so none of its secrets could be decrypted. Both commands now ask for the unlocker passphrase before creating the vault, so one stopped at that prompt leaves no vault without an unlocker behind, which they would then refuse to create again. The lock tests set up the vault "work" instead of "default", which init now refuses to create again. Model: opus-5-5	2026-10-04 08:25:40 +02:00
clawbot	5ec59862ff	Speed up the internal/cli lock and two-vault tests (closes #80) ... The test that each changing command waits for the state directory lock slept a fixed 100 ms per command. It now polls the goroutine stacks until the command is parked in vault.LockStateDir, checks the state directory is unchanged, and releases the lock; a command that takes no lock still fails by finishing first. newTwoVaultFs creates its two vaults, each with a passphrase unlocker, once, and returns a fresh copy of them on every call, so the six path and move tests no longer each pay for two passphrase key derivations. Model: opus-5-5	2026-10-04 08:08:04 +02:00
clawbot	32a61ff963	Lock the state directory and write vault files atomically (closes #34) ... Each command that changes the state directory holds one lock: flock(2) on `lock` in the state directory, dropped by the kernel if the process dies, or a process-wide mutex on the in-memory test filesystem. It covers the state directory, not each vault, because `currentvault`, `vault create` and cross-vault moves span vaults, and a lock file in a vault would be deleted by `vault remove` under a waiting command. Files go through `secret.WriteFileAtomic`; versions, new secrets and cross-vault copies are built in a temporary directory and renamed into place; removals rename out of the way first. Left for later: replacing an unlocker (#71) and deleting what an interrupted command leaves under a `.tmp-` name (#75). Model: opus-5-5 Co-authored-by: clawbot <sneak+clawbot@sneak.cloud>	2026-10-04 04:57:58 +02:00