Bug#1147303: gnome-keyring: daemon aborts on a Secret Service property GET when the caller has no PKCS#11 client record
ilatypov at yahoo.ca
ilatypov at yahoo.ca
Thu Sep 10 15:15:50 BST 2026
Package: gnome-keyring
Version: 50.0-1
Severity: important
Control: tags -1 upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/195
Dear Maintainer,
gnome-keyring-daemon aborts (SIGABRT) while answering a D-Bus property GET on
the Secret Service interface. It has happened three times on this machine in
six days, in three separate boots, always with the same three-line signature.
D-Bus then activates a replacement daemon, which comes up with the login
collection LOCKED. Every libsecret client on the session must then wait for an
unlock prompt. On this machine one background service waited 2h26m, because a
Secret Service prompt has no method reply and no timeout, so a service with
nobody sitting in front of it hangs rather than fails.
PLEASE READ BEFORE THE VERSION TABLE BELOW
------------------------------------------
The "System Information" and dependency versions at the end of this mail were
collected by reportbug TODAY, about three hours after the most recent crash and
after an `apt dist-upgrade` that replaced several of the packages involved.
They describe this machine now, NOT the machine that crashed.
The assertion is inside glib, and glib is one of the packages that moved. At
all three crashes the versions were:
gnome-keyring 50.0-1 (unchanged since 2026-06-18)
libglib2.0-0t64 2.88.2-1 (table below says 2.89.4-2+b1)
libgcrypt20 1.12.2-1 (table below says 1.12.3-2)
libc6 2.42-17 (table below says 2.43-5)
libsystemd0 261.1-3 (table below says 262~rc2-1)
p11-kit 0.26.4-1 (table below says 0.26.5-1)
pinentry-gnome3 1.3.3-2 (table below says 1.3.3-3)
gcr 3.41.2-6+b1 unchanged
libgck-1-0 3.41.2-6+b1 unchanged
libgcr-base-3-1 3.41.2-6+b1 unchanged
dbus / dbus-daemon 1.16.2-5+b1 unchanged
dconf-gsettings-backend 0.49.0-4+b1 unchanged
Taken from /var/log/dpkg.log and /var/log/apt/history.log. libglib2.0-0t64 was
2.88.2-1 from 2026-07-21 until 2026-09-10 09:32, which covers all three
crashes. I have not retested on the new glib, so I cannot say whether
2.89.4-2+b1 still aborts.
Occurrences
-----------
Three, in three different boots, all under gnome-keyring 50.0-1:
Sep 05 05:48:34 EDT pid 591
Sep 07 13:42:52 EDT pid 680
Sep 10 06:29:33 EDT pid 690
Journal for the most recent one, verbatim:
Sep 10 06:29:33 gnome-keyring-daemon[690]: gkd_secret_service_get_pkcs11_session: assertion 'client' failed
Sep 10 06:29:33 gnome-keyring-daemon[690]: secret_objects_lookup_gck_object_for_path: assertion 'session' failed
Sep 10 06:29:33 gnome-keyring-daemon[690]: **
GLib-GIO:ERROR:../../../gio/gdbusconnection.c:4765:invoke_get_property_in_idle_cb: assertion failed: (error != NULL)
Sep 10 06:29:33 kernel: gnome-keyring-daemon: gnome-keyring-d: potentially unexpected fatal signal 6.
The Sep 05 and Sep 07 entries are identical apart from the pid. The daemon in
each case was the session daemon started by D-Bus activation, running
--components=pkcs11,secrets with --control-directory=/run/user/1000/keyring.
There is no core dump and therefore no backtrace: systemd-coredump is not
installed here and /proc/sys/kernel/core_pattern is "core".
What the caller was doing
-------------------------
Ordinary Secret Service reads through libsecret 0.21.7-2+b1, from Python
services that fetch a stored token before each HTTP call. No unusual API use:
get_password() and item lookups, and nothing that touches OpenSession
directly.
dbus-daemon logged the re-activation request immediately after the abort, which
names the client that was mid-call:
Sep 10 06:29:33 dbus-daemon[597]: Activating service name='org.freedesktop.secrets'
requested by ':1.78712' (uid=1000 pid=300855 comm="python3 .../chat-agent-daemon.py")
I cannot prove that this client's call is the one that tripped the assertion,
because dbus-daemon logs activations and not method calls. Two facts argue
against a single unusual client being required: the Sep 05 and Sep 07 crashes
happened before that particular service existed, and the crash has recurred
under three different mixes of running clients.
Mechanism, as far as the source shows
-------------------------------------
The assertion order suggests the same missing-GError family as upstream
issue #190, but on a different call site.
gkd_secret_service_get_pkcs11_session() returns NULL when the caller has no
ServiceClient record yet. secret_objects_lookup_gck_object_for_path() guards
that with g_return_val_if_fail (session, ...), which returns without setting
the GError. The property getter therefore returns failure with *error == NULL,
and glib's invoke_get_property_in_idle_cb() asserts error != NULL and aborts
the process.
Upstream #190 describes exactly this shape in OpenSession -> aes_negotiate()
and carries a patch for that path. If that reading is right, the property
lookup path needs the same treatment: set a real GError (G_DBUS_ERROR_FAILED)
instead of returning FALSE silently.
Upstream
--------
https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/195
Same abort site (gdbusconnection.c:4765). Open since 2026-09-02,
labelled "1. Crash", reported on gnome-keyring 50.0 with GLib 2.88.3.
That report has the symbolized backtrace this one lacks, but does not
name the two gkd_secret assertions that precede the abort, so it does
not identify which getter is at fault.
https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/190
Root cause of the same class on the OpenSession path, with a patch.
https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/194
Another OpenSession instance.
I found no existing Debian bug for this. I checked the bug titles for source
package gnome-keyring, open and archived (198 reports), and found nothing
matching; bugs-search.debian.org does not resolve from this network, so I could
not search report bodies.
Impact
------
The abort itself is survivable, but the recovery is not quiet:
- the replacement daemon starts locked, so every stored credential becomes
unavailable until someone types the login passphrase;
- a background service that reads a secret gets neither a value nor an
error, because the Secret Service prompt returns a Prompt object and then
waits for a Completed signal that a replaced daemon never sends. The
service hangs for as long as nobody answers the dialog. Here that was
2h26m, and it looked exactly like a working daemon that had gone quiet.
Environment note
----------------
This is Debian sid inside WSL2 (kernel 6.6.87.2-microsoft-standard-WSL2),
running a systemd user session with no graphical desktop. gcr-prompter does
start and draw its dialog, but there is frequently nobody to answer it, which
is why the locked-after-respawn state is so visible here.
AI assistance
-------------
This report was assembled with AI assistance and reviewed before sending.
AI-Assisted-By: claude-opus-5 (claude code)
The Occurrences, version and impact sections were read out of this machine's
journal, dpkg log and apt history. The Mechanism section is inference from the
upstream source and the order of the assertions; with no core dump it is not
confirmed here.
-- System Information:
Debian Release: forky/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.87.2-microsoft-standard-WSL2 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gnome-keyring depends on:
ii dbus-user-session [default-dbus-session-bus] 1.16.2-5+b1
ii dconf-gsettings-backend [gsettings-backend] 0.49.0-4+b1
ii gcr 3.41.2-6+b1
ii libc6 2.43-5
ii libgck-1-0 3.41.2-6+b1
ii libgcr-base-3-1 3.41.2-6+b1
ii libgcrypt20 1.12.3-2
ii libglib2.0-0t64 2.89.4-2+b1
ii libsystemd0 262~rc2-1
ii p11-kit 0.26.5-1
ii pinentry-gnome3 1.3.3-3
Versions of packages gnome-keyring recommends:
ii gnome-keyring-pkcs11 50.0-1
ii libpam-gnome-keyring 50.0-1
gnome-keyring suggests no packages.
-- no debconf information
More information about the pkg-gnome-maintainers
mailing list