[Desktop 2026.7.0 / Linux Flatpak] ashpd portal property-watch retry loop leaks fds, crashes ksecretd (KWallet Secret Service backend) on KDE/Wayland

Summary

Bitwarden's desktop Flatpak spams a failed portal property-watch retry once a second, indefinitely, from the moment it starts. On KDE/Wayland with KWallet as the Secret Service backend, this leaks file descriptors into ksecretd (KDE's org.freedesktop.impl.portal.desktop.kwallet backend) until it hits EMFILE and hard-crashes.

This is a different code path than #20909 (fixed by #20919, merged 2026-06-15, already included in this build) and a different manifestation than the still-open #22092 (same "retries forever against stale state" bug family, but that one is a data.json disk-write loop under GNOME/gnome-keyring, not a KWallet portal leak). Session bus itself survived both crashes here; only the two ksecretd client processes died, not the whole desktop like in #20909.

Steps to reproduce

1. Install com.bitwarden.desktop from Flathub on Fedora 44 / KDE Plasma 6, Wayland, KWallet as Secret Service provider.
2. Log in, let Bitwarden autostart.
3. Watch the journal from the moment of login:

   journalctl -f | grep ashpd
   

4. Observe the retry firing roughly once a second, forever:

   flatpak[2829]: [NAPI] [WARN] zbus::proxy: Failed to populate properties cache
   via GetAll: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist
   at path "/org/freedesktop/portal/desktop/request/1_128/ashpd_wg1Ew8vTc2"
   

   Each retry targets a fresh randomly-suffixed ashpd_... request path, all failing the same way, none ever succeeding.
5. Leave it running. Eventually the currently-active ksecretd instance (KWallet's Secret Service portal backend) crashes:

   ksecretd[14432]: GLib-ERROR **: Creating pipes for GWakeup: Too many open files
   audit: ANOM_ABEND ... exe="/usr/bin/ksecretd" sig=5 res=1
   

Expected behavior

The property-watch call either succeeds, backs off, or gives up. It should not retry against a stale/expired request path forever, and it should not leak whatever resource it's leaking on each failed attempt.

Actual behavior

2,020 failed retries logged between login (21:06:40) and crash (21:46:42), roughly 40 minutes, all against different ashpd_... paths, all UnknownMethod. Two separate ksecretd processes (PIDs 10392 and 14432) were both crashed simultaneously by EMFILE when this finally exhausted their fd tables:

$ coredumpctl list
Mon 2026-08-03 21:46:42 EDT 14432 1000 1000 SIGTRAP present /usr/bin/ksecretd 2.2M
Mon 2026-08-03 21:46:42 EDT 10392 1000 1000 SIGTRAP present /usr/bin/ksecretd 2.2M

Not EMFILE from a systemd-imposed limit. LimitNOFILE on the transient portal-backend service was 1,048,576:

$ systemctl --user show 'dbus-:1.1-org.freedesktop.impl.portal.desktop.kwallet@1.service' -p LimitNOFILE
LimitNOFILE=1048576

Genuinely leaking that many fds in 40 minutes means the per-retry leak rate is real, not marginal. I didn't get a live trace of exactly which fd type is leaked per iteration (would need to poll ksecretd's own /proc/<pid>/fd across several retries to catch it directly, and by the time I was watching, both instances had already crashed and been replaced), so I can't point at the exact unclosed handle the way #20909 pinned its D-Bus socket leak. But the correlation is solid: over 2,000 failed retries against the same portal-backend instances, ending in exactly the crash you'd expect from a per-request resource that's never released on failure.

Workaround: quitting Bitwarden stops the retry loop immediately (confirmed: no further ashpd_... log lines within seconds of quitting) and prevents further crashes.

Environment

Related issues

• #20909 (closed) / #20919 (merged 2026-06-15): same general symptom (D-Bus/portal resource leak leading to EMFILE), but that leak was in the powermonitor/lock-monitor reconnect path and the fix predates this build. Confirmed not the same code path: this leak is driven by portal property-watch retries against ashpd_... request paths, not power-monitor polling, and the session bus itself didn't crash here, only the portal-backend client did.
• #22092 (open): same underlying "app retries forever against stale local/D-Bus state without cleanup" pattern, but manifests as a data.json disk-write loop under GNOME/X11 + gnome-keyring. Different resource (disk I/O vs. fds), different desktop/backend, but worth a maintainer looking at both together since it may share a root cause upstream in how the credential-storage/portal retry logic is structured.

Issue Tracking Info

I understand that work is tracked outside of GitHub. A PR will be linked to this issue should one be opened to address it.

Start by reproducing the loop with journalctl -f | grep ashpd on the described KDE/Wayland setup, then trace the desktop credential-storage path responsible for the ashpd property-watch retries. Compare the behavior with #20919 and #22092 without assuming they share the same code path. Done means stale request paths no longer retry forever, resources stop accumulating, and the failure is covered by an appropriate regression test.