| My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have. When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package. When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone. I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important. On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere... |
Where do we get more maintainers? Sometimes in my development I release one new Wekan version per day. Canonical's Snap build servers download Wekan source code directly from GitHub, it is very transparent.
> On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way
Wekan Snap has strict sandbox, so code can not access any other directory that /var/snap/wekan/common. So in case someone would find exploit for web service, it can not escape sandbox. It is very important.