5 ms·

> The only 'con' is the pushing of Snap packages. It looks like deb files only can be installed via the terminal. My main concern with Snap is security. Using

> The only 'con' is the pushing of Snap packages. It looks like deb files only can be installed via the terminal. My main concern with Snap is security. Using the default Ubuntu Apt repositories, I can `apt install` pretty much anything I want and it's almost guaranteed to not be malicious/dangerous, as only trusted/well-established developers can get their package into the Apt repos. However, with Snap, everybody in the world can publish any old rubbish in the Snap Store, including packages that typosquat the names of others. Snap's current 'protections' for this are mainly reactionary rather than preventative, which is far from satisfactory [1]. For me, the absolute key selling point of Linux over Windows/Mac is the secure-by-default and natively integrated package management. Pushing Snaps as the main package management method goes too close to the Windows way of just downloading random EXEs from the internet. I personally would like to see Apt remain as the default system package manager for all common/well-known software, with Snap existing purely as a 'community' repository for software that is known to be untrusted/unknown. [1] https://forum.snapcraft.io/t/is-there-any-protection-against-typosquatting-on-the-snap-store/10815 https://forum.snapcraft.io/t/is-there-any-protection-against...

ric2b 6y ago
This could be fixed by separating the store into an "official" repo that only includes trusted apps and an opt-in "community" repo with the rest. It's not really an issue with snap itself.
- O_H_E 6y ago
  It kinda is. Canonical explictly doesn't want to do that. The cli doesn't support any other server except canonical's.[1] Flatpack on the other hand, does support that structure out of the box, and a few projects are already using there own repos.[2] [1] https://forum.snapcraft.io/t/external-repositories/176 https://forum.snapcraft.io/t/external-repositories/176 [2] https://docs.flatpak.org/en/latest/repositories.html https://docs.flatpak.org/en/latest/repositories.html
modzu 6y ago
there's debian!
bsharitt 6y ago
>However, with Snap, everybody in the world can publish any old rubbish in the Snap Store, including packages that typosquat the names of others. This is why I don't bother installing snaps unless the developer themselves are actually providing(or at least promoting) the snap. There's been a couple of occasions where I went to install the snap and it turned out to either be an old or broken version of the software. I don't have too many technical quibbles with snaps, it's just the way Ubuntu has the ecosystem setup now.
teekert 6y ago
This is a bug and is already fixed, debs can be installed by clicking. (Source: Alan Pope in the Ubuntu Podcast Chatter Telegram channel)
- jamieweb 6y ago
  What do you mean? I'm assuming that this is a Snap Store feature? My concern is really more about the command-line, as that's how I (and probably most technical users) install packages.
  - teekert 6y ago
    I guess my reply should be one level lower, it was an answer to "It looks like deb files only can be installed via the terminal."
    - deadbunny 6y ago
      I think OP is refering to snap being the default application install in the gui now rather than apt.
danieldk 6y ago
I can `apt install` pretty much anything I want and it's almost guaranteed to not be malicious/dangerous, as only trusted/well-established developers can get their package into the Apt repos. Maybe not malicious, but packages in the universe repos only have 'community maintenance', meaning that they are not updated with security fixes in any systematic manner. Given that you need universe to have a somewhat useful system, most people's systems are full of known holes: https://people.canonical.com/~ubuntu-security/cve/universe.html https://people.canonical.com/~ubuntu-security/cve/universe.h...
- InternetOfStuff 6y ago
  > meaning that they are not updated with security fixes in any systematic manner. Interestingly, that exact thing was always my worry about Snap (or Flatpack) as well. Sure, big-name software such as Spotify will keep their Snap package well in order; they've got both the incentive and manpower to do so. (Incidentally, they could also use this manpower to build distro-specific packages). But what about all the little open-source hobby projects? They'll be packaged with whatever library version happens to be latest at the time. And then, be updated whenever the hobbyist dev finds the time and inclination. So on my system I might have a huge zoo of different versions of the same library, with various bugs or vulnerabilities. If they all used the same system-wide library, at least they would all be fixed at the same time (when the library maintainers publish an updated .deb). To me, Snap and the like feel like they're essentially the same as static linking, except more opaque.
  - kingosticks 6y ago
    Spotify aren't doing a great job with their Snap, it's been a few versions behind Mac and Windows for a while now. They could do with more dev manpower.
    - InternetOfStuff 6y ago
      Heh, interesting, didn't know that. I was just trying to pick a random example.
