From: Daniel Martí <mvdan@mvdan.cc>
Date: Sun, 27 Sep 2026 22:45:03 GMT
Subject: Re: [PATCH] credential/libsecret: load secrets explicitly
Message-ID: <3cae7bd6-33fa-4695-bf4e-9f473ac98042@mvdan.cc>
In-Reply-To: <CAGJzqs=sUA7vGDwadL9h-dcuPAsQvhAjiirZhA5=_fyqH1QXuA@mail.gmail.com>

On 9/24/26 8:00 AM, M Hickford wrote:
> Is this an upstream bug in libsecret?
>
> The libsecret docs for SECRET_SEARCH_LOAD_SECRETS  are unfortunately
> truncated https://gnome.pages.gitlab.gnome.org/libsecret/method.Service.search_sync.html

Partly. The truncated sentence is a docs bug, which I've sent a fix for:
https://gitlab.gnome.org/GNOME/libsecret/-/merge_requests/182

The behavior itself looks intentional, though. The search does not
load secrets of locked items, and just like a failed unlock, a failed
load does not fail the search; secret_item_get_secret() is documented
to return NULL for a locked or unloaded item. The daemon side is
deliberate too: gnome-keyring's GetSecrets skips items which are
locked or no longer exist, whereas GetSecret on a single item returns
an error.

So git needs to handle a NULL secret either way, including with every
libsecret release out there. libsecret's own secret-tool also loads
each secret explicitly after searching, which is what this patch does.

I'll send a v2 with a reworded commit message shortly.

Thanks!