Git development
 help / color / mirror / Atom feed
From: "Daniel Martí" <mvdan@mvdan.cc>
To: "M Hickford" <mirth.hickford@gmail.com>,
	"Daniel Martí via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Mantas Mikulėnas" <grawity@gmail.com>,
	"Patrick Steinhardt" <ps@pks.im>
Subject: Re: [PATCH] credential/libsecret: load secrets explicitly
Date: Sun, 27 Sep 2026 23:45:03 +0100	[thread overview]
Message-ID: <3cae7bd6-33fa-4695-bf4e-9f473ac98042@mvdan.cc> (raw)
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!


  reply	other threads:[~2026-09-27 22:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 22:40 [PATCH] credential/libsecret: load secrets explicitly Daniel Martí via GitGitGadget
2026-08-20 15:00 ` Daniel Martí
2026-08-20 19:05   ` Junio C Hamano
2026-08-22 20:47     ` Daniel Martí
2026-09-21 21:54       ` Daniel Martí
2026-09-21 22:52         ` Junio C Hamano
2026-09-24  7:00 ` M Hickford
2026-09-27 22:45   ` Daniel Martí [this message]
2026-09-27 22:46 ` [PATCH v2] " Daniel Martí via GitGitGadget
2026-09-28  7:37   ` Daniel Martí

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3cae7bd6-33fa-4695-bf4e-9f473ac98042@mvdan.cc \
    --to=mvdan@mvdan.cc \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=grawity@gmail.com \
    --cc=mirth.hickford@gmail.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox