NordPass auto-connect to password-manager-service interface

NordPass ( is a password manager and we want to use native keyring/keychain to store some of our secret keys. For that we need to connect to password-manager-service.

We are planning to release our desktop app soon. Currently it is uploaded to snap but hidden. Not sure if we need to make it public for this process, let us know if that is the case.

By connecting to the password-manager-service, secrets can then be accessed by any other snaps which also have the password-manager-service connected - which may not be desirable or obvious to users. In general, we discourage auto-connection of password-manager-service as a result and instead suggest that applications which wish to use this interface detect that it is not available and show a dialog or similar to the user to prompt them to connect the interface manually. This allows the user to be aware of the possible consequences. Otherwise perhaps it is better to store the secrets outside the keyring so that it is private to the snap itself.

I agree with @alexmurray. I’ll also mention that detection is easier this days and from within the snap can do snapctl is-connected password-manager-service. Eg,

# inside the snap, when disconnected
$ snapctl is-connected password-manager-service && echo yes
# inside the snap, when connected
$ snapctl is-connected password-manager-service && echo yes

-1 to auto-connect

Any app that has access to keyring can see all other apps secrets. This is the same on all OS. I can see why it might be an issue, since linux users are in general more security conscious. On the same note, storing secrets outside keyring, means storing it on a file and that is not good for our case.

The only problem with your proposal is that users will have to manually enter a command in terminal. It would be really nice if it would be possible to show some kind of permission request windows that would connect this interface from UI.

I agree that it is desirable for nordpass to store its passwords in the keyring, but it is important to remember that in the snap ecosystem there are several voices when considering auto-connection: snapd (base declaration policy), the gadget snap (for device-specific auto-connections, does not apply here), the store (snap declaration policy; ie, this request) and the user. We’ve determined that the various keyring services do not provide sufficient isolation for snap access for the interface to be auto-connected by default (since not only can your snap see all stored passwords, but all other applications with access to the password services can also see your snap’s passwords). Reviewers have historically voted to not auto-connect this interface due to the sensitive nature of the access and because preserving the user’s voice in this sensitive access is so important.

Today, snaps may choose to either check the access is available and instruct the user to run an additional command (either snap connect or via the snap store GUI) or fallback to storing passwords locally. Ideally when instructing the user, the details of the access would be explained so the user could make an informed choice. It is true that there is an extra step for the user, but done well, this need not be onerous and may even provide additional trust that your snap and the system as a whole is working to keep the user’s passwords secure.

In the future, the snapd team plans to provide a prompt API for snaps to use that will not only provide appropriate messaging, but also allow the user to choose to connect within the prompt.

Finally, the desktop team has discussed the lack of isolation in secret-service with upstream GNOME and there are plans to improve the service to provide the necessary isolation for auto-connecting. Hopefully, KDE/Plasma will follow with kwallet or move to the improved service.

Thank you for an in-depth answer. We decided to ask users to enter snap connect command for our case.
I look forward to prompt API and secret service improvements you mentioned.

1 Like