Disabling automatic refresh for snap from store

Until this feature is implemented, I flat out cannot use Snap packages.

I recognize the desire to protect users—but the end result is that I cannot use snaps at all, or any of the other potential benefits they offer.

I’m toying with the possibility of just installing everything in -devmode, but that of course has it’s own, major security implications.


@Ads20000 Misbehaves means that it does not behave as the user expects it too. This can be a bug (incorrect implementation), a new feature that changes the user experience (UI or UX changes), or something else. Let me state an example:

Say that I have installed the skypeforlinux app through a snap (isntead of a deb from microsoft ppa as I 've currently done) in my parents laptop. And then let’s suppose that in a new version microsoft updates the UI as usually happens with this apps. As far as my parents are concerned this can be more of a bug than a feature. Right now I have set Ubuntu Mate to notify of updates that are available that they accept at their convenience. Therefor if after that something goes wrong (either because of a bug or because of a UI change) they can be ready for it (and hopefully figure out the UI change on their own). On the other hand, apps/snaps that update in the background without the user knowing when may surprise the user at inconvenient times.

On top of it it’s interesting that the snap enterprise proxy application allows (as claimed here, haven’t verified it) to defer snap updates, but the user on a laptop/desktop can’t. If it’s reasonable to allow the user to keep using an older kernel on his machine (e.g. by disabling updates) why is it unreasonable to give him the option to do that with snaps as well ? I am not saying that a user should do that, and if I met such a user I 'd try my best to help him solve the technical debt that made him make such a decision.

Snaps really need to have a way to plug into the centralized way an Operating System has for managing updates (e.g. the Software and Updates application in Ubuntu and derivatives). Snaps are a good technology, and I 'd rather have skype as a snap instead of a normal installed deb in my system, but not at the expense of losing, as a user, the unified workflow I have for controlling how my system updates.

I think I heard a while ago that a notification feature is on the roadmap, just be patient :wink:

What stops you to set up such a proxy on a desktop/laptop ? It is just a question of installing and configuring software after all (there is no magic in running a proxy locally on a desktop/laptop and point your proxy settings to localhost, many people do that all the time)…

One of the bigger goals of snaps is to actually take away the need for having to control this. If you look at server snaps (any snap that starts a system service) they already do fully automatic rollbacks if the service fails to start after an upgade. The builtin rollback and selftest features in snaps aim for exactly that … not having to care for updates anymore and having a system that always works, no matter if something gets updated or not.

The target here is to take away a burden so that your parents will not even have to care if an update happens or not but will always have their applications fully functional without being bothered with maintenance work or reading cryptic messages in changelogs.

1 Like

One of the bigger goals of snaps is to actually take away the need for having to control this.

This will never happen. Software always had and will always have bugs. Look for example the bugs Intel’s firmware updates had after the Metldown/Spectre vulneerabilities were announced. This is why people who professionally administer systems said in this thread that auto updates are a no go.

BWhat stops you to set up such a proxy on a desktop/laptop ?

I 'm not keen on installing a proprietary solution in order to use snaps properly. Moreover it adds complexity in managing the system. Lastly, as has been suggested here, one way to kill snap upddates is to block/redirect api.snapcraft.io. If I just wanted something for myself I could settle for that. But It’s a duct tape solution and I don’t like it. Moreover this feels like DRM on video games when they were shipped in CDs (legitimate users couldn’t make back ups of their CDs [to cover for scratches/damage] but cracks and images were available for people who didn’t buy them). People who want to go around auto updates can do so, but non-technical users don’t have a way of controlling their updates according to their needs. Moreover this approach prevents Ubuntu desktop distributions from integrating snap updates in the Software and Updates app that handles updates for the rest of the system. Why do we need two different update mechanisms in Ubuntu? This (not allowing snap updates to be fully controlled by the user - that includes never update -) is wrong and I hope Ubuntu developers will realize that allowing users to control updates does not harm the quality of snaps.


If you’re using snapd you’re already using the proprietary snap store.

Because they’re for two different package managers. Snappy has reverts which means that updating without prompt in the background is safer because you can revert the update if it breaks something (which they’re less likely to do because snaps don’t use shared dependencies in the same way that Debs do) - albeit by Terminal which admittedly most users won’t know how to do.

I think this is a good move, however, I’m not aware of ChromiumOS updates having an off switch?

Also perhaps Ubuntu could have settings to control snappy in Software & Updates. Please mark yourself as affected by this bug that I just filed! :slight_smile:

1 Like

I think the malware found on the snap store is actually a reason to keep the status quo on this issue. Snappy, Flatpak, AppImage, random binaries, external Apt repositories are all weak on this because there’s no distribution maintainers checking every app’s source code (with few exceptions) for malware and understanding software inside-out. However snappy is stronger than the others firstly because everyone is locked into Canonical’s snap store, there’s no possibility of someone installing a rogue Flatpak remote that Flatpak can’t take down (though someone could sideload a rogue snap with snap install foo.snap --dangerous) and Canonical can implement checks on all uploaded snaps but also can remove snaps from the store and secondly (more relevantly to this topic) forced updates has the potential to ensure that malware is removed from everyone’s computer via dummy packages that ensure that malicious changes are reverted etc. If updates weren’t forced, someone could turn them off because they don’t want unhelpful changes to their software etc but they may never hear about a particular malicious app and they could thus be stuck with it. I suppose it could be made so that updates are only forced for malicious apps or some notification is given for those updates which grabs people’s attention so it’s not easily dismissed (but I’m sure some would still dismiss it) - maybe the title bar being ‘Your computer is infected’ or something…

Forced updates are also a risk though because someone could push a malicious update to a benign app and it would be installed to everyone’s computer that has the snap.

The malware found in the snap stop show that as far as software distribution goes the snap stop is nothing special compared to other solutions. Malware has been found, for example, in the android playstore, it will also find it’s way in the snap store, especially as it gets more popular. This means that disabling automatic updates is as important in snap store as it is in all other methods of software distribution.

As a reminder. Disabling automatic updates is not about not keeping a user’s system updated. It is about using a custom update process that fits the user’s requirement. If somebody wants to stop updating he can already do that by blocking access to the snapcraft servers.

Yes, and if you can specify exactly what control you need and why then the snapd team are happy to develop features to help with that use case (short, for now, of implementing a global off switch).

I suggested a use case earlier that seemed to be overlooked/ignored. Given Shuttleworth’s recent interest in security, it might be worth considering.

I feel like there’s been more time spent explaining why a kill switch to snap updates won’t be implemented on this forum than it would have taken to implement by a large margin. The use cases keep building, the explanations for why it won’t be done stopped making sense a long time ago. Seems like this has gone on long enough for developers to clearly say we won’t ever do it and close this thread or just do it so this conversation can stop. There’s plenty of good reason have it and not very good ones to not.


Am 48. First computer at age 12. I have stuff I wrote since about age 17 stored away safely and if you knew how infrequently I have backed up over these years, perhaps, you would consider me insane. Still, I have lost very little due to security issues, mistakes and malicious binaries.

I am responsible for all IT for my employer, thankfully less than 20 machines including their servers.

Snap has all other signs of great maturity, and I really do like it - it could become the best distribution platform ever, but only truly mature software will land on some systems I manage that I view as in any way critical.

Truly mature software will let you risk not updating for as long as you see fit to take such a risk without making you block domains at whatever level you choose to block such.

Assuming the immaturity of your user? Sorry, looks pretty immature to me - bury the kill switch in a .conf file in /etc, /snap or where-ever you like and ‘Gumby’ will naturally always be updated. If Gumby determines reason (no matter how foolish insane) to block the updates then he will find a way regardless what you think of him.

Have a nice day.


That’s an interesting perspective. As a counterpoint to this specific line
of thinking, disabling refresh would also mean that the fixed snap
wouldn’t be automatically pushed out to affected users.

@jdstrand A user who wants to control his update process is also able to check for updates and inform himself of that scenario (new security updates). Also security updates can cause harm as well if they are not vetted, a good example are Intel’s Spectre firmware updates that bricked some devices and had to be rolled back.

On top of that, Canonical’s proprietary solution for managing snaps for enterpise customers, who will be the biggest consumers of snaps because of IoT, already allows them to stay outdated (given what has been said here about version pinning, have not read the docs myself).


This is what Niemeyer (the snapd lead) often refers back to and, I must admit, this does seem to be outdated because of the existence of the Snap Enterprise Proxy. Is really to be expected that non-enterprise users use this proxy? It doesn’t seem very easy to set up but maybe that’s the point, in reality, it’s still hard to ‘simply disabl[e] updates altogether’ for the reasons given above.

I’m also guessing this still applies.

As far as I understand it, snapcraft is not a democracy. We should keep satisfying what Niemeyer requested above and providing use cases and suggesting forms of mitigation (I think the snap refresh timer was introduced as an outcome of this topic? Plus Niemeyer said it would be ‘reasonable to have an option to say “skip refresh windows if the last manual update was within N days/hours/etc”’ so this is a change which effectively has design approval which is an outcome of this topic. Probably also the Snap Enterprise Proxy bore the thoughts of this topic in mind), but the developers have no obligation to satisfy our demand just because we make the demand. If you absolutely can’t stand the status quo, I suppose the only answer is to manually work out a way to block refreshes (maybe by using the Snap Enterprise Proxy) or by using a different universal packaging system like Flatpak. Alternatively…if anyone reading this understands Go, it may be possible to code a snapd soft fork which implements certain changes which many users want but the snapd team disagrees with, now you could say ‘but we shouldn’t have to resort to a fork!’ but if you can’t do the other things I’ve suggested as action in this post then we do have to because we fundamentally disagree with the snapd team, we have no other option. Forking is part of open-source, after all, perfect for when you have design disagreements that can’t be resolved any other way. @G.S.1 listed the changes that should be made in this repo, also see the other pinned snap repositories on their GitHub.

Specific use cases need to be given as objections, as requested by the snapd team, rather than generally raging against the status quo, you can Like (+1) previous posts to achieve that. I really hope this topic is kept open so that more use cases and proposed solutions (short of an off switch) can be suggested by the community, I think closing this topic permanently would be a big downside for the snap project, enabling criticism to be made in-house is bold and can result in positive changes. E.g. @robsoles you kinda gave a use-case but you didn’t state why forced refreshes are a problem for you, can you state that more clearly? Why do you need software that ‘will let you risk not updating for as long as you see fit’? Saying merely that ’ it should because I say so and the software should #RespectTheUser :open_mouth: ’ doesn’t challenge the status quo because the snapd team clearly aren’t responsive to such a statement because they’ll just disagree (and you can just Like previous comments that have said the same thing rather than write a new one). Give specific reasons why you can’t update software on systems and suggest action short of an off switch - e.g. do you need the refresh timer to be extended? Would it be OK if the timer allowed one refresh every five years? Or is there software that you need to keep completely static with not even security updates for longer than five years? Why?

This is a good example, going back to Niemeyer’s original post on this topic, though,

@niemeyer were health checks implemented? Would they always catch cases like the one given above? If not, is it reasonable to accept that the user’s system is bricked because snapd or the snap developer didn’t do health checks etc properly? Can snapd really expect developers to implement lots of automated testing when they don’t have to do so for any other packaging format? Should users be forced to suffer when developers/snapd get that wrong? I guess you would argue that the alternative is that users are left on vulnerable software because they won’t update their software, but what’s the actual risk of them being attacked because of their decision?

Is this a common experience? Maybe it would be acceptable for snapd to allow users to be vulnerable to attack because they want to be? They don’t mind the risk of having all their data (that which is accessible to a particular app) stolen?

Going back to Niemeyer’s original post again:

Maybe the key part of this is ‘some of the problems’, maybe some users want those problems but appreciate the other solutions that snapd has produced? Do we really need to fork to get this situation that some users want? :slightly_smiling_face:


@Ads20000 Before anything else, thanks for your continued interest and respectful way of discussing those issues. It’s very appreciated.

No, that’s really a case to handle enterprise-style needs. You and me would not have something like this for our own personal use or for a small business. It should be unnecessary.

As a minor agreement from the previous sprint, which I’m not sure already made into the code, we’ll extend the period in which the system won’t force out-of-schedule updates to 3 months. In other words, the timer is still monthly based, but if a window is missed, it won’t force an update out of schedule unless the system hasn’t attempted an update for 3 months.

The first bits of it are scheduled for the current cycle, so something should start to be visible in the coming months. First step is a hook on the client with some new semantics attached to it.

All of that makes it sound like the semantic changes we’re proposing are larger than they really are. No matter our opinion (wish I could force people to test software :)), the fact that people can ship broken software to your machine is already true no matter what platform you are in. The only difference here is that we are also acknowledging the fact that software that does not change also becomes broken over time, so we’re putting that flow of updates on rails. Users already have control to fine tune updates on their own systems, so the goal is clearly not to take power out of the user and into our hands. The goal is to make sure things are flowing, somehow.

The enterprise proxy helps in that goal, instead of being a change in perspective. It would be extremely ironic (from my perspective at least) if people go over the trouble of setting up an enterprise proxy for their large scale deployment only to make everything out-of-date and vulnerable, at a large scale.

They can have them. I just won’t have facilitating that as a goal. :slight_smile:


I disagree with this on a very fundamental level.

I have a Harmony remote which I configure using a five-year-old version of Logitech’s software, because newer versions took away the ability to customize every button on the device. Luckily, the older version still runs fine on my system. Perhaps running this old version is a security risk, but that’s a risk I’m willing to take, especially given the relatively-low number of attack vectors afforded by a TV remote config program. And, my personal computer is not used for anything mission-critical.

There are a lot of instances like this—times when software was updated to remove some functionality I rely on. The old versions still run fine, and I hold onto them. In these cases, I’m refusing to update not out of laziness or apathy, but because the newer versions have ceased to be useful. A forced automatic update in this scenario is no different than outright deleting software from my machine, without my consent.

In an ideal world, software makers would always have their users’s best interests at heart, and updates would only ever constitute an improvement. In the real world, however, that’s often not the case, and I cannot move to any system that takes such an important choice away from me.


In your scenario, you might easily install the snap locally either way and have it completely disconnected from the store.

As an even better alternative, but which depended on someone (not necessarily the software author) being a good snap publisher, the old version might be provided on an independent track. That’s typical and best when there are major incompatible changes, so that people can maintain independent lines in their systems, and it also means that the old version might receive a security update without breaking your case.

So the fundamental level disagreement is not so fundamental, and perhaps not even a disagreement. :slight_smile:


This argument perhaps doesn’t work when the source is closed and the old version can no longer be accessed easily on the Internet and the snapcraft.yaml is not easy to recreate? Also if the user wanting the old feature is the only user in the world wanting to do so and isn’t technical enough to maintain a snap for that old feature but is technical enough to turn off automatic refreshes for that snap?

@Ads20000 This is again going into territory where nothing will help. If you update your system and apt updates your system with a new package, and then it disappears from the Internet, you’ll have the same issue. In fact, snaps will do much better in this case, as you’ll still have the old snap in your system (and the one before it) and can revert to it once it breaks.

Oh, if one runs snap revert then snapd won’t automatically refresh it?
Is it possible, then, to recreate the .snap from that install and allow others to install with --dangerous if they so wish? Perhaps it’s not something that you’d like to detail but presumably there’s no simple command to do that?
Edit: Figured it out, I think you can copy the files from e.g. /snap/discord to ~ and then snap pack ~/discord/66