description: Extensible software platform used to build Bible translation tools. It’s built using Electron and runs on Linux, macOS, and Windows.
snapcraft: We’re using electron-builder so there isn’t a full snapcraft file available, but here is the relevant electron config for the password-manager-service interface we’re requesting.
upstream-relation: I am one of the developers working on this project.
interfaces:
password-manager-service:
request-type: auto-connection
reasoning: We are using Electron’s safeStorage API to store authentication tokens and other secrets. The API doesn’t work in snaps without connecting the password-manager-service interface. We would like for people who aren’t familiar with running commands from a terminal to be able to run our application without having to run additional commands to connect this interface after installation.
We read the comments about password-manager-service from 2 years ago in the process post, but we don’t see any prompting API mentioned in the NordPass post from 5 years ago or other ways that avoid having the user pull up a terminal and run a command we tell them to run then restart the application (which also seems like a bad habit to train users to follow). We’re not sure if the stance on password-manager-service is still the same or if there are any other workarounds suggested at this point.
Note that if this is approved, I will have one more, similar request in the near future for another tool built on top of this framework.
Can you confirm you need this interface with the Gnome extension in use and on a modern version of Electron?
Electron can use libsecret, libsecret should be capable of identifying it’s sandboxed and using the XDG portals to facilitate transactions with the secret store. If you’re using this as a consumer and not a provider (I.E adding secrets for yourself to use and not reimplementing an entire password manager itself) - then this should be completely automatic on modern systems. This would allow the application to store the secret outside the snap with just the desktop interface.
Edit: FWIW I’ve tried this with one of my own snaps and it doesn’t actually work (joplin-desktop) so maybe although the implementation is theoretically available, it’s not working quite right in an Electron environment. (Ubuntu 25.04)
We tried using the safeStorage API from Electron without connecting this interface, and it failed. When you say “the Gnome extension”, what do you mean exactly? We’re on Electron version 36.5 right now which is not very old (months at most).
We’re using the safeStorage API in a pretty basic way and are not trying to be a general password manager. We just don’t want to be storing secrets on disk unencrypted.
While Electron could choose to implement their safeStorage API in multiple ways, it looks like they are leaning on os_crypt in Chromium to handle encryption/decryption. I’m not well versed in Chromium’s code or the low level Linux libs for doing this, but from my experience there is no straightforward way around this permission when using Electron’s API.
Sounds ideal for the XDG API - the caveat from the interface is that the portal approach limits your snap to only being able to see its own passwords/secrets, outside the sandbox, any process can see all secrets; so you should be fine if you’re only dealing with your own tokens.
Since you’re not using snapcraft itself I guess the terminology doesn’t really appear for you much - snaps build without Electron Builder often make use of an “extension” which acts as a wrapper for common desktop environments and their ecosystems libraries, and sets up things like GPU drivers. Gnome and KDE both have an extension. I think from what I’ve seen, Electron Builder does use these extensions automatically, without ever referring to them. I’d have hoped/expected that having the Gnome extension would provide enough gnome-libsecret to get Safestorage working for you with the portals powering the actual storage.
So you’re in a scenario where reasonably things should “just work” but aren’t, and there’s a decent chance there’s something wrong in the ecosystem here that might need tweaking, I can have a go looking into this myself since I’m in a fairly ideal spot to benefit from getting it to work (that notebook app would have the same concerns as yourself, basically, since its E2E encryption keys stored on disk if it’s not working), but it could be a wide range of issues in a lot of different places.
Unfortunately I doubt you’d get autoconnection on that interface reasonably, but in essence, any Core22 snap that uses libsecret should “just work” for this usecase with the portals, that’s how it’s been told to me, so I’m hopefully there’s maybe just something somewhere that needs a tweak to make it so.
I suppose in this case if we decide to essentially ignore what Electron provides via safeStorage and build our own just for Linux we might be able to get around the need for this interface. Since our app is meant to be cross-platform and we’re trying to avoid doing platform-specific things as much as possible, I’m not sure if we would do that or fall back to telling users to run the snap connect command.
This does not appear to work for me. I asked another developer who has been working on this problem, too, and he said that the safeStorage.isEncryptionAvailable() API always returns false regardless of any other settings without connecting the password-manager-service plug.
We don’t grant auto-connection to password-manager-service interface in most cases, it gives the snap access to all session secrets, what does not fit great the confinement mode.
Portals are the correct approach when possible, as they give the snap access to the secrets created by itself but not all secrets in the system. Access to the secret-portal is granted by the “desktop” interface, and libsecret should handle everything seamlessly in newer releases.
When libsecret detects that it is being used in a confined environment (i.e. it does not have raw access to the secret storage) it tries to access the secret storage via the secret-portal. In this case, Instead of storing the password directly to the secret storage, libsecret stores the password locally encrypted with an encryption secret unique to the application, which it is stored in the secret storage via the secret-protal.
All this magic is seamless to the application as libsecret handles it behind the scenes. Related PR can be found:
However, as portals rely on the gnome-keyring version installed in the host systems, it only works properly when this version supports the secret-portal backend. I’ve been able to run a proof-of-concept in Ubuntu 22.04 and newer releases. So an option would be to use the secret-portal when present (it can be detected in the same way than libsecret does), and use fallback to less secure alternatives, such as disk storage.
OK, thanks for the confirmation. I was guessing that it wouldn’t be granted, but I thought it made sense to request the auto-connection just in case something had changed that I didn’t see.
We will have to see if there is anything else we can do with the electron configuration to make this work without the interface. Since some users might be using a different secret store, we probably need to leave the interface in our configuration as a fallback. It will just have to be manually connected.
My assumption is it should still work though as it’s actually offloading the functionality to the XDG portals, which means e.g., KDE would have its own portal implementation, as Jorge explains above.
Reasonably I’d assume that you’d be able to hardcore gnome-libsecret then to be the only provider, but, even on Gnome Ubuntu 25.04 it doesn’t work in Electron specifically from what I can see. If it would work on Gnome, I’d expect through the portal system, it would work on KDE.
As you have already pointed out, it relies on gnome-keyring and this is not available on KDE or other environments. Even with gnome-keyring it doesn’t work properly, and electron uses kwallet in KDE as you can see in the docs.
Interesting… Considering that storing secrets is a common need for many apps and I consider it to be critical, I think we will need to work to streamline its usage. I try to find the time next cycle to create a compatibility matrix and examples for most common use cases.
