Disabling automatic refresh for snap from store

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.

5 Likes

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.

2 Likes

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).

2 Likes

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:

2 Likes

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

3 Likes

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.

3 Likes

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:

2 Likes

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

if you’re on revision a, and get a refresh that takes you to revision b, and you revert (manually via snap revert or automatically via health checks), you’ll be on revision a and revision b will be blacklisted so you won’t refresh to it. If revision c then becomes current on the channel your snap is tracking, you will be automatically refreshed to revision c.

you don’t need to “recreate” the snap; if you can revert to it it’s because you have it already (revert does not download). And you don’t need dangerous, because you’ve already got the snap assertion for that revision (so when you install it, snapd will know the revision and will continue to refresh it from the store).

I guess you could take an old snap, modify it in some way so its sha3 is different, and then install that (for which you’ll need --dangerous indeed), and then you’d be getting no more refreshes from the store.

But if you’re going to do that, I’d rather you didn’t use the snap at all TBH.

@niemeyer I have not seen your opnion on the following:

People (speaking about home users) who want to stop snaps from updating can do so by blocking api.snapcraft.org either at the OS level or at the router/network level. Therefore if somebody wants to stop updating he can easily do that. On the other hand a user who wants to control his update process cannot - unless he fits into your specifications. To give an example. Non-techinal relatives of mine are using Ubuntu Mate. For them the risk of getting hacked because they didn’t update has to be balanced with the risk of an update either changing (e.g. new application UI - for them it’s not a feature) or breaking something (e.g. broken intel firmware updates). In the setup I ve created for them the system, through the software and updates app, automatically looks for updates - but prompts the user before actually updating. This works well for them because they can chose to upgrade at non-critical times and know to expect changes on their system. And if something changes (e.g. new UI after a skype update) they can attribute it to the update and look a little bit more for the buttons instead of calling me and telling me that linux doesn’t work. However your approach fragments the applications into ones that get upgraded by the software and updates app and ones that get updated by the snap app. This is not helpful and creates confusion when you need to explain it to other users. If snap allowed for an option to never upgrade then the software and updates app could take over by running sudo snap refresh after sudo apt upgrade. All applications of a linux installation would again be homogenous with regards to updates. Software and Updates has been available for a long time, it’s a mature application that works well for users, why not use that for snaps like we do for everything else - including kernel updates.

1 Like

@Iolaum Please could you mark yourself as affected by this bug which I filed against Software & Updates? This will make it possible to control snaps from there (using the refresh timer which lets you refresh at a particular time in each month, or more frequently).

Up to Niemeyer to reply in more detail but I think I can probably argue from his perspective given what he’s said so far so I’ll try to save him some time:

Do users really give their software updates dialogue a careful inspection before updating or do they just hit the Install button as fast as possible or, more likely, dismiss the updates and get on with what they were doing? I think the idea with the automatic refresh is that people’s applications are updated but they still work as they are being updated (well, not currently, but that’s the idea, I think) and then when the app is launched the next time yeah the UI might change…but people may not realize what’s happened even if they had to explicitly give an update, plus I think Niemeyer is happy to make the possible-confusion-in-exchange-for-properly-updated-apps tradeoff.

Software and Updates also has an option to allow security updates to be installed in the background (unattended-upgrades). Snapd simply requires this for every app update to block the case where people simply dismiss updates because it’s a faff to update their software. Instead, software should just work even when updating in the background, if it doesn’t then it’s a bug. UI changes should be self-explanatory enough…I don’t really think that your relatives will be less confused by a UI change if there’s a (potentially rather long) updates dialogue that they have to confirm first, really? If they do then this is an edge case that @niemeyer should address…

@Ads20000 Marked myself affected in the bug report, nice idea!

No users don’t inspect changelogs before applying updates. But you make sure to complete the important job that made you open your laptop and then click the yes upgrade button. (Or at least that’s how I 'm training my relatives to use Ubuntu Mate.) When you explicitly tell your system when to update you know when to expect changes. When you know when you should expect changes you have an easier time identifying random bugs from changes or new bugs that come from updates. (And that’s when you look for the changelog if you need to :wink: )

@lolaum

People (speaking about home users) who want to stop snaps from updating can do so by blocking >api.snapcraft.org either at the OS level or at the router/network level.

I can shed a little light in this area. Have been following this thread for quite some time and have interacted with a number of the dev team with my questions. Followed the instructions given to use IPtables to stop the updates.

Well - - - here - - - it doesn’t really work. What happened was (happened 2 times now) is that there is enough software banging on the system from inside and a reboot results. As my server needs some manual intervention to complete the booting sequence it wasn’t initially (the first time) clear what had happened. After the second time I spent a number of hours searching through the /var/log files looking for why the machine had gone down. (I am working toward having my server monitor and control processes.) In became quite clear that it was snapd (or snappy or snap or snapcraft whatever the software is actually called) that was triggering the behavior which resulted in the reboot.
Because this kind of behavior (outside control) is not only quite antagonistic to my needs (a server that is monitoring AND controlling processes) I have started setting up another complete system so that I can determine how to run LXD from source code rather than having to use software that doesn’t allow my choices to be used.
Interesting to me is looking at the total environment. When I look at ubuntu’s stated goals and then their specific team’s actions I am starting to see movement away from the idea of independent systems as is espoused in the idea of FOSS to a centrally managed (and controlled) environment (the 800# gorilla of the microcomputer software world is already doing this all). I can remember reading the advertisements way back when the IBM pc (and the pc jr) was released and one of the ideas espoused was ‘computing - - - YOUR way’ (my emphasis). I’m thinking that the IT departments of yesteryear might actually have been easier to deal with that the IT thinking that is now dominating microcomputers and their use. (Especially fascinating is when debate is halted by a sysadmin - - - not because of uncouth language - - - but merely because of a need to shut the topic down.)

1 Like

@Iolaum Our goal is to establish a proper flow for software updates that tend to work very nicely both for users and for publishers. We’re not actively preventing the system from being hacked by such home users, though. It’s just that if it breaks when doing that you get to keep all the pieces.

With that said, we continue to hear feedback from everybody about the good and the bad cases that arise from the implementation, and we’ll continue to improve it until it has achieved that goal. So don’t take the current system as final, and keep the feedback coming. There’s a lot we want to do still.

@dabeegmon That’s unexpected, and snapd should definitely not be rebooting a classic system like that. Can you please provide the logs that made you believe that this had happened?

2 Likes

Are you really sure that you want all of this information?
To put this together I looked through something like over a hundred pages worth of material and from that likely at least 20% would need to be pulled along with the editing needed to outline what each section came from in the log files. It would be a very large amount of work!

I thought there was a clear link between snapd and reboot. If that’s not the case, then let’s not spend time on the wild-goose chase.