That statement is just wrong. If it were that easy, we would never have experienced issues like the ones we have with popular packages such as Steam and even major system packages like Firefox.
For example the “Open Folder” option doesn’t work with Transmission Snap (Both beta and stable versions). It’s not a big deal but I have been experiencing issues like that with different packages.
Even if all these packages worked perfectly, treating containerized systems like Snap (or even Flatpak, etc.) as the only correct way is simply wrong. Containers have their place and purpose, but they also come with drawbacks. For instance, when you have multiple packages all relying on a single system-wide library, it’s easier to maintain that library, track, and fix security flaws. However, when each package includes its own version of the same library, it becomes much harder to monitor and patch vulnerabilities. In such cases, package maintainers must fix each version separately for their respective packages.
Another argument often made is that containers make it easier for maintainers to ship software, which is true. However, that doesn’t necessarily make them more secure—just because an application has restricted access and can’t reach all folders in your home directory doesn’t mean it’s foolproof. I mean, your file browser can still access everything—are you going to install a Snap version of that to “fix” it?
So you think that a Canonical maintained, tested and QA’ed Steam snap package is less secure than the rest of the distro because security flaws of libraries would not be fixed in time ?
It is not really clear to me what you mean to achieve with your reply to a post that simply points users to install software from the default tool to manage software in the distro and that points out that this specific software is supported here and has been tested by the provider… There was no mention or promoting of snaps anywhere in Ian’s post, it was just a simple statement of facts
If you want to discuss container technology or snap packaging you should perhaps open a new thread, just jumping with an unrelated rant into some discussion feels slightly rude…
I replied to ian-weisser’s specific post. It should be pretty clear what I am saying. I didn’t say Canonical Steam snap is less secure.
He made this statement: “The software in there is tested for compatibility with your system.
It’s the software we provide support for.” and this is wrong for different reason. Canonical doesn’t test all snap packages available the App Center, and his screenshot has “Filter by ‘Snap packages’” in it. To me this sound like he’s definitely recommending Snap packages and is claiming they’re all tested (Although, he did say ‘for compatibility’).
Further, we have already experienced issues many times even with packages that were tested and not only for compatibility I hope.
However, I am not against Snap. I do use Snap, and I would probably use it more in a different setting (Server, shipping enterprise software to a customer - because it’s easier etc.).
No, this is completely true for the package he was pointing to, it is developed by a full time team of developers from Canonical on Ubuntu, is being tested and QA’ed by this team on Ubuntu and is being maintained and regularly updated for security issues and fixes …
The packaging format has absolutely zero meaning to that fact…
It is truly impressive how you can read Ian’s inner thinking out of a side pulldown in a screenshot even though he doesn’t mention the word snap anywhere in his original post or claims that he speaks about all snaps
But regardless of the reason that got us here into a new Topic called “Security of snap packaging”, lets focus on your security concerns …
Have you reported this to the snap packager ?
ogra@styx:~$ snap info transmission|grep contact
contact: https://github.com/sameersharma2006/transmission-snap
ogra@styx:~$
(there is an issue tracker on that github page)
This might be true for packages shipping their own libraries, but in the snap ecosystem the relevant ones are typically consumed from either content snaps (i.e. nearly all graphical snaps are using one of the Canonical provided extensions (gnome or kde) to get their desktop libraries and integration) or from the base snap … let me give you an example with two of the most security relevant libs:
So the libs to run your GUI apps come from the Canonical (or from Canonical-trusted maintainer’s) maintained content snap for the respective graphical framework, the libs responsible for encryption come from a Canonical maintained base snap … both of these snaps are updated by the Ubuntu maintainers when security vulnerabilities show up …
Now, that still leaves a bunch of libs an app might use and bundle in its snap …
If you are a snap maintainer, you have to register that snap in the store with your Ubuntu SSO account, snap packages in the store are regularly checked for vulnerable libraries, if your snap ships such a library you get an email to the address you used for your SSO account registration every time that vulnerability is found during such a scan asking you to please hit the “rebuild” button for your snap to pick up the fixed library … it is indeed up to the packager to ignore that regular mail spam, but clicking a button on a website is really not that big of an effort …
In case the packager ignores the mails there is then still the fact that your app runs under confinement so that all you could theoretically take over is the confined space but not actually the host…
A file manager would come as a classic snap due to the fact you state (needs to access all places on a system), this means it would run completely unconfined anyway … classic snaps have to undergo a certain procedure on upload which involves a review by the security team and a verification of the trustability of the uploader, so yes, I personally would install such a snap since I trust Canonical and its security team, else I would not run Ubuntu but a different distro …
