From a security standpoint, I’d be happy if sideloaded snaps weren’t made to be easily installed through GNOME Software and they remain only installable through the snap command line client.
I think it does make sense to support the installation of classic snaps in GNOME Software. I don’t have much to add outside of what I’ve already mentioned in the bug. To summarize, I’d like to see a clear warning displayed to the user. A prompt is not necessary, IMO, as long as the warning is in close proximity to the Install button.
But Debs can be sideloaded and they’re less secure because they’re not confined?
I guess there’s no reason not to upload a snap to the snappy store though and it’s really not very difficult, whereas it’s more difficult to upload a Deb to a PPA (and expect users to add the PPA) or the Ubuntu repositories and keep it up-to-date…
However, if we want to enable user-friendly offline installs (and offline updates), then we need the ability to sideload snaps using GNOME Software.
If there was a way to install .snap files and .assert files graphically that would be useful, then you could install a signed snap, by installing the .assert file, then the .snap file.
Are there any limits on the contents of classic snaps? Being able to search in GNOME Software and with a single click install it seems a very easy way to install a malicious package. In comparison, you have to opt-in to a PPA before this is possible in the .deb world.
No, there are no limits for what is in the snap or what it can do, but all snaps using “confinement: classic” require a snap declaration to allow that publisher to use classic for that particular snap. There are a series of questions that are asked by the store reviewers (usually asked by the advocacy team, eg @evan, @JamieBennett, etc) to determine if the request is reasonable and from a reputable publisher/upstream.
I agree with @tyhicks that users installing classic snaps should be able to see easily that the snap is a classic snap with information on what that means. This is important so that they know that it isn’t confined at all and also because they may have different criteria for what to install on their systems than the store reviewers for what is included in the store.
Note that the warning is only visible if the window is tall enough, otherwise you would have to scroll down to see it.
I’m concerned that this is not visible enough, but as pointed out classically confined snaps are considered reviewed by the store. Can design / security confirm if this is suitable?
I find the wording of the warning way to tame since this snap “will have access to all your files”, not just documents, but also dot-files with passwords, browser cookies and whatnot …
Note that it is typical for packages installed from the software center to have access to all the users’ files. What is different here is that this is a binary package coming from a 3rd party that is only accepted based on trust between the party and the reviewers from the snap store. I think this is what needs to be emphasized.
Yes, but compare the wording on the Atom page and on the page of any other non-snap app in the software center. All those other apps can access your documents and cookies.
We do support installing classic snaps but we don’t support sideloaded snaps. There doesn’t seem to be a strong demand for sideloading and the security opinion seems to be they aren’t a good idea.
I just tried installing Slack (which uses classic confinement) using Ubuntu 17.04, with this error message: snapd returned status code 400: Bad request and so used the terminal. Is there a fix in the works?
What defines sideloading a snap? Is it installing a snap that has not be signed by the store?
Sideloading is an archaic term that we’ve been trying to avoid because it doesn’t covey the meaning of the actual case at hand.
There are two possible installations that can happen in the local system:
Installing a local snap that has proper signatures. That operation is completely fine as far as snapd is concerned, with almost no differences compared with an installation directly from the store.
Installing a local snap that is unsigned. That’s considered a dangerous operation, because the content and the origin of that snap are completely unknown. It also has no revision information, so snapd creates a local sequence for the snap (x1, x2, …).
By sideloading I mean installing a snap from a .snap file. The ‘side’ refers to coming from a side-channel rather than the standard snap channel (i.e. from the store). We currently support neither of the cases that @niemeyer listed on GNOME Software, instead requiring the user to use the command line to do this.
Ubuntu 17.04 is end-of-iife - did you mean 17.10? Which version of GNOME Software is this?
Right, that’s the historical meaning, which we’re avoiding because it’s a bit confusing. A local snap file may be a fully supported installation operation, completely blessed with signatures and everything else, and it may also be a dangerous operation, as explained above. So the fact the snap is local is not meaningful by itself.
We suggest using the term “unsigned” for the dangerous operation, and simply a “local install” for the other case, which isn’t really too special as far as snapd is concerned.
If a user sideloads a signed snap (local install), will that be detectable using gnome software? As in will be able to launch/remove it? I’m assuming it uses the conventional revision system as it has passed through the store at some point.
It was with 17.04, I don’t know what version of gnome software was running at that time. I updated to 17.10 last night and I’m having issues trying to boot the computer . I’ll troubleshoot today and get back to you.
Yeah, this documentation is all being taken away from GitHub and polished. For the API docs we’ll also want to split it up into smaller pages and review content and format.
. I’ll troubleshoot today and get back to you.
