[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..