Possible bug or feature ? Storing/Getting data keyring: protected vs unprotected keyring

Hey all,

First of all to clear things up, I’ve read how-are-keyring-items-secured-encrypted-in-default-collection-vs-other-collections so I know a bit of what to expect from the expected keyring behavior.

General Context
I’m working on a python app that relies on the keyring package to store tokens and other sensitive data to the keyring. This keyring package provides multiple default backends, of which the app specifically uses SecretService (makes use of the SecretStorage package behind), as the app currently relies on gnome-keyring. The app stores json data to the keyring with json.dumps(data_to_store), and whenever it reads data from keyring it does the following json.loads(stored_data).

Problem/Feature: pre-conditions
So this all starts with the following pre-conditions:

  • User installs (from the ones I tested) Ubuntu 22.04 and Fedora 39
  • User sets no password for the account during install (for Fedora it’s not possible to set empty password, see below)
  • User select to auto-login during Ubuntu install
  • After distro install is complete
    • Install any updates
    • For Fedora:
      • Install Password app (aka Seahorse)
      • Open Password app, right-click on Login and select Change Password, set new password to empty
      • Go into user settings and set to auto-login
    • Install python app
  • The previous SecretService is used for keyring communication

Problem/Feature: context
Once the distro boots, the keyring by default is locked, which by launching our app, it requests access to the keyring. Once the user unlocks the keyring, the login process can continue.
The app stores json data to the keyring as previously mentioned, and this is where the confusion happens. The data that we stored, apart from being normal json it also contains public keys, which obviously contain newlines:

"-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----\n"

As you can see, it contains \n in there, but apparently there seems to be an inconsistency in the behavior when storing to the keyring, depending if it has a password or not.

I did most of my testing with the SecretService backend from the keyring, I also tested using the libsecret backend provided by the same keyring package, and the results were basically the same. In the end I even tried with the secret-tool and the outcome was also the same.

Problem/Feature: description
The problem is that when we store and get data that contains \n, it sometimes is treated as literal new lines. To ensure that the data was properly formatted before storing it to the keyring, it was confirmed during experimentation that all new line instances are properly escaped, meaning that all \n became \\n.

  1. When the keyring has no password and we attempt to get the data for some reason the output we get is with literal new lines \n instead of it being escaped \\n.
  2. When the keyring has a password and we attempt to get the data, the output we get is with the new lines escaped as we’d expected \\n.
  3. In both cases, before storing the data to keyring we ensured that all \n were escaped \\n.

As you can see from the above examples, in the app once it reaches the line to json.loads(stored_data), in 1) the app crashes because it’s attempting to parse literal new lines and the json is not able to load the data properly, while in the 2) since the new lines are escaped there are no issues.

Given that I have tried this via both SecretService and libsecret backends from the keyring package, and have also used the secret-tool tool, I’m assuming the issue is with gnome-keyring and not with any of these communication backends, see screenshot below for my tests with secret-tool in both Ubuntu 22.04 and Fedora 39.


Posted on gitlab: Bug storing/retrieving converted json data: differente behaviours when keyring is password protected vs when not (#147) · Issues · GNOME / gnome-keyring · GitLab

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.