Request for auto-connection for sendall:password-manager-service

Hi, I am requesting for this as https://snapcraft.io/sendall uses something called node keytar to save login tokens across sessions. Without this auto-connection, it will not be persistent so the user has to re-login every time they re-launch the app if they don’t set the connection manually.

The standard guidance when snaps request auto-connection to the password-manager-service is as follows:

When connecting the password-manager-service, your snap is able to access all stored secrets, but also your snap’s secrets can be accessed by any other applications with access to the service (including snaps which also have the password-manager-service connected). Since this may not be desirable or obvious to users, in general, we discourage auto-connection of password-manager-service and instead suggest that applications using this interface detect its availability (eg, with snap is-connected password-manager-service) and show a dialog with instructions on how to connect the interface manually (eg, with snap connect, the snap store GUI, etc). Ideally when instructing the user, the details of the access will be explained so the user can make an informed choice. While this is an extra step for the user, if done well the process should provide additional trust that your snap and the system as a whole are working together to keep the user’s passwords secure. Alternatively, the snap may choose to store the secrets outside the keyring in an area private to the snap.

Can the snap store these login tokens in say just $SNAP_USER_DATA which is private to the snap?

Is $SNAP_USER_DATA encrypted / can other apps / snaps read it?

The reason why I’m even using password-manager-service is because of node keytar (https://cameronnokes.com/blog/how-to-securely-store-sensitive-information-in-electron-with-node-keytar).

$SNAP_USER_DATA is not encrypted and other unconfined applications can read it, but other snaps can not. However, note that whilst GNOME keyring is ostensibly encrypted with the user’s login password, it is automatically unlocked as soon as they log in and then any application which can access GNOME keyring can access the secrets stored there by other applications. So assuming a user is logged in, the use of $SNAP_USER_DATA is slightly more secure than GNOME keyring (aka password-manager-service) since it is still private to that snap (compared to other snaps) and otherwise is just as open to other applications as the use of the keyring is. Hence why we recommend this over password-manager-service.

Hi is there any other electron dev here who knows if safeStorage.encryptString then storing it in an electron-store in $SNAP_USER_DATA (https://freek.dev/2103-replacing-keytar-with-electrons-safestorage-in-ray) would be a good alternative and would work? Because it seems like safeStorage.encryptString also relies on the user’s keyring to perform the encryption so I’m not sure whether it would work without password-manager-service.

Hi @customautosys do you have any more updates/information on use of $SNAP_USER_DATA for this, so that we can progress this request?

Turns out I can’t use safeStorage unless I use electron 15, while too much of my code relies on the remote module (which was removed in electron 14) and it would be very troublesome to port it to use @electron/remote.

I’m gonna leave this alone for now until I manage to figure out the least problematic way to fix this.

Ok - thanks for letting us know - I will remove this request from our internal queue then for now.