Disabling automatic refresh for snap from store

[Ads20000]

Disabling automatic refresh for snap from store

The issue that makes us resist the idea of simply disabling updates altogether is that very often that will mean never update rather than update at someone’s discretion, and then we’re getting back to some of the problems that got us here in the first place. That’s why we’ve been resisting introducing that global switch, at least for the time being, and instead working with people to mitigate the bad side effects of having automatic updates enabled. Today we’re already able to schedule the prec…

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.

@niemeyer

Given the understanding above, is there anything else we can do to help mitigate the real issues you’ve observed without simply turning updates off entirely?

I’m also guessing this still applies.

@SuperJonotron

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.

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 ’ 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?

@Iolaum

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.

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

@niemeyer

Soon we’ll also start working on health checks, which will allow systems updated to automatically rollback if the system finds itself in a bad place after the update.

@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?

@robsoles

I have lost very little due to security issues, mistakes and malicious binaries.

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:

@niemeyer

very often that will mean never update rather than update at someone’s discretion, and then we’re getting back to some of the problems that got us here in the first place.

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?