Unencrypted gnome-keyring file is corrupted on write (PEM/JSON newlines); v0.0.2 read workaround is not enough

[BVisagie]

Summary

Storing a Proton session in GNOME Keyring corrupts an unencrypted (passwordless) keyring file on disk. After gnome-keyring-daemon restarts, the whole default keyring fails to load — not just the Proton item.

The v0.0.2 / #1 workaround only repairs read (json.loads after replacing literal newlines). It does not stop the daemon from writing those newlines into the INI file, so it cannot help once the file is unreadable.

This is the remaining half of the long-running GTK keyring reports (proton-vpn-gtk-app#100, and earlier #8 / #16 / #30 / #35).

Environment

• python-proton-keyring-linux 0.2.3 (current Arch/proton-vpn-cli 1.0.3 stack)
• gnome-keyring 50.0
• Passwordless default keyring (Omarchy and other autologin setups do this on purpose)

What happens

1. KeyringBackendLinux._set_item stores json.dumps(value) via Secret Service. The payload includes PEM material (-----BEGIN …-----) with real line breaks.

2. Encrypted GNOME keyrings use a binary format and survive this.

3. Unencrypted keyrings are GKeyFile / INI. GNOME Keyring writes those line breaks as literal newlines in secret=.

4. On the next daemon start:

   gnome-keyring-daemon: keyring was in an invalid or unrecognized format: ~/.local/share/keyrings/Default_keyring.keyring
   

5. The Default collection never loads. Any app that needs a secret then prompts “Choose password for a new keyring called Default”, looping until cancelled. Other stored secrets (gh, browsers, Bitwarden, …) are unreachable until the Proton item is removed or the newlines are escaped in the file.

Confirmed here: after protonvpn signin, the Proton SSO account item in Default_keyring.keyring contained a JSON blob whose ClientKey / Certificate fields spanned many lines. Removing only that item made the keyring load again.

Why the existing fix is not enough

KeyringBackendLinuxSecretService._get_item already documents the gnome-keyring behaviour and retries:

stored_data = stored_data.replace("\n", "\\n")
return json.loads(stored_data)

That only runs if the daemon can still serve the secret. After a reboot it cannot, because it refuses the file.

_set_item still does:

json_data = json.dumps(value)
self.__keyring_backend.set_password(self.KEYRING_SERVICE, key, json_data)

json.dumps emits \n escapes, but GKeyFile on an unencrypted keyring round-trips those into real newlines and then persists them unescaped. Proton staff already described the password vs no-password mismatch on GNOME Discourse.

Suggested fix (in this backend)

Make the stored secret safe for a textual keyring, independent of gnome-keyring’s writer:

• Base64-encode (or otherwise flatten) the JSON blob before set_password, decode on get; or
• Strip / join PEM line breaks before dump; or
• Store tokens in the keyring and keep bulky PEM out of Secret Service.

Any of those would work for both encrypted and passwordless keyrings. GNOME should still escape newlines in unencrypted files (gnome-keyring#103, #147), but clients that store PEM/JSON can avoid bricking every other app’s secrets today.

Reproduce

1. Use a passwordless default GNOME keyring (empty password / Omarchy-style Default_keyring.keyring).
2. protonvpn signin (or equivalent GTK sign-in) so a session with certificates is stored.
3. systemctl --user restart gnome-keyring-daemon
4. Observe invalid or unrecognized format and the “new Default keyring” prompt.

Happy to test a write-side patch.

[megascan]

Me too

Hit the same failure on Omarchy (Hyprland) after an update reboot.

Environment

• Distro: Omarchy (Arch-based)
• python-proton-keyring-linux 0.2.3-1 (Arch extra)
• proton-vpn-gtk-app 4.17.2-1
• proton-vpn-cli 1.0.3-1
• gnome-keyring 1:50.0-1
• Passwordless / unencrypted ~/.local/share/keyrings/Default_keyring.keyring (Omarchy-style default)

What happened

1. Proton SSO session was stored in the default keyring (item display-name like Password for 'proton-sso-account-…' on 'Proton').
2. That item’s secret= value contained PEM material (-----BEGIN …----- / certificate JSON) with literal newlines, which broke the textual GKeyFile/INI keyring format.
3. While the session stayed up, secrets still worked from the in-memory daemon.
4. After reboot, gnome-keyring-daemon logged:

   keyring was in an invalid or unrecognized format: .../Default_keyring.keyring
   

5. The Default collection never loaded. A prompt created a new empty Default Keyring, Chromium/Helium got a new “Chromium Safe Storage” OSCrypt key, and every browser site looked logged out / wiped until the old keyring was repaired and pointed back as default.

Confirming the write-side gap

Agree with this issue: the existing read-side replace("\n", "\\n") workaround in KeyringBackendLinuxSecretService._get_item cannot help once the daemon refuses the file. Flattening/base64’ing (or keeping PEM out of Secret Service) on _set_item would have prevented bricking every other app’s secrets.

Recovery that worked here

• Re-wrote the broken Proton secret as a proper GKeyFile multi-line value (or removing that Proton item alone would also make the keyring load again).
• Restored ~/.local/share/keyrings/default → Default_keyring (away from the empty replacement).
• Unlocked the repaired collection; all prior items including Chromium Safe Storage came back.

Happy to provide sanitized logs if useful (daemon “invalid format” lines, package versions above). Please don’t ask for the raw keyring file — it contains live secrets.