docs: record that libsecret is validated against GNOME Keyring only - #75
Merged
Merged
Conversation
) The backend was documented as working with "GNOME Keyring, KWallet's shim, any Secret Service implementation". Testing against KWallet disproves that. Ubuntu 26.04's kwallet6 ships ksecretd, a Secret Service compatibility daemon that claims org.freedesktop.secrets, so the environment the issue said could not be provisioned is in fact available. Running the suite against it, with the bus name owner verified as ksecretd rather than assumed, produced 46 failures from a single root cause: KWallet does not implement the session collection alias that gnome-keyring provides, so the tests' KeyringCollection = "session" fails with "No such object path '/org/freedesktop/secrets/aliases/session'". Probing the shipped configuration instead -- KeyringCollection = "default" -- does not fail; it hangs. ksecretd logs "Using kwallet without parent window!" and blocks trying to raise an unlock dialog. Our four libsecret entry points all pass a NULL GCancellable, so there is no timeout and no cancellation. That is a product defect in its own right and is filed as #74. Docs now state what is validated: GNOME Keyring only, KWallet unsupported, other implementations untested. KeyringCollection's doc notes that "session" is a GNOME convenience rather than a portable value -- worth saying, since the test suite depends on it. No behaviour change. Co-Authored-By: Claude Opus 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.
Fixes #19.
The issue said this couldn't be verified. It can.
Ubuntu 26.04's
kwallet6shipsksecretd, a Secret Service compatibility daemon. Its binary implements the fullorg.freedesktop.Secret.{Service,Collection,Item,Session,Prompt}set and claims theorg.freedesktop.secretsbus name, so it can be swapped in for gnome-keyring locally. That is what I did.The harness stops the gnome-keyring user unit, starts
ksecretd, verifies which pid actually owns the bus name before trusting anything, runs the suite, and restores gnome-keyring. The ownership check is not ceremony — only one process can hold that name, so without it a "passing" run might just be gnome-keyring answering.Result: two distinct failures
1. No
sessioncollection. 46 failures (23 tests × 2 TFMs), single root cause:The test suite targets
"session"because CI runners have no provisioned login keyring. That collection is a GNOME Keyring convenience — KWallet does not provide it.2. The shipped configuration hangs. Probing
KeyringCollection = "default", the actual default, does not fail — it never returns.ksecretdlogs:It is trying to raise a wallet-unlock dialog. All four of our libsecret entry points pass a NULL
GCancellable, so there is no timeout and no cancellation. The probe had to be killed at 120 s.That second one is a product defect independent of KWallet — a locked GNOME login keyring would prompt too — so it is filed separately as #74 rather than buried in a docs change.
What this PR changes
Documentation only, no behaviour change:
LibsecretCredentialManagerremarks: same, with the exact error text so the next person hits a search hit instead of a mystery.CredentialStoreOptions.KeyringCollection: notes that"session"is a GNOME convenience, not a portable value — worth saying given the test suite depends on it.Verification
Build clean, 412 tests (354 passed, 58 skipped) against gnome-keyring — unchanged, since nothing executable changed. gnome-keyring was confirmed restored as the bus-name owner after each experiment.
🤖 Generated with Claude Code