Package: golang-github-zalando-go-keyring Version: 0.2.4-1
Severity: normal Dear Maintainer, Programs built against go-keyring 0.2.4 cannot read a secret from KeePassXC's Secret Service when KeePassXC is set to confirm each retrieval. The read fails at once with org.freedesktop.Secret.Error.IsLocked and no prompt appears. Upstream fixed this in v0.2.5. The package is at 0.2.4-1 in stable, testing and unstable, and your tracker flags 0.2.8 as available. How I found it gh 2.46.0 fails with "no oauth token found for github.com" right after a successful gh auth login. gh 2.46.0-4 build-depends on golang-github-zalando-go-keyring-dev >= 0.2.4. The official upstream gh 2.46.0 binary embeds go-keyring v0.2.4 and fails the same way. Upstream gh 2.103.2 embeds v0.2.8, shows the KeePassXC prompt and works. I tested on Ubuntu 26.04.1 LTS with gh 2.46.0-4ubuntu0.26.04.1~esm1 and KeePassXC 2.7.10. I have not tested Debian itself. Debian stable ships gh 2.46.0-3 and the same library version, so I expect the same result there. To reproduce 1. In KeePassXC, enable Secret Service Integration and tick "Confirm when passwords are retrieved by clients". 2. Run gh auth login -h github.com. 3. Run gh auth token. It prints "no oauth token found for github.com", exits 1 within about 30 ms and shows no prompt. 4. Untick the option and run step 3 again. It works. What the bus shows I watched the session bus with dbus-monitor, filtered to method calls on the Secret Service, Collection and Item interfaces plus error replies. Item and session ids are left out. With go-keyring 0.2.4, run twice, once searching for username "" and once for username realstuffie: Service.Unlock on /org/freedesktop/secrets/aliases/default Collection.SearchItems with service=gh:github.com and the username Service.OpenSession with "plain" Item.GetSecret on the item KeePassXC replies Secret.Error.IsLocked under 60 microseconds later. With go-keyring 0.2.8, same item: Service.Unlock on the default collection Collection.SearchItems with service=gh:github.com and username=realstuffie Service.OpenSession with "plain" Service.Unlock on the item itself about 3 seconds while I approved the KeePassXC prompt Item.GetSecret on the item, which succeeds. Cause With confirmation on, KeePassXC locks each item separately, so a client has to unlock the item before calling GetSecret. Version 0.2.4 only unlocks the collection. Upstream PR 108, "Prompt to unlock individual item when getting secret from keyring in unix system", commit 14b7cd2, was merged on 2024-06-06 and released in v0.2.5. KeePassXC issue 9334 describes the same symptom from the client side. Request Please package 0.2.5 or later. If a smaller change suits you better, cherry-picking 14b7cd2 as a patch fixes this too. gh needs a rebuild to pick up either change. I have not checked other reverse dependencies. Until then, unticking the confirm option in KeePassXC avoids the failure. Thanks, Thomas Moore
