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]

The original report said the crash-time glib was 2.88.2-1 and that I could not
say whether 2.89.4-2+b1 still aborts, because the machine had been upgraded
three hours after the last occurrence and I had not retested.

Retested now, unintentionally: **it still aborts with glib 2.89.4-2+b1
mapped.** One clean data point rather than two, and the distinction is the
point of this message.

The machine was not rebooted after the upgrade - needrestart's "restart
recommended services" was answered, which restarts services and not every
long-lived user process - so a daemon started before 2026-09-10 09:32:27 kept
the old library mapped however the package database read. Only a process
started AFTER that time is evidence about 2.89.4-2+b1.

Verified rather than assumed: the gnome-keyring-daemon running now, started
after the upgrade, maps /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.8904.0 with
no "(deleted)" marker, so a fresh exec does resolve to the new library.

Installed versions, from /var/log/dpkg.log:

  libglib2.0-0t64   2.89.4-2+b1   upgraded 2026-09-10 09:32:27 (2.88.2-1 when
                                  I filed). Installed before both of last
                                  night's aborts; only the second RAN it
  gnome-keyring     50.0-1        unchanged since 2026-06-18
  gcr               3.41.2-6+b1   unchanged
  libsecret-1-0     0.21.7-2+b1   unchanged
  dbus              1.16.2-5+b1   unchanged

Five occurrences now, each in a separate daemon, all with the same signature.
The last column is the glib each process actually had MAPPED, which for the
fourth is not the one that was installed:

  Sep 05 05:48:34 EDT   pid 591      started before   ->  2.88.2-1
  Sep 07 13:42:52 EDT   pid 680      started before   ->  2.88.2-1
  Sep 10 06:29:33 EDT   pid 690      started Sep 08   ->  2.88.2-1
  Sep 10 21:18:54 EDT   pid 352478   started 08:37    ->  2.88.2-1  (pre-upgrade
                                     process, so this one says nothing new)
  Sep 10 22:04:22 EDT   pid 461781   activated 21:18  ->  2.89.4-2+b1  <-- new

Journal for the last one, verbatim and identical to the first three:

  Sep 10 22:04:22 gnome-keyring-daemon[461781]: gkd_secret_service_get_pkcs11_session: assertion 'client' failed
  Sep 10 22:04:22 gnome-keyring-daemon[461781]: secret_objects_lookup_gck_object_for_path: assertion 'session' failed
  Sep 10 22:04:22 gnome-keyring-daemon[461781]: **
  GLib-GIO:ERROR:../../../gio/gdbusconnection.c:4765:invoke_get_property_in_idle_cb: assertion failed: (error != NULL)
  Sep 10 22:04:22 kernel: gnome-keyring-daemon: gnome-keyring-d: potentially unexpected fatal signal 6.

pid 461781 is the daemon D-Bus ACTIVATED to replace pid 352478 when that one
died at 21:18:54. So it is both the freshest possible process on the new glib
and the proof that a crash here is not a one-off state a restart clears: it
aborted the same way 45 minutes after being started.

## The downstream cost, measured a second time

The first report said the replacement daemon comes up locked and that a
Secret Service unlock returns a Prompt object and then waits for a `Completed`
signal, with no method reply and no timeout. A second, longer measurement:

After the 21:18:54 abort the replacement came up with the login collection
locked. Two unattended background services asked for the same credential, at
21:19:06 and 21:21:54. Neither was answered, because there was nobody at the
screen. Eleven hours later the collection is still locked and one of those
services is still inside its unlock wait, having logged nothing since - it
sleeps five seconds at a time, so from the outside it is indistinguishable
from an idle process doing its job.

So the practical severity is not the abort. It is that one assertion failure in
a session daemon can leave every stored credential unreachable until a person
types a passphrase, and nothing about the resulting state announces itself.

Still no core dump on this machine: systemd-coredump is not installed and
/proc/sys/kernel/core_pattern is "core". The symbolized backtrace in
GNOME/gnome-keyring#195 remains the only one.

## AI assistance

This follow-up was assembled with AI assistance and reviewed before sending.

AI-Assisted-By: claude-opus-5 (claude code)

The dates, pids, versions and journal lines were read from this machine's
journal and dpkg log. The remark about the replacement daemon is inference from
the activation record in the same journal, not from instrumentation.