Snap developers admit that you need to trust the developers of the snaps you’re using. If you don’t trust a developer then don’t use their snap! To get up-to-date packages on any distribution based on time-based releases and freezes (for stability, updating every part of the OS as it becomes ready as rolling-release distros do is not as stable as people think it is because all packages are interconnected, it’s hard to test each individual update one-by-one on the stable base (not in testing, in the case of Debian, for example) on enough hardware and software configurations and from enough previous package versions to ensure as good stability as freeze-based OS’s do), people often use external repositories (PPAs in the case of Ubuntu and Mint, COPRs in the case of Fedora, though their stable releases are much more flexible in terms of application updates it seems, which maybe Ubuntu should move to (but maybe there isn’t the manpower, the Backports repository exists but it doesn’t seem that many applications that could be updated via Backports actually are)). These are even more dangerous than snaps (though it’s more clearly written on Launchpad that they are). Snaps are confined, they only have access to certain parts of your system, so what you’re talking about shouldn’t actually be a problem unless a user is tricked by an application into giving it access to something it shouldn’t have access to. If you can think of ways that snaps could break that confinement (or ways in which they’re not currently confined and they should be) then please file bugs as these are serious security issues that could be fixed. You can do that here or if you’re talking about how confinement could be expanded you could try creating a new topic here.
This sounds like something a company would be doing, generally speaking, and they should talk to Canonical and set up the snap enterprise proxy so they can control updates on that machine. If you can think of machines that would really benefit from the proxy but that lie outside of the corporate sphere then please give use cases (preferably real ones)!
I think that having an option to disable automatic refreshes would be good and @niemeyer (the
snapd lead developer) has expressed that although they are reluctant to introduce a global off switch (because that would prevent them fixing the problem of people sticking to old versions of software to avoid change (in their view, to increase stability, even though changes in the world mean that old versions can become unstable and insecure without users really doing much about it)) but they are very happy to introduce changes to accommodate users’ needs, this is part of the reason for keeping the off switch, because it forces them to make changes to snapd so that people do feel able to update their snaps, rather than turning their updates off. If you can think of ways in which snappy can do this (e.g. extending the refresh timer period (currently you must update at least once per month, if I recall correctly setting your Internet connection as metered ensures that you don’t have to update until two or three months past your initial update)) then suggest them.
By the way, you might just want to IP block the server snapd uses if you want a hacky off switch if you’re desperate for one. I don’t know what the IP is but it’s a known workaround
If you don’t trust an upstream to test new versions properly, security-wise, then don’t use their snap (unless you think they will have it sorted within one month of the update, in which case set your refresh timer to update once per month and you’re sorted, though if the update came 31+ days after your previous refresh then it might update anyway? I don’t know how the timer works really, @zyga? I think you may have told me before but it’s still unclear to me… the system options doc should probably be updated to make more clear how the hold process works (e.g. maximum hold time, when the time is counted from) so people know how to fit it to their use case? I can update the doc if someone can remind me how the timer works) If they had an LTS branch that you would consider secure, then use that: see MicroK8s for an example, if you click
latest/stable in the top-right, you’ll see that there are different tracks listed, so running
snap install microk8s --classic --version=1.12/stable will keep you on the 1.12 track (until it’s closed, I’m not sure what happens when it’s closed?!) rather than on
latest, so you’ll only get updates for 1.12, which I presume are just security updates (though I don’t know if MicroK8s sticks to semantic versioning or not), note also that MicroK8s is a
classic snap so it has much less confinement than a normal snap and so is much more insecure. Classic as a confinement setting is considered transitional, @niemeyer plans to get it removed when strict (the normal confinement, but remember, a huge improvement on Debs/RPMs since Debs/RPMs don’t have any ‘sandboxing’ really) confinement is usable for more apps.