Repository navigation
docs(keychain): correct two claims that live-probing did not support - #116
Merged
Merged
Conversation
Comments only; no behaviour change. Probed /usr/bin/security on macOS 26.5 with a throwaway keychain: - CONFIRMED: a security -i round trip stores the value byte-for-byte, an absent item really does exit 44, and a LOCKED keychain does not exit 44 at all — it blocks on a GUI unlock prompt until spawnSync's timeout fires, leaving status null. That is the common real-world path into the read failure 0.41.1 fixed, so the classification there is load-bearing. - WRONG, now corrected: the newline guard's comments claimed the remainder of a broken line 'executes as another security(1) subcommand'. It does not. With escaping the injection attempt exits 2 and stores nothing, and WITHOUT escaping it also fails — the quote escaping already prevents a value from closing its own quote. The guard is a correctness improvement (an explicit reason instead of an opaque exit 2), not the security boundary I described. - UNVERIFIED, now labelled: the 128-byte truncation of the bare -w prompt is inherited from Circle's CLI and did not reproduce here (the probe hit a usage error). -i is preferred for keeping the secret out of argv anyway, so nothing depends on the figure being exact. Leaving a wrong security claim in a comment is how someone later deletes the wrong guard for the right-sounding reason.
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.
Comments only, no behaviour change, no version bump — rides the next release.
I probed
/usr/bin/securityon macOS 26.5 with a throwaway keychain and a fake key (the user's own keychain was never touched — it had noblockrunentries). Three claims held, two did not.Confirmed
security -iround trip stores the value byte-for-byte.MACOS_ITEM_NOT_FOUNDis right.spawnSync's timeout fires, leavingstatusnull. That is the likeliest real-world path into the read failure 0.41.1 — a failed keychain read must not mint a new wallet #115 fixed, andkeychainReadclassifiesnullaserrorrather thanabsent. So that fix is load-bearing, and the 0.41.0 bug was reachable by the most ordinary failure there is.Wrong, corrected here
The newline guard's comments claimed the remainder of a broken line "executes as another
security(1)subcommand." It does not. With escaping, the injection attempt exits 2 and stores nothing; without escaping it also fails, because the quote escaping already prevents a value from closing its own quote.The guard is still worth keeping — it turns an opaque exit 2 into a stated reason, and hedges a future platform being laxer about a half-parsed line — but it is a correctness improvement, not the security boundary I described in #114.
Unverified, now labelled
The 128-byte truncation of the bare
-wprompt is inherited from Circle's CLI and did not reproduce here (my probe hit a usage error).-iis preferred for keeping the secret out ofargvregardless, so nothing depends on the figure. It is now marked as inherited rather than stated as fact.Why bother
A wrong security claim in a comment is how someone later deletes the wrong guard for a right-sounding reason.
362 tests pass; typecheck clean.