5 Commits

Include renames

Author	SHA1	Message	Date
clawbot	63928ea745	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 12:28:18 +00:00
clawbot	007254a1f0	Check vault names in every command that takes one (closes #68) ... A vault name may use only lowercase ASCII letters, digits, `.`, `-` and `_`, and must not be empty, `.` or `..`; the error now states that rule. `vault create`, `vault import`, `vault select`, `vault remove`, both vault names of `mv` and shell completion of a `vault:secret` argument check the name as typed before building any path from it. Before, `vault import ..` wrote a long-term key and an unlocker into the state directory itself, and `vault select ..` made that the current vault. Model: opus-5-5	2026-10-04 13:58:46 +02: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	e640d10964	Reject secret mv onto the same secret under another name (closes #78) ... On a case-insensitive filesystem (the macOS default) "Foo" and "foo" name one secret, so `secret mv --force Foo foo` removed the destination, which was the source, and lost the secret with every version. Between vaults the copy replaced the source, and removing the source then removed the copy. Both kinds of move now compare the two secret directories with os.SameFile before changing anything and reject the move if they are one, with or without --force. The tests give one secret two names with symbolic links on the real filesystem. Model: opus-5-5	2026-10-04 07:42:11 +02:00
clawbot	663986f551	Stop secret mv deleting a secret moved onto itself (closes #73) ... `secret mv --force x x` deleted the secret: a move within one vault removes an existing destination before renaming the source onto it. The same happened for `work:x work:`, `work:x work` and `work:x ""`, and for `work:x work/:x`, which named one vault two ways and so was taken for a move between vaults. A move whose two names are the same is now rejected before anything changes. Every vault named with `vault:` must be one of the existing vaults by exact name, checked before choosing between the two kinds of move. A move within a named vault no longer makes it the current vault. The test runs each rejected move on a copy of two in-memory vaults and requires the exact error and an unchanged state directory. Model: opus-5-5	2026-10-04 05:08:06 +02:00