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