From: "Daniel Martí via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: "M Hickford" <mirth.hickford@gmail.com>,
"Mantas Mikulėnas" <grawity@gmail.com>,
"Patrick Steinhardt" <ps@pks.im>, "Daniel Martí" <mvdan@mvdan.cc>,
"Daniel Martí" <mvdan@mvdan.cc>
Subject: [PATCH] credential/libsecret: load secrets explicitly
Date: Tue, 04 Aug 2026 22:40:17 +0000 [thread overview]
Message-ID: <pull.2372.git.git.1785883217733.gitgitgadget@gmail.com> (raw)
From: =?UTF-8?q?Daniel=20Mart=C3=AD?= <mvdan@mvdan.cc>
secret_service_search_sync() can return an item whose secret is not
loaded, despite SECRET_SEARCH_LOAD_SECRETS being set: the search
silently discards secret-loading failures, and the GNOME keyring
daemon silently omits from its GetSecrets reply any item that is
locked or that was deleted after the search matched it, e.g. by a
concurrent "credential erase" from another git process.
secret_item_get_secret() then returns NULL, which we pass unchecked
to secret_value_get_text() and secret_value_unref(), producing
secret_value_get_text: assertion 'value' failed
secret_value_unref: assertion 'value != NULL' failed
and losing the password even when the secret is still retrievable.
Drop SECRET_SEARCH_LOAD_SECRETS and instead load the secret of the
one item we use with secret_item_load_secret_sync(), which does
report errors. A secret the search would have silently dropped is
now retrieved normally, and a genuinely inaccessible item produces
a useful message instead of assertion spew, with git falling back
to prompting either way. Merely guarding against NULL would avoid
the assertions, but would forfeit a secret that is still available.
The cost is unchanged: the search no longer batch-fetches the
secrets of all matching items, and the explicit load fetches the
one we use.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
---
credential/libsecret: load secrets explicitly
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2372%2Fmvdan%2Flibsecret-null-secret-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2372/mvdan/libsecret-null-secret-v1
Pull-Request: https://github.com/git/git/pull/2372
.../libsecret/git-credential-libsecret.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/libsecret/git-credential-libsecret.c b/contrib/credential/libsecret/git-credential-libsecret.c
index 941b2afd5e..6bbdf2bd45 100644
--- a/contrib/credential/libsecret/git-credential-libsecret.c
+++ b/contrib/credential/libsecret/git-credential-libsecret.c
@@ -126,7 +126,7 @@ static int keyring_get(struct credential *c)
items = secret_service_search_sync(service,
&schema,
attributes,
- SECRET_SEARCH_LOAD_SECRETS | SECRET_SEARCH_UNLOCK,
+ SECRET_SEARCH_UNLOCK,
NULL,
&error);
g_hash_table_unref(attributes);
@@ -143,6 +143,18 @@ static int keyring_get(struct credential *c)
gchar **parts;
item = items->data;
+
+ /*
+ * Load the secret explicitly rather than via
+ * SECRET_SEARCH_LOAD_SECRETS, which silently discards load
+ * failures and returns items whose secret is NULL.
+ */
+ if (!secret_item_load_secret_sync(item, NULL, &error)) {
+ g_critical("could not load secret: %s", error->message);
+ g_error_free(error);
+ g_list_free_full(items, g_object_unref);
+ return EXIT_FAILURE;
+ }
secret = secret_item_get_secret(item);
attributes = secret_item_get_attributes(item);
base-commit: 5b2471720c93ee30e5764a19f3d3b3ae9ec9712a
--
gitgitgadget
next reply other threads:[~2026-08-04 22:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 22:40 Daniel Martí via GitGitGadget [this message]
2026-08-20 15:00 ` [PATCH] credential/libsecret: load secrets explicitly Daniel Martí
2026-08-20 19:05 ` Junio C Hamano
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=pull.2372.git.git.1785883217733.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=git@vger.kernel.org \
--cc=grawity@gmail.com \
--cc=mirth.hickford@gmail.com \
--cc=mvdan@mvdan.cc \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.