4 Commits

Include renames

Author	SHA1	Message	Date
sneak	9a745d8d1c	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 07:33:47 +00: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