A vault name may now use only lowercase ASCII letters, digits, ., - and _, and must not be empty, . or ... vault.ValidateVaultName checks this, and its error states the rule, as #65 did for secret names.
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 any path is built from it. Before, vault import .. wrote a long-term key, metadata and an unlocker into the state directory itself, vault select .. made it the current vault, and completing secret mv ../../elsewhere: listed the entries of elsewhere/secrets.d.
What the diff does not show:
vault create and vault select needed no new call: vault.CreateVault and vault.SelectVault already checked the name first, so only the rule and its message changed. vault create therefore still asks for the mnemonic and passphrase before rejecting a bad name, as it does for an existing vault.
In mv the check sits in existingVault, ahead of the exact-name check from #76. The work/ and ./work cases in move_test.go now expect the name-rule error. Its .. case became a missing vault nosuch, so the exact-name check keeps a test of its own; .. is covered by the new test.
Completion offers nothing for a vault part that breaks the rule, without an error, as it already does for a vault that does not exist.
Model: opus-5-5
A vault name may now use only lowercase ASCII letters, digits, `.`, `-` and `_`, and must not be empty, `.` or `..`. `vault.ValidateVaultName` checks this, and its error states the rule, as https://git.eeqj.de/sneak/secret/pulls/65 did for secret names.
`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 any path is built from it. Before, `vault import ..` wrote a long-term key, metadata and an unlocker into the state directory itself, `vault select ..` made it the current vault, and completing `secret mv ../../elsewhere:` listed the entries of `elsewhere/secrets.d`.
What the diff does not show:
- `vault create` and `vault select` needed no new call: `vault.CreateVault` and `vault.SelectVault` already checked the name first, so only the rule and its message changed. `vault create` therefore still asks for the mnemonic and passphrase before rejecting a bad name, as it does for an existing vault.
- In `mv` the check sits in `existingVault`, ahead of the exact-name check from https://git.eeqj.de/sneak/secret/pulls/76. The `work/` and `./work` cases in `move_test.go` now expect the name-rule error. Its `..` case became a missing vault `nosuch`, so the exact-name check keeps a test of its own; `..` is covered by the new test.
- Completion offers nothing for a vault part that breaks the rule, without an error, as it already does for a vault that does not exist.
Model: opus-5-5
internal/cli/completions.go, completeVaultQualifiedSecrets (line 137): shell completion of the mv arguments still builds a path from the vault name as typed, without vault.ValidateVaultName. Completing secret mv ../../elsewhere: lists the entries of elsewhere/secrets.d, outside vaults.d. #68 requires every command that turns a typed vault name into a path to call the rule before building it. The PR body lists this as not done, but nothing on record takes it out of scope, and (closes #68) would close the issue with it still open. Acceptable: return no completions when vault.ValidateVaultName rejects the vault part, before vault.NewVault is called, with a test showing that completing .:, ..: and a/b: returns nothing.
The only conflict with next is in TODO.md.
Model: opus-5-5
**Verdict: FAIL (needs-rework)**
1. `internal/cli/completions.go`, `completeVaultQualifiedSecrets` (line 137): shell completion of the `mv` arguments still builds a path from the vault name as typed, without `vault.ValidateVaultName`. Completing `secret mv ../../elsewhere:` lists the entries of `elsewhere/secrets.d`, outside `vaults.d`. https://git.eeqj.de/sneak/secret/issues/68 requires every command that turns a typed vault name into a path to call the rule before building it. The PR body lists this as not done, but nothing on record takes it out of scope, and `(closes #68)` would close the issue with it still open. Acceptable: return no completions when `vault.ValidateVaultName` rejects the vault part, before `vault.NewVault` is called, with a test showing that completing `.:`, `..:` and `a/b:` returns nothing.
The only conflict with `next` is in `TODO.md`.
Model: opus-5-5
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
completeVaultQualifiedSecrets returns no completions when vault.ValidateVaultName rejects the vault part, before vault.NewVault is called. New test TestVaultSecretCompletionRejectsInvalidVaultName in internal/cli/completions_test.go: completing .:, ..: and a/b: returns nothing although a secrets.d with an entry exists where each would lead.
Rebased onto current next; the TODO.md conflict is resolved with both entries kept.
The PR body's "not done" note is replaced; the commit message and the TODO.md entry now include completion.
Model: opus-5-5
Rework:
- `completeVaultQualifiedSecrets` returns no completions when `vault.ValidateVaultName` rejects the vault part, before `vault.NewVault` is called. New test `TestVaultSecretCompletionRejectsInvalidVaultName` in `internal/cli/completions_test.go`: completing `.:`, `..:` and `a/b:` returns nothing although a `secrets.d` with an entry exists where each would lead.
- Rebased onto current `next`; the `TODO.md` conflict is resolved with both entries kept.
- The PR body's "not done" note is replaced; the commit message and the `TODO.md` entry now include completion.
Model: opus-5-5
PASS: every command that takes a vault name, shell completion of mv included, now checks it against the one stated rule before building a path, as #68 requires.
Model: opus-5-5
PASS: every command that takes a vault name, shell completion of `mv` included, now checks it against the one stated rule before building a path, as https://git.eeqj.de/sneak/secret/issues/68 requires.
Model: opus-5-5
clawbot
merged commit 007254a1f0 into next2026-10-04 13:58:47 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A vault name may now use only lowercase ASCII letters, digits,
.,-and_, and must not be empty,.or...vault.ValidateVaultNamechecks this, and its error states the rule, as #65 did for secret names.vault create,vault import,vault select,vault remove, both vault names ofmvand shell completion of avault:secretargument check the name as typed before any path is built from it. Before,vault import ..wrote a long-term key, metadata and an unlocker into the state directory itself,vault select ..made it the current vault, and completingsecret mv ../../elsewhere:listed the entries ofelsewhere/secrets.d.What the diff does not show:
vault createandvault selectneeded no new call:vault.CreateVaultandvault.SelectVaultalready checked the name first, so only the rule and its message changed.vault createtherefore still asks for the mnemonic and passphrase before rejecting a bad name, as it does for an existing vault.mvthe check sits inexistingVault, ahead of the exact-name check from #76. Thework/and./workcases inmove_test.gonow expect the name-rule error. Its..case became a missing vaultnosuch, so the exact-name check keeps a test of its own;..is covered by the new test.Model: opus-5-5
Verdict: FAIL (needs-rework)
internal/cli/completions.go,completeVaultQualifiedSecrets(line 137): shell completion of themvarguments still builds a path from the vault name as typed, withoutvault.ValidateVaultName. Completingsecret mv ../../elsewhere:lists the entries ofelsewhere/secrets.d, outsidevaults.d. #68 requires every command that turns a typed vault name into a path to call the rule before building it. The PR body lists this as not done, but nothing on record takes it out of scope, and(closes #68)would close the issue with it still open. Acceptable: return no completions whenvault.ValidateVaultNamerejects the vault part, beforevault.NewVaultis called, with a test showing that completing.:,..:anda/b:returns nothing.The only conflict with
nextis inTODO.md.Model: opus-5-5
045a5bf83etoebb1d3d5a4Rework:
completeVaultQualifiedSecretsreturns no completions whenvault.ValidateVaultNamerejects the vault part, beforevault.NewVaultis called. New testTestVaultSecretCompletionRejectsInvalidVaultNameininternal/cli/completions_test.go: completing.:,..:anda/b:returns nothing although asecrets.dwith an entry exists where each would lead.next; theTODO.mdconflict is resolved with both entries kept.TODO.mdentry now include completion.Model: opus-5-5
PASS: every command that takes a vault name, shell completion of
mvincluded, now checks it against the one stated rule before building a path, as #68 requires.Model: opus-5-5