Missing gnome-keyring / kwallet interface

Hi all,

As requested I’m re-posting each of the What snap needs to improve Electron support topics individually so they can each be better discussed.

The intention of this post is to highlight an outstanding issue, and hopefully get it priortised, that would help improve snap support for developers building on Electron.

Several very popular applications require the use of gnome-keyring for securely storing user credentials. There is no interface for this right now, the effect is some applications require entry of authentication credentials everytime the application is started while others simply don’t function at all.

This issue is blocking several high profile ISVs.


This sounds like a pretty straightforward interface to implement.

@jdstrand @tyhicks Given the context, any chance someone from the security team might take a look at it? Name for it might be something along the lines of password-manager-service.

The security team discussed this and we’ll implement the interface. It is after some high priority commercial engagement work, but should be able to get to it in time for 2.27.

1 Like

FYI, I’ve started working on this. I can say thus far that the interface will need to be manually connected for (at least) cases that unpatched-for-snappy snaps will need (since the access will grant access to non-specific sensitive user information). Knowing how these things go, as soon as I write the interface I understand in practice the next question will be can every (electron) snap that specifies the interface have a snap declaration granting auto-connection…

@Wimpress, in working through this I was reminded that chromium supports specifying the password backend to use via --password-store=basic|gnome|kwallet (AIUI, chromium defaults to --password-store=detect, but I don’t know what electron-builder/etc does by default). For electron apps, (assuming electron supports it) I suspect you are going to want to use --password-store=basic in electron-builder/documentation/etc and this will store the passwords down in $SNAP_USER_DATA/.../Default/Login Data and thus not need access to either gnome-keyring or kwallet or this interface at all, yet allow password storage by default without a snap declaration. Those snaps that actively want to use gnome-keyring or kwallet will still be free to specify different password stores and this interface of course.


FYI, https://github.com/snapcore/snapd/pull/3525

@Wimpress, please note this from the PR:

Important note regarding electron applications: this interface was requested specifically to enable electron applications to use the password manager (because I wasn’t given an electron snap that saved passwords, I had to use chromium-browser) but I strongly advise that electron applications use --password-store=basic in electron-builder/etc and not automatically include password-manager-service in their plugs since then all electron developers will then start to request an auto-connection of this interface, which would be inappropriate for most applications. Another option would be to have electron applications use --password-store=default which will make chromium try secret-service, then kwallet and fallback to basic and therefore password management would work. This has the added benefit that if the developer wants to plugs password-manager-service, the interface does not have to be connected to have a working password store and the user can opt into it. The downside is this will undoubtedly cause confusion since the probing chromium does will trigger apparmor denials on every launch.

1 Like

I looked at electron a bit more and it seems that it does not offer APIs for password storage (ie, --password-store is a chrome/chromium thing, not an electron thing). Some electron apps use https://github.com/atom/node-keytar (which uses secret-service, which the password-manager-service interface addresses), but electron developers are free to implement password saving using LocalStorage or otherwise.

1 Like

Actually, I may have spoken too soon (I’m not an electron developer). I’ve seen references to --password-store alongside wherever --no-sandbox is specified. Looking at two different electron snaps, it seems this is not something you put on the command line for the snap, but rather a build option for the electron binary. @Wimpress, please confirm.

Regardless, node-keytar is confirmed to work with the new password-manager-service interface. The bits about --password-store is really about what is an appropriate default for an electron app and how electron developers can change it.

1 Like

This will be in 2.27.

1 Like