[acgkmopvvgvmgv]

It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities.

https://blog.linuxmint.com/?p=3906

> A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.

> First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed.

[xet7]

I used to use Linux Mint at many computers. But making hard to use Snap is just shooting itself in to foot.

Currently I prefer Kubuntu/Xubuntu/Debian, where Snap works.

It's like community just complaining about Snap, and not rushing to provide pull requests for alternative package systems like Flatpak.

Without packaging to Snap, I just end up producing separate .deb package for each distro, like:

- Ubuntu 18.04

- Ubuntu 20.04

- RasPi 4

etc. Separate .deb package is needed, because different distros have different versions of dependencies.

Snap works on multiple distros with one package, that saves a lot of time.

[galgalesh]

> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store.

This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get.

> You can’t audit them

Many Snaps contain a build manifest in `/snap/snap-name/current/snap/manifest.yaml`. This manifest contains a log of everything that is used to build the package. For snaps built on Launchpad, this is automatically enabled and includes a link to the Launchpad build log for that snap. This is one of the build logs for the Chromium package, for example: https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-n...

Using Launchpad as the source of truth, you can be 100% certain that the snap you're running is built from the source it presents. This is the same infrastructure that builds and provides trust for Ubuntu itself.

The snapcraft build service uses Launchpad in the background, so any snap built using that can be audited just like regular Ubuntu packages. Snaps built on third-party infrastructure can enable this manifest using an environment variable.

I don't know why Linux Mint is spreading such misinformation, but this is harmful.

[comex]

> This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get.

By “you” I assume they are referring to users, not distributions.

[galgalesh]

Hm, maybe you're right. So in that case:

> hold them

Users have many ways to hold snaps temporarily. If they want to hold snaps indefinitely, then they should install them using he `--dangerous` flag. That won't give them any updates, but I'm guessing that's the point. They can always get the latest version of the app manually using `snap download snapname` and install it using `snap install snapname.snap --dangerous`.

> modify them

Just like a `.deb` package, users can unpack a snap, modify any file, repack and install the modified version. Alternatively, you can unpack the snap, modify any file and install the directory using "snap try". You can then modify files and rerun the app without having to reinstall it for every change.

> or even point snap to a different store.

The signing keys are baked into the Snap binary but the URL is configurable via an environment variable. So users can change to a different Brand Store without any issue. If they want to use a store with a different signing key, they have to install a different version of snapd which is compiled with the signing keys of the other vendors.

This isn't an insurmountable problem, but it is less flexible than apt, yes. Although I think "apt remove snapd; apt install snapd-fsnap" is still pretty easy..

[bboozzoo]

> It's not for nothing that Snap is considered dangerous by SUSE and is not officially supported. They even fail basic upstream responsibilities.

Care to provide a link to support your claims?

[galgalesh]

The security issues SUSE raised were actually fixed, but the Snap developers did not respond quickly enough with the info that the issues were fixed.

> I'd like to point out that the reason for the closure was not a failure at addressing any of the raised issues, but a failure to reply to either of the requests for a status update in July and September.

https://twitter.com/sysrich/status/1206593475833151488

[Conan_Kudo]

That's interesting, since it looks like the issues raised by the SUSE Security audit are not all fixed yet: https://github.com/snapcore/snapd/projects/4