What snap needs to improve Electron support

Hi all,

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

There are a couple of other issues I’m tracking that I need to re-test as a result of some recent updates, but here’s what I have so far.

Missing gnome-keyring / kwallet (secret service) interface

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 correctly at all.

Strictly confined snapped desktop applications can’t toggle Launch at Login

I’ve a PR in progress for the desktop-helpers that works similarly to desktop-exports#L158 that symlinks ~/.config/autostart but I suspect an existing interface needs extending or an additional interface creating?

snapd-xdg-open in Trusty and other distros

This issue is well understood and a lengthy discussion is active in this forum. To breifly recap, many Electron applications need to facility to open URIs and currently this capability only exists in Ubuntu 16.04 and newer.

Media Keys do not work in strictly confined snaps

There are several (one in particular) desirable media streaming applications built on top of Electron or Chromium framework that can integrate with media keys. However, the media keys are not being exposed so it is not possible to skip tracks or play/pause using media keys.

snapcraft fails if desktop file included “ascii” cannot decode byte

Many Electron applications have translated strings in their .desktop files for the Name, GenericName or CommentName fields. Some of the translatated strings include UTF-8 characters and this causes snapcraft to fail.

3 Likes

Note that giving a confined application the ability to write to ~/.config/autostart effectively gives it the ability to run arbitrary code unconfined (although not until the user logs in again). This doesn’t sound like the kind of thing you can solve with a helper inside the snap.

1 Like

Do we have Yarn support yet?

Look at Done: snapcraft 2.29 … there is experimental support for it, yes.

yeah, this probably needs to be a parametrized interface.

I think this is also tracked in bug https://bugs.launchpad.net/snappy/+bug/1613420

We indeed need a way to add startup services (maybe via systemd user session though), and it should be up to snapd to define the command script so that there’s no way for apps to change that…

For legacy apps, not sure if it would be possible to “intercept” access to ~/.config/autostart and then put such generated scripts under confinement, after that they’ve been sanitized.

One more problem that we’ve in Unity starting from zeisty is that XDG_CURRENT_DESKTOP is set to Unity:Unity7, and that breaks the appindicator usage…

An (ugly) workaround that should be probably added in the mean time to the electron-builder is a startup script such as export XDG_CURRENT_DESKTOP=$(echo $XDG_CURRENT_DESKTOP | sed "s,Unity:Unity7,Unity,")

This needs someone to write the interface and submit it. Note this will definitely be a privileged interface until someone works with upstream to make the services enforce application isolation. AIUI, this work is unprioritized. Please escalate via the stakeholder process if this should be prioritized over current work.

I don’t know what this would look like, but @jamesh is right-- we can’t allow exactly what is described here in the forum without it being a privileged interface because it gives a direct path to confinement escape. @Trevinho mentioned session services but this is a bit different. We definitely do need session services but this functionality is about starting a non-daemon automatically on login (though admittedly, if we had session services the snap could write a session service that could start an application in the user’s session if $SNAP_USER_DATA/.config/autostart/foo was present). In addition to the security issues outlined above, each DE seems to handle this differently. This needs design so applications can use a consistent interface that works across DEs.

I suspect it is something similar to how we handle desktop files: the snap puts a desktop file somewhere in the snap, and snap run provides a facility that the application can use (snapctl? dbus session service?) to request putting a sanitized version of that file in place. For existing applications, the desktop part could help: we know that $HOME is set to $SNAP_USER_DATA, the snap is allowed to write whatever it wants there, including to $SNAP_USER_DATA/.config/autostart. The desktop part could check if this file exists and if it does, use the aforementioned facility (snapctl? dbus session service?) to put the sanitized version in place. Or, the desktop part could use the session service idea (above).

Again, these are just otoh idea and needs design.

Can you verify this is still broken? I verified that https://bugs.launchpad.net/snapd/+bug/1663565 is fixed. If those fixes were incomplete, please file a new bug.

1 Like

Most utf-8 issues should be fixed, feel free to confirm by getting the latest snapcraft from the edge channel.

2 Likes

Sorry, bad news :frowning: I’ll update the LP issue.

@Wimpress Thank you very much for bringing those issues up. Can you please break these down into independent topics?

Otherwise the conversation gets very fragmented and general. The topic summary is not indicative of anything in particular, for example, and there’s no way to tell what anyone here is talking about without actually reading all of it.

I’m closing this topic for that reason, but please don’t feel discouraged. Your input is welcome, and actually deserves better answering and tracking which can only be achieved if we organize the conversation properly.

1 Like