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!
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 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.
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 ’ 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?
@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.
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.
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.
@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 )
’ 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?
)