Linux: secrets go to libsecret’s file backend when debugging from Rider (snap), not the Secret Service #205

Activity

1. matt-edmondson commented on Nov 6, 2026

   

   matt-edmondson

   on Nov 6, 2026 – with Claude

   Contributor

   More actions

   Triage

   • Category: Improvement (documentation, plus an optional diagnostic). This is not a CredentialCache bug. libsecret picks its own backend, and when it detects a sandbox (SNAP_NAME, or flatpak's equivalent) it uses the portal-keyed file backend (~/.local/share/keyrings/*.keyring) instead of the Secret Service. The library calls secret_password_*_sync, so it inherits that choice.
   • Priority: Low. Secrets still persist, and the file is still encrypted with a portal-supplied key. The real cost is surprise: where the data ends up depends on how the process was launched. This affects debugging from a snap IDE, and also any consumer that actually ships as a snap or flatpak.
   • Area / suggested assignment: README.md, the "Linux runtime prerequisites" and platform-notes sections. If the diagnostic is wanted, also CredentialCache/Storage/LinuxSecretServiceCredentialStore.cs, whose Name is a fixed string ("Linux libsecret (Secret Service)"). That is why Store.Name looked the same in both runs.
   • Duplicates / in progress: Not a duplicate. The other open Linux issues (Linux: personas "alice" and "alice\0mallory" (or two lone-surrogate variants) share one Secret Service entry, so after a restart one loads, overwrites and deletes the other's secret #199, Saving a credential leaves its plaintext JSON in ArrayPool<byte>.Shared: zeroing the byte[] from SerializeToUtf8Bytes misses System.Text.Json's pooled copy #185) are about key collisions and memory scrubbing. No open PR touches this. The open PRs Ignore Dispose on the process-wide Instance [patch] #202, Write credential JSON with relaxed escaping so Windows' blob cap counts real bytes [patch] #203 and Refuse a null non-nullable credential property when reading or saving [patch] #204 cover other things.
   • Next steps:
     1. Add a README note: under snap or flatpak, or with SNAP_NAME set in the environment (Rider and other snap IDEs pass it to debugged processes), libsecret writes to its file backend rather than the Secret Service. Give the reporter's workaround: unset SNAP_NAME before the first store call in debug builds, or run the IDE outside the snap.
     2. Optional: have Name (or a new property) report the backend libsecret will actually use. The store would detect the same sandbox signals libsecret checks, and avoid claiming "Secret Service" when it is not.
     3. Check which SECRET_BACKEND value, if any, forces the service backend in the libsecret version Ubuntu ships, and document it if one works.

   Thanks for the detailed report and the timestamp check. It makes the cause clear.

   ---

   Generated by Claude Code

   👍React with 👍1Reacted by oopsypoo
2. oopsypoo commented on Nov 6, 2026

   

   oopsypoo

   on Nov 6, 2026

   Author

   More actions

   I looked at https://github.com/GNOME/libsecret
   And it is allready "documented" at the top of their README-file. I'm not going to investigate any further. Thanks for the reply:
   A GObject-based library for storing and receiving secrets. libsecret provides a convenient wrapper around two different mechanisms: If available, secrets are stored in the freedesktop secret service. Otherwise, secrets are stored in a file that is encrypted using a master secret that was provided by the secret portal.
3. matt-edmondson commented on Nov 6, 2026

   

   matt-edmondson

   on Nov 6, 2026 – with Claude

   Contributor

   More actions

   Triage

   Re-triaged because the reporter replied after the earlier triage.

   • Category: Improvement (documentation). This is still not a CredentialCache bug. The reporter confirmed that libsecret's own README documents the file-backend fallback, and they won't be investigating further.
   • Priority: Low
   • Area: README.md, Linux runtime prerequisites
   • Duplicates / in progress: None. No open PR covers it; Ignore Dispose on the process-wide Instance [patch] #202, Write credential JSON with relaxed escaping so Windows' blob cap counts real bytes [patch] #203 and Refuse a null non-nullable credential property when reading or saving [patch] #204 are unrelated.
   • Next step: The maintainer picks one: (a) add a short README note that a sandboxed launch (snap/flatpak, or SNAP_NAME inherited from a snap IDE such as Rider) makes libsecret use its portal-keyed file backend, with a link to libsecret's README, then close; or (b) close as upstream behaviour. The optional backend-reporting Store.Name from the earlier triage only needs doing if someone asks for it.

   Thanks again for following up on this.

   ---

   Generated by Claude Code