Document the listing and export flags - #29
Merged
Conversation
The three listing commands took flags the reference never mentioned, including the one that governs whether a secret appears at all: a secret whose newest version has been deleted is left out unless -q is given, even when an older version of it is still readable.
Both flags change which secrets come out, not only how many versions of each, and neither was described in the reference.
This was referenced Jul 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documentation only. Stacked on #28 — it builds on the
### lssection thatPR adds, so review that one first; GitHub will retarget this to
developonce#28 merges.
Why
ls,tree, andpathsall take flags the command reference never mentioned,and one of them decides whether a secret is listed at all. A secret whose newest
version has been deleted or destroyed does not appear in a default listing —
not even when an older version of it is still perfectly readable — and nothing
in the README said so. The behaviour is defensible for a listing of what you can
read, and
-qis right there, but a reader had no way to learn either fact.export's two flags were undocumented in the same way, and they change whichsecrets come out, not just how many versions of each.
Verified, not inferred
Every claim was measured against a live Vault 1.13.2 first. Fixture on the v2
secret/mount:alive(one live version),gone(v1 live, v2 deleted),dead(its only version deleted),blown(its only version destroyed).treeandlsagree withpathson the same fixture, both with and without-q.Which is where the wording comes from:
-akeeps any secret with at least onereadable version and pads the rest as placeholders so the surrounding version
numbers stay right;
-drecovers the deleted values and pulls in secrets aplain export skips entirely; a destroyed version stays a placeholder either way.
Not changed
The listing behaviour itself. Hiding a secret you cannot read is a reasonable
default for a listing,
-qcovers the other case, and unlike a backup it losesnothing. This PR makes it discoverable rather than quietly true.