Gotta ask: why not just give these people the option to totally disable Snap updates, but not disabled by default?
Everyone’s happy.
2 Likes
The more I think about this the more I’m convinced that automatic updates are a straight up security vulnerability in and of themselves. Here’s a no-brainer, generalized zero click exploit for any would be black hats reading this thread (all 3rd party snaps are off my machine now so I have nothing to fear myself):
Suppose a set of email account / credit card credentials sell for $X - look in the snap store for a single developer project with an exploitable install base of Y - send them an email along the lines of “Hi we’re a startup who just got funding and we would like to purchase your project for $X * Y * (1-target_profit_margin)”. BS your way through negotiations and then once you get a taker silently push a keylogger to the project and collect your $$$ from your defenseless victims.
Another one:
Watch programming streams or conference talks on youtube by a prominent developer and wait for them to press the super key, revealing their installed programs. Hopefully they have something niche installed on their machine - if so make the developer of that project an offer. Insert your keylogger or exfiltrate their ssh keys of the prominent dev and then push an invisible update to their app.
Supply chain attacks are not hypothetical and should be taken as seriously as unpatched binaries! Installing a todolist from the snap store should not give the developer of that todolist perpetual access to my machine!
https://www.wired.com/story/kaseya-supply-chain-ransomware-attack-msps/
Alternatively, if you don’t want to muck around with credential exfiltration / darkweb markets, just deploy a crypominer:
-J
3 Likes
+1
It’s not that hard to find reputable sources confirming this, not that Ars Technica or Linux Uprising aren’t reputable IMO, i.e. https://www.crowdstrike.com/blog/crowdstrike-customers-protected-from-compromised-npm-package-in-supply-chain-attack/
Especially relevant is the recent go.dev publication titled “How Go Mitigates Supply Chain Attacks” which goes in depth on why latest isn’t always the greatest w.r.t security. https://go.dev/blog/supply-chain
This really shouldn’t be a difficult thing for anyone to understand. When you deploy software in a way that says " we will force every update, and go out of our way to make sure that the user, who owns the system on which that software is running, does not have any option to turn off automatic updates", you are telling someone else that they are not allowed to decide what happens on their system, and that you will decide for them. That’s an immediate F U, and your auto updates. I will decide what happens on my system, not you. I will block your stupid approach to software delivery however I have to, be it through editing the hosts file, blocking all outgoing traffic to your IPs, etc., etc.
See in the end, the user will decide what happens on their system, and ultimately when someone wants to stop you from forcing new versions of software onto their system whenever you feel like it, they will, regardless of their reasoning. Therefore your overcharged ego driven solution of mandating automatic updates, and “blocking” users from being able to simply turn them off, is entirely futile anyway, and really only serves to create a poor user experience by making people who are going to turn that garbage off anyway do a bunch of extra crap just to stop you from forcing software onto their system, and then undo it temporarily when they DECIDE to update. Maybe they want to run their own update schedule manually, maybe they just want to run a specific outdated version of some specific software indefinitely for whatever reason, it doesn’t matter. Do you know why? Because it’s their system, not yours, and it’s their decision, NOT YOURS, and it’s really none of your business how or why they choose to run their system they way they do.
Stop treating your software users like you think they’re too stupid to decide how to run their own system, and that you have the right to take that decision making power away from them. People come to linux to get away from that trash. When you find yourself removing any decision from the user’s control, you have failed as a developer.
1 Like
Here’s a hint…
snap autoupdate off
It’d be that simple. Then this topic which has spawned a 5 year long thread that’s still receiving replies, and over 100 Million search results in Google, would be solved, clean and easy. The solution is really simple as soon as you admit to yourself that it’s none of your business, and not your decision, how other people choose to run their system. Everybody’s happy, the auto update lovers can just roll on like nothing even happened, and you don’t have to pretend to be in charge of everyone else’s systems.
5 Likes
Is there a chance to have autoupdate option turned off? It broke my Eclipse install and config, my time was wasted. Who am i? 7yo to not be able to decide what to update or what not to update?
I would be more than happy to be able to set this option as per package or as a global setting.
I’m under the impression that the ability to disable automatic updates (for individual snaps and all snaps) is actively being worked on for a future release, as can be seen in Github activity.
(But I’m not a snapd developer, and plans may change).
1 Like
Could you maybe provide some links that show what you’re talking about? Commits/issue responses?
1 Like
https://github.com/snapcore/snapd/pull/12035 & https://github.com/snapcore/snapd/pull/12073
But of course, until both land in a stable release, not as experimental, and preferably with a blog post (it’d be a big announcement!), I wouldn’t consider it a promise that it’s the solution everyone here is hoping for, but it’s certainly indicative of interest.
5 Likes
Just to check back in here, looks like they have recently added these to the 2.58 milestone. So could be relatively soon!
this just seems to extend the functionality of the existing snap refresh --hold to use it on a per-snap basis rather than doing it system wide for all snaps …
It’s mostly this commit that’s interesting for the people here
e226d30 adds support for holding refreshes indefinitely for all the system's snaps
But the way I’d read these changes together is essentially:
- You’d be able to only block a certain set of installed snaps
- You’d be able to block all installed snaps
- And there’d be no time restriction, unlike the current 90 days approach.
Granted, I could be wrong. This would still be a major shift in design philosophy, so I’d still be cautious until everything lands and is shown to work how it’s hoped to work.
6 Likes
hah, i missed that one, thanks for pointing it out !
Sorry, I should have been more clear, but only linked to the second commit that was directly added to the milestone. The first seems to have already been merged though!
when does this --hold thing comming to scene?
snap refresh --hold microk8s
error: unknown flag `hold’
look at what damn auto refresh did to me and others who use microk8s on snap (and again canonical force to provide microk8s only via snap) !! of course it must be optional to hold a package for ever without update, most servers are behinde firewall and do not access to internet (maybe occasionally connecting to internet) then why snap force auto refresh, this is absurd and lame logic and to make mattar worse justifying it with taking security measures for users!!!and if we dont update u won’t do it! 
https://github.com/canonical/microk8s/issues/3545
once it is rock solid and well enough tested to not break millions of IoT devices, industrial controllers, robots and digital signage setups that are out there from paying customers i guess …
it should currently work with the snapd from the edge channel as described in the documentation:
It’s worth mentioning that you can use the tracks functionality with MicroK8S, so that you’d only receive patch/security updates for a specified branch, and that functionality is already in snapd and usable right now, based off of the Github issue you’d use
sudo snap switch microk8s --channel 1.23/stable
1 Like
There’s now an official blog post advertising this functionality.
(The functionality itself is still currently only present in the edge channel and hasn’t yet hit stable).
4 Likes
snapd 2.58 released to the stable channel recently (10/01/23) and with it brings the ability to prevent automatic updates, on either a per snap or all snap basis; for as long as the user desires (i.e, potentially forever).
To E.G prevent Firefox updating for a day
snap refresh --hold=24h firefox
to E.G prevent Firefox updating forever (Please update it manually at least).
snap refresh --hold firefox
To prevent all snaps updating automatically ever (With great power…):
snap refresh --hold
If you haven’t got 2.58 yet, please consider updating your distro packages packages (for distros such as Fedora), rebuilding (e.g AUR) or snap install snapd or snap refresh snapd (for Debian derivatives).
If you run
snap refresh, any snaps that have been held explicitly will not be included for updates. If you want to update a snap thats been explicitly specified, you must specify its name, e.g snap refresh firefox.
And finally, you can reverse all of these by using snap refresh --unhold, on a per snap or all snaps basis.
13 Likes
Thank y’all developers so much for this 