Repository navigation
keyring CLI tests each own a TempDir keyring: init and list no longer race on the real $HOME keyring (#444) - #445
Merged
Conversation
… race on the real $HOME keyring (Refs #444) test_INSTALLER_CLI_007_keyring_init and _list ran the binary with the ambient environment, so both resolved the user's real ~/.config/bashrs/installer/keyring.json. libtest ran them on parallel threads and list read the file while init was writing it: "Failed to parse keyring: EOF while parsing a value at line 1 column 0" (the red v7.4.2 release gate on 0ae1212). They also wrote the runner's real keyring. Every keyring CLI test now runs through keyring_cmd(&TempDir), which sets XDG_CONFIG_HOME and HOME to its own directory, so neither branch of keyring_path_from can reach the real home. init asserts the file lands in its directory; list on a fresh directory asserts "Keyring not initialized" (it accepted either state before); a new list_after_init test asserts list reads what init wrote. These are the only tests that touch the keyring file: the unit tests already pass the path in (#339), and installer run reads the keyring only with --verify-signatures, which no test passes. Discriminator (t2build, the two tests at --test-threads=8 against one shared scratch HOME): before 2/300 and 13/1000 runs fail with the EOF parse error; after 0/1000 three times, and the shared HOME never gets a keyring file. Refs PMAT-444 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…eal 3/3 PASS, plant caught 2/3 (degraded: same-family) Refs PMAT-444 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
1 participant
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.
Refs #444. Ticket PMAT-444 (epic #426, release v7.4.2).
test_INSTALLER_CLI_007_keyring_initand_listran the binary with the ambient environment, so both resolved the real~/.config/bashrs/installer/keyring.json. libtest ran them in parallel, and list read the file while init was writing it:Failed to parse keyring: EOF while parsing a value at line 1 column 0. That made the v7.4.2 release gate red on 0ae1212.Fix (test-only):
keyring_cmd(&TempDir)setsXDG_CONFIG_HOMEandHOMEto the test's own directory. The init test now asserts the file lands there. The list test runs on a fresh directory and assertsKeyring not initialized. A newlist_after_inittest asserts that list reads what init wrote. No other test touches the keyring file: the unit tests already pass the path in (#339), andinstaller runreads the keyring only with--verify-signatures, which no test passes.Discriminator (t2build: the two tests at
--test-threads=8, all runs sharing one scratch HOME):Receipt:
docs/audits/impl-PMAT-444-receipt.md.🤖 Generated with Claude Code