kd913 6y ago
The amount of cases for malicious snaps was about 1 with the cryptominer that was addressed within 3 days. Those snaps that are published go through static analysis and unless manually vetted will not have access to the rest of your system. You install it, at worst it will cryptomine that is it. Oh and you can remove it completely with all traces unlike deb equivalents. Snaps come with a tick against verified snaps coming from first party. Such as those from Jetbrains, Mozilla, Microsoft, Amazon, Spotify etc.. If you are downloading from a software center this would all be handled for you and typo squatting will not be a problem. In contrast with debs, the person who owns the PPA for those third party packages do have unfetted, root access to the system. The most popular PPA to this day is a closed down Java PPA run by 3rd party dev. That could easily turn malicious easily.
- GordonS 6y ago
  I don't know much about the Snap system - regarding 3rd parties and the "tick", is this using domain verification, or some other means? Do 3rd parties have to pay for this? I read something the other day about needing to pay Canonical $15k/y for a branded Snap store, but I'm not sure if that was about private stores, this, or something else.
  - jamieweb 6y ago
    Another point is that when installing Snap packages from the command-line, the verification tick only appears after the install has finished, by which point it is already too late. You can view package info prior to installing, but if we're talking about a typosquatting issue here, that doesn't really help.
  - kd913 6y ago
    I think the main mechanism of this is communication directly with developers on forum.snapcraft. In this case Mozilla with Canonical etc... I didn't go through this process so I don't really know. I think that is how it has worked so far for all of the 1st party snaps I have seen.
- jamieweb 6y ago
  I was specifically talking about the default, trusted Ubuntu Apt repositories, not custom PPAs which are of course inherently untrusted. > You install it, at worst it will cryptomine that is it. If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing. > Oh and you can remove it completely with all traces unlike deb equivalents. Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed. In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.
hajile 6y ago
Don't forget performance. SquashFS has terrible IO performance and you pay that price every time you open an application. https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-format/9466 https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-... There's an even bigger security hole with Snaps. If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again. Very few (if any) dev teams are that well connected to the development of their dependencies. In contrast, the developers of those dependencies will be very well connected.
- rlpb 6y ago
  > If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again. Snaps compete with third party apt repositories, not distribution-provided packages (but see below). I've seen a general trend in complex upstreams _bundling_ their dependencies even in builds destined for apt/deb -based distribution via third party apt repositories - because handling differing dependency versions across every distribution release is too complex. In this case, your distinction is moot. In both situations it is up to the upstream developers to update their dependencies. Only that with snaps, their sandboxing security model provides some mitigation. It is true that some packages traditionally shipped by the distribution are moving to snaps, such as Chromium. This is because these packages are moving to bundling anyway, because updating them during the lifetime of a stable distribution release has become impossible any other way, due to the same dependency pain.
  - deleted 6y ago
    [deleted]

ric2b 6y ago

This could be fixed by separating the store into an "official" repo that only includes trusted apps and an opt-in "community" repo with the rest. It's not really an issue with snap itself.

O_H_E 6y ago
It kinda is. Canonical explictly doesn't want to do that. The cli doesn't support any other server except canonical's.[1] Flatpack on the other hand, does support that structure out of the box, and a few projects are already using there own repos.[2] [1] https://forum.snapcraft.io/t/external-repositories/176 https://forum.snapcraft.io/t/external-repositories/176 [2] https://docs.flatpak.org/en/latest/repositories.html https://docs.flatpak.org/en/latest/repositories.html

modzu 6y ago

there's debian!

bsharitt 6y ago

>However, with Snap, everybody in the world can publish any old rubbish in the Snap Store, including packages that typosquat the names of others. This is why I don't bother installing snaps unless the developer themselves are actually providing(or at least promoting) the snap. There's been a couple of occasions where I went to install the snap and it turned out to either be an old or broken version of the software. I don't have too many technical quibbles with snaps, it's just the way Ubuntu has the ecosystem setup now.

teekert 6y ago

This is a bug and is already fixed, debs can be installed by clicking. (Source: Alan Pope in the Ubuntu Podcast Chatter Telegram channel)

jamieweb 6y ago
What do you mean? I'm assuming that this is a Snap Store feature? My concern is really more about the command-line, as that's how I (and probably most technical users) install packages.
- teekert 6y ago
  I guess my reply should be one level lower, it was an answer to "It looks like deb files only can be installed via the terminal."
  - deadbunny 6y ago
    I think OP is refering to snap being the default application install in the gui now rather than apt.

danieldk 6y ago

I can `apt install` pretty much anything I want and it's almost guaranteed to not be malicious/dangerous, as only trusted/well-established developers can get their package into the Apt repos. Maybe not malicious, but packages in the universe repos only have 'community maintenance', meaning that they are not updated with security fixes in any systematic manner. Given that you need universe to have a somewhat useful system, most people's systems are full of known holes: https://people.canonical.com/~ubuntu-security/cve/universe.html https://people.canonical.com/~ubuntu-security/cve/universe.h...

InternetOfStuff 6y ago
> meaning that they are not updated with security fixes in any systematic manner. Interestingly, that exact thing was always my worry about Snap (or Flatpack) as well. Sure, big-name software such as Spotify will keep their Snap package well in order; they've got both the incentive and manpower to do so. (Incidentally, they could also use this manpower to build distro-specific packages). But what about all the little open-source hobby projects? They'll be packaged with whatever library version happens to be latest at the time. And then, be updated whenever the hobbyist dev finds the time and inclination. So on my system I might have a huge zoo of different versions of the same library, with various bugs or vulnerabilities. If they all used the same system-wide library, at least they would all be fixed at the same time (when the library maintainers publish an updated .deb). To me, Snap and the like feel like they're essentially the same as static linking, except more opaque.
- kingosticks 6y ago
  Spotify aren't doing a great job with their Snap, it's been a few versions behind Mac and Windows for a while now. They could do with more dev manpower.
  - InternetOfStuff 6y ago
    Heh, interesting, didn't know that. I was just trying to pick a random example.

kd913 6y ago

The amount of cases for malicious snaps was about 1 with the cryptominer that was addressed within 3 days. Those snaps that are published go through static analysis and unless manually vetted will not have access to the rest of your system. You install it, at worst it will cryptomine that is it. Oh and you can remove it completely with all traces unlike deb equivalents. Snaps come with a tick against verified snaps coming from first party. Such as those from Jetbrains, Mozilla, Microsoft, Amazon, Spotify etc.. If you are downloading from a software center this would all be handled for you and typo squatting will not be a problem. In contrast with debs, the person who owns the PPA for those third party packages do have unfetted, root access to the system. The most popular PPA to this day is a closed down Java PPA run by 3rd party dev. That could easily turn malicious easily.

GordonS 6y ago
I don't know much about the Snap system - regarding 3rd parties and the "tick", is this using domain verification, or some other means? Do 3rd parties have to pay for this? I read something the other day about needing to pay Canonical $15k/y for a branded Snap store, but I'm not sure if that was about private stores, this, or something else.
- jamieweb 6y ago
  Another point is that when installing Snap packages from the command-line, the verification tick only appears after the install has finished, by which point it is already too late. You can view package info prior to installing, but if we're talking about a typosquatting issue here, that doesn't really help.
- kd913 6y ago
  I think the main mechanism of this is communication directly with developers on forum.snapcraft. In this case Mozilla with Canonical etc... I didn't go through this process so I don't really know. I think that is how it has worked so far for all of the 1st party snaps I have seen.
jamieweb 6y ago
I was specifically talking about the default, trusted Ubuntu Apt repositories, not custom PPAs which are of course inherently untrusted. > You install it, at worst it will cryptomine that is it. If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing. > Oh and you can remove it completely with all traces unlike deb equivalents. Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed. In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.

hajile 6y ago

Don't forget performance. SquashFS has terrible IO performance and you pay that price every time you open an application. https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-format/9466 https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-... There's an even bigger security hole with Snaps. If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again. Very few (if any) dev teams are that well connected to the development of their dependencies. In contrast, the developers of those dependencies will be very well connected.

rlpb 6y ago
> If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again. Snaps compete with third party apt repositories, not distribution-provided packages (but see below). I've seen a general trend in complex upstreams _bundling_ their dependencies even in builds destined for apt/deb -based distribution via third party apt repositories - because handling differing dependency versions across every distribution release is too complex. In this case, your distinction is moot. In both situations it is up to the upstream developers to update their dependencies. Only that with snaps, their sandboxing security model provides some mitigation. It is true that some packages traditionally shipped by the distribution are moving to snaps, such as Chromium. This is because these packages are moving to bundling anyway, because updating them during the lifetime of a stable distribution release has become impossible any other way, due to the same dependency pain.
- deleted 6y ago
  [deleted]