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.