so, i think i found a solution for ME.
sudo snap refresh nextcloud --channel 21/stable
now, when i list all snaps, they all say ‘latest’, except nextcloud which says 21/stable
This will hold nextcloud on 21/stable?
You’ll still receive any new revisions published to the “21” track (security/patch releases/etc), but these should all be from the same major branch of version 21. You’d never update to any newer major versions, even if version 21 becomes end of life, without changing the channel manually.
2 Likes
PERFECT! I think this is what a lot of people are looking for.
Now my personal nextcloud instances will stop breaking on me every time i turn around.
It is a kind of workaround but not a real solution in my opinion. There is still this annoying and unnecessary lack of control (just the channel switched).
1 Like
Disagree, the thread is here so people can just +1 existing comments they agree with (by liking them) to express support for those comments or making new suggestions and providing more evidence that the status quo isn’t working per the below:
I would like this thread to say open whilst this is still an issue and whilst @niemeyer is still asking for real and specific use cases (if he is still asking?) where automatic snap refresh is the problem and where there can definitely be no workaround other than an off switch (there’s quite a lot of snap commandline control now for scheduling updates if you only want one update per month, for example).
1 Like
There’s two answers Canonical would give for this use case I think:
- Outdated software puts both you and your users at risk, yet servers still run outdated software, hence taking the control out of your hands and protecting your users by forcing you to update the software occasionally, unless you hack around that design.
- You can control when these updates are made from the
snapcommandline. Usingrefresh.timer, you can set it to just update once per month at a particular time, so that you can plan around the update. Once an update has been made you can also userefresh.holdto delay updates for the next 90 days.
Please could you specify a real use case where the a once a month refresh.timer and a 90 refresh.hold is not enough? If you can specify a real use case where this isn’t enough, I’m sure Canonical would be very happy to listen, that’s why this thread is still open.
I agree with others that if the workarounds and controls available don’t satisfy you then you need to find an alternative to snappy.
Do read Re-visiting update control on the desktop if you haven’t already, I just read it now, it’s by a very well-respected Ubuntu community member and former (recent!) Canonical employee and summarizes the situation well.
1 Like
I already have.
I’m not interested in regurgitating the same answer once again, read the thread, read my comments.
I would be ok with only the STABLE channel auto refreshed and updated… but all the other channels needed to be manually refreshed. Something at least so we have more control over the auto refreshes.
Correct me if i’m wrong, but if you open a Enterprise app store ($$) with Canonical, you get more control and options on updates and version control? What do small startups like myself do so we can control app updates and not crash customers business computers in the middle of the day all over the world when the 4h auto happens? Our software snap for example, will run games with live customers in-person, and imaging the app crashing to do an auto update bringing the business to a stand still. Having an option to set the ‘allow refresh time of day’ or something would be so nice.
This is exactly what refresh.timer option is for:
So how do we do that on Ubuntu CORE devices we give to our customers? For us, we want to stop any updates on the CORE side, and control all the updates in our web application logic so our customers and pick times to update, or schedule them.
For such setups the usual way is to use snapd-control interface. However, this is a super privileged interface, as such you will likely not be allowed to publish anything to the global store that anyone can use, and are expected to use the brand store (basically the interface allows you to execute all API of snapd, so pushing a bad snap to the global store would mean any user of that snap could be affected, while with a brand store its effects are limited to your snaps and devices). But there are also other options: https://ubuntu.com/core/docs/refresh-control which I think @ogra referenced already. TBH if you’re deploying devices based on Ubuntu Core, I would still think it makes sense to get in touch with someone from the field/sales team. For some reason people seem to focus on snapd and snaps, but for device deployments it’s just part of the problem.
I think it would be useful to have some docs about the typical deployments of devices with snaps, how those are organized, how the device is set up and so on. I had a quick look at core docs, there are docs describing individual building blocks, but it isn’t entirely clear how one would maange a device. Something like a FAQ or use cases. Maybe a topic to research for @degville ?
I think you’re right - it would be really useful if the Ubuntu Core docs had some example deployments, including how they were built and how they’re updated and maintained. I’ll give it some thought and try to get some examples together.
1 Like
The Brand Store. It sounds great but how do we get one or turn our snapcraft account into once since I’m about to deploy core devices to customers? Is there a link on the site to apply and open a brand account? I feel like we are moving by trial and error so some create deployment vs management documentation would be amazing for startup small shops like me, as well as other developers trying to figure out how to best use snap apps in a commercial environment.
to get a brand store, try here:
1 Like
In science, there is what is commonly called the reproducibility crisis . Experimental results from published papers cannot be reproduced, casting doubt on their validity.
To address this, the concept of FAIR (Findability, Accessibility, Interoperability, and Reusability) has emerged. An important part of that is computations that we conducted years ago can be reproduced.
The science project I am employed by is government funded. Part of our grant justification is our commitment to maintaining exact versions of computing environments for years.
We cannot complete our mission in the context of auto updating software.
We understand that, as security issues emerge, it may not be possible to safely run outdated systems live on the Internet. We address this by archiving entire virtual machines, which can then be run locally in a hypervisor sandbox to reproduce computations while not being exposed to the Internet.
We based our platforms on Ubuntu because it seemed like the superior distribution for ease of use and maintability, starting with Ubuntu 16 and then 18. As we’re migrating to 20, this snap behavior presents a major issue. No doubt some of the hacks suggested in the thread will work, so we’ll do that.
It’s just disappointing that we have to.
1 Like
Hello,
This is a difficult comment to draft, because I feel as though stating my feelings honestly and truly will cause them to be taken as a personal attack and thus less seriously, so I’m asking at the outset for any developers / community reps (@ogra @niemeyer ) reading this to lend me a measure of charity as I have tried to do when writing this. I’ve been a Ubuntu desktop user for three or four years now - I’m not a sysadmin or a longtime unix user or anything like that so presumably automatic forced updates are the sort of thing that was developed for relatively unsophisticated people like me, so I genuinely hope you will take my honest feedback into account.
Finding and reading this thread was one of the worst feelings I’ve ever had in computing. My stomach literally dropped. The sensation was first and foremost a feeling of violation. I’ve had things break on my computer, I’ve lost data, but this was the first time I found out that someone I trusted was doing things to my computer against my knowledge and will.
I don’t have a defined workflow or hard system operating requirements or anything like that like others in this thread - the way I use my computer is that I’ll think of something I’d like to do, then I look for software that might be helpful, and then I’ll install it and try it out if it looks trustworthy. Sometimes I only use the software one time, but I generally leave it installed on my machine if it correctly did the thing I wanted it to do.
What you have to understand is that my expectation is that software stays exactly the way it is unless I tell it to change. Developers will frequently update their software to change UI or remove features and this is 100% their right, but the #1 selling point of a free operating system is that I can stick with the software I have on my computer that I know works if I want to.
I am well aware that security updates are very important - every few days Ubuntu Software Updater pops up and prompts me to update this or that system binary and I always click yes - but the important thing is that this happens with my explicit permission.
You see, supply chain attacks are increasingly in the news. Automatic security updates may mitigate a known unpatched vulnerability, but they also allow someone to insert a brand new zero day as part of an attack.
When I found this thread I immediately ran ‘snap list’ and there were three pieces of software on my machine written by now defunct organizations, thankfully last updated no later than 2018. I immediately uninstalled them all, because how am I to know that none of those devs sold or will sell their projects to people with malicious intentions (as far as I know this is a common attack vector in the browser extension store)?
I expect and trust Ubuntu core or Firefox or Spotify or whatever to update itself frequently, but a lot of software is expected to be relatively static. If some random text editor or todolist or image viewer sends me a request through the Software Updater or as an in app prompt to download the latest version I would be suspicious, and I could review the changelog and make sure nothing fishy is afoot. With silent, forced automatic updates, I am simply pwned.
“Update or Postpone Update” is a dark pattern. It’s dirty, it’s nasty, I hate it. I hate it, I hate it, I hate it. I thought I left it behind forever when I uninstalled Windows. Today was a disillusioning day and I hope that maybe this comment will surface a hereto unconsidered perspective from a regular old user. Respect and kindness have been invoked repeatedly in this thread, so I hope you’ll listen when I say that I’ve never felt less respected as I did reading this thread. I’ve been happy with Ubuntu for a long time, and the thought of wasting a weekend installing a different distro weighs heavily on my mind, but I might just have to do it.
-J
4 Likes
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