Disabling automatic refresh for snap from store

backlog

#21

I know core images support having ssh turned disabled, is there a way within a snap to have a customer specify when these updates would be able to occur through a management interface. The snap would need a way to trigger the update itself in this instance.

Also in the case of safety concerns is the device is currently moving, my motor control service can’t be shut down. It needs a mechanism to block an update while in motion or during some other critical activity.


#22

Maybe there could have a snap auto-update disable and to update just snap refresh as always


#23

Yeah, that’s exactly the aspect that the conversation above addresses.


#24

What if I’m a desktop user who just wants to feel like I have control over my computer?

I’ve been using Arch for over a year, and I was used to updating at least once a week on that. I recently switched to KDE Neon because Arch lacks debug packages, and of course now I’m stuck with year-old versions of all non-KDE apps because I’m now using Ubuntu 16.04 repositories. One possible way to get modern versions of some apps is by installing their Snaps, but I absolutely refuse to use a packaging system that forces me to update, even though I fully plan to update anyway.

If I wanted my only options to be “update now” and “defer update,” I’d be using Windows 10. I use Linux because I want to have control over my computer, and it’s frankly insulting if anyone thinks they have to force updates on me because they don’t trust me to update my computer myself. I’d like the ability to disable automatic updates simply for the principle of the thing, and I’m sure there are others like me.

From what little information I’ve found, it looks like we either need to accept that developers know best and conform to mandatory updates or use a different packaging system. That seems like a closed-minded attitude toward end users. I can understand having auto-updates as the default behavior, but not having the ability to opt out when it’s clearly technically possible really puts me off of the whole project. Would it really be so bad to allow power users to choose when to update and still take advantage of everything else Snaps have to offer?


#25

Hi Jacob,

You’re clearly a bit frustrated about the topic, and as a consequence word the problem in a confrontational way which creates an us vs. them situation that detracts from the real point. As mentioned above, the issue that makes us resist the idea of simply disabling updates altogether is that very often it will mean never to update rather than update at someone’s discretion, and then we’re getting back to some of the problems that got us here in the first place. That’s why we’ve been resisting introducing that global switch, at least for the time being, and instead working with people to mitigate the undesired side effects of having automatic updates enabled.

On that route, a number of features have been created and others are on the pipeline, such as the transactional operation foundation, multi-revision installations which keeps N revisions around for safety, pretty much instantaneous reverts across these, tracks which enable software publishers to only force updates on critical issues, epochs which introduce stepped upgrades, carefully scheduled updates, health checks which allow ensuring that a revision is safe to update to before it is completed, and so on.

That’s the attitude being taken by this project, and that is not towards you or anyone else. This attitude is towards the problem of enabling systems to be up-to-date and safe. We may very well introduce a trivial global switch at some point, but right now the priority is in working with the community on the low sides of automatic updates, and the examples above are very concrete results of that.

Sounds like this is a problem you’re also very interested on, so your contributions and opinions around improvements would be appreciated. We’ll also understand if your personal priorities and preferences take you elsewhere, though.


#26

Just to add my $0.02 here because it can be difficult to hold the line in situations like this… Even though it’s uncomfortable for us to have auto-updates enabled without an off switch, I believe it’s the right way to go, for servers and embedded devices in particular, or anything headless - it’s the only way we’ll keep them secure over time.

One additional concern, that might not have been covered explicitly above - is around data usage on cellular connections. Many connected devices are on cellular plans with 100MB/mth data allocation.

Having some way to opt out of a very frequent release cadence (especially for large snaps) would be important for these devices.

Maybe a new ‘critical’ track that developers would only release to if a serious issue was identified? e.g. to prevent DDoS


#27

A lot of this sounds great. If possible could we get some more details on the health checks and carefully scheduled updates?

To add another case, this might fall under carefully scheduled updates, is it possible to ensure that a customer has all the same versions at a site? This might look like all devices signaling that they are ready for update before a simultaneous update. I could see a snap attempting to trigger them all by the core api for a refresh at the same time, but that wouldn’t ensure one did not update earlier.


#28

Thank you for the serious response. I did edit my post several times when I realized how confrontational it sounded, and I apologize that it still sounded that way in its final form.

In order to help you understand where I’m coming from, let me explain the first thoughts I had when I found out that snaps auto-update. I use RocketChat for my small group of video content creators. It provides a well-organized communication system, and because it’s both open-source and self-hosted, we can be sure it’s completely private (as far as our security practices will allow.) I used to have RocketChat installed manually, and I would skim through the changelogs before I applied an update.

Here’s a very practical concern I had about switching RocketChat from manual to Snaps: if the snap will automatically pull in any update the developer publishes, then the developer could publish an update that adds a backdoor and allows outside access to my private chats. Of course, the chats on my server don’t store very sensitive information, but once again, I support privacy out of principle, not because I’m keeping secrets.

I understand that the RocketChat developers would be hard-pressed to find a reason to publish such an update, and that doing so would cause all sorts of other problems I’m not addressing. Additionally, I trust the RocketChat developers not to publish an update that adds a backdoor, but with free & open software, I’m not supposed to have to trust the developers, I’m supposed to be able to see things for myself, before I install it on my server/computer.

I know this is only a hypothetical scenario, but all security flaws are hypothetical before they’re exploited. With how overreaching the US government has become in recent years, it’s conceivable to me that they might, say, attempt to force the RocketChat developers to publish an updated Snap with a backdoor to infiltrate the RocketChat server of somebody under investigation. There’s also the possibility of desktop app Snaps being updated to access a computer’s camera, microphone, or filesystem, although from what I understand there may be some security features in Snaps that could prevent that from happening.

Ultimately, I switched my RocketChat server to using Snaps because I know they’re coming down the pipeline whether I want them to or not. (A few weeks later, I had a failed update take my server offline and manual intervention was required to get it working again.) But I’m not comfortable using Snaps on my personal desktop computer as long as it’s set up in a way where the developers give me a time limit to review their code before it’s installed to my system without my knowledge or consent. Does that make sense?


#29

I don’t see this “exception” any different than other exception for critical systems (ie example of having snaps in a car or any kind of critical machinery or [in my case] breaking the network for a few seconds to minutes because of snap updates.) Some places this might be a danger of high cost (data or outage damage) or potentially other serious harm.
I think some of these places are just not (yet) ready for snap packages - or maybe just not for snap packages from the store as manual installs are not triggering any updates.

As a sidenote, trying to understand the concept of the tracks, so I can potentially make a difference between critical new snap’s or just minor (ie help text) fixes.
Anyone knows a snap which is a good example and has this implemented?


#30

So if you use the scheduling function to delay to the maximum that @niemeyer described above but get a notification about upcoming changes the day they show up in the store (including a date info when the actual update will be) would that help ?


#31

@brendan.carroll Indeed. We’ll definitely be implementing the proposal above soon, and it will address that. Our current plan is to enable scheduling on one or more days of the week within the month (e.g. 2nd Tuesday, between 9am and 10am).

As an aside, note that even for large snaps the downloads are actually deltas on top of the local revision

@cratliff Of course. There are at least three different features that cover the detailed scheduling:

  • One or more precise time windows may be defined for the whole system to update under. Today that window is constrained to a daily basis, and we’re changing that so that it may be scheduled to one or more days of the week within the month, per the example above.
  • Soon we’ll also enable the administrator to explicitly defer a scheduled update so that it doesn’t happen in the next so many hours or days. There will be a limit to the postponing, but it’ll be non-trivial (probably over a month).
  • Then, snaps will also have a saying on whether it is a good time or not for an update to happen. There are many cases which can easily benefit from scheduled updates, but have strict windows in which they cannot happen. For example, Spotify is being used right now to listen to music, so don’t update it.

As for health checks, the snap will be able to define a hook that verifies whether the snap is working well after the update. This may hold arbitrary logic. If the health check fails, the snap will be automatically reverted. This same mechanism will also be used to implement canary rollouts, in which a controlled number of systems is updated and if a relevant number of them report a failure, the upgrade is stopped and the status is reported back to the snap publisher.

Yes, there will certainly be management platforms for controlling site-wide deployments, but that falls slightly outside of the scope of the core snapd project itself.

@jacobgkau There are a number of valid concerns about auto-updates that we’re trying to address, but I don’t see how this particular problem is made any worse with auto-updates or how we might even do much about at all, in the sense that there will always be an element of trust on the publisher of the snap no matter what we do. In other words, whether you manually update or automatically update a snap, for using the snap at all you have to trust that the developer is not simply shipping your private conversations to arbitrary third-parties for example, in the case of a chat service.

With or without auto-update the publisher might add such a backdoor on the next update, and that backdoor will remain there for as long as that update is installed on your system, which means at least 3 months to review the backdoor assuming the auto-update scheme above since we keep three revisions around, and you may always just copy it out onto a separate space to review in the future.

So the situation is really not that different from a manual update.

@mwinter Yeah, some of the features above are aimed at such scenarios.

Right, that’s indeed the purpose of tracks. There are more details in this topic.

As for examples, I suggest having a look at the requests in the store category.


#32

@ogra Sure, but think about this. Here’s how things used to work:

  • Developer publishes an update
  • I update when I’m comfortable updating

Here’s how you’re proposing I work instead:

  • My computer will install all updates automatically by default
  • I set a “schedule” delaying updates for the arbitrary maximum amount of time
  • Developer publishes an update
  • I have a time limit for how long I have to get comfortable updating
  • When I am comfortable updating, I update manually, taking away the point of the auto-updater

This is making things so much more complicated for me when my current non-snap system does exactly what I want it to do, exactly when I want it to do it, by default. What you’re suggesting is a workaround to a problem that Snaps have gone out of their way to create.

@niemeyer The difference is, with auto-update the update is being installed on my system automatically, and without auto-update I am choosing to install that update on my system. You’re taking away my element of choice.

If I install a bad update on my system, that’s on me. If my computer auto-installs a bad update, that’s on the auto-update system (or on me for using the auto-update system.) Is the end result the same? Yes. But I was given the chance to avoid it in one case, and I wasn’t given any options in the other.

Again, if I’m using a “scheduling” feature to delay auto-updates to their maximum length, but I’m obviously going to want to update sooner than that in practice, the entire auto-update feature is adding work for me while not affecting my final update schedule at all… so why doesn’t the system just allow me to turn off auto-updates?

(Answer: because developers don’t trust normal users to update their computers if they have the option not to, even if auto-update is on by default. Where’s the trust there?)


#33
Original response folded for not contributing much to the topic.

I was specifically responding to the actual point you made regarding trust on the snap being published.

I’m glad to hear the automatic update won’t in fact be a problem for you in practice. This is the key thing we want to ensure.


#34

It’s going to be a problem for me in practice because in practice, I’m not going to use it.

Did you miss the part where I said, “the entire auto-update feature is adding work for me?” You’re talking circles around me at this point, and I can see I’m not going to get any further here. I hope you become less stubborn in the future, but for now, thank you for taking the time to talk to me as long as you have.


#35

I’ve posted the proposed syntax for within-the-month refresh windows as an answer to this existing topic:


#36

Not trying to be confrontational but technically yes that does seem to be what snappy is doing at the moment…

Pretty sure the above quote proves it :stuck_out_tongue: snappy won’t allow disabling updates because snappy worries that people just won’t update - it doesn’t trust its users. Phrasing it as Jacob has is confrontational but correct.

I can see the benefit of taking this decision in the medium-term though, it provides an incentive to produce features that will encourage developers not to use the kill switch if it is eventually introduced (similar to Niemeyer’s decision to block improving snapd-xdg-open packages so as to produce an incentive to get that integrated into snapd itself). Sorry for the notifications spam BTW, but you write interesting stuff!


#37

This view is way too narrow … what snap tries to do is to take away any need for having to care about updates by improving the package environment in a way that software can take care of it itself, can do self tests, can automatically roll back to the last working version.

The only way to achieve security of software (to protect it from mirai attacks or from infection by encryption trojans) is to keep it with the least amount of vulnerabilities by keeping it updated in the timeliest possible manner. The only factor that breaks this principle is human intervention.

Let’s take a look at a typical sysadmin today. When an upgrade comes in he will hold it back and run a bunch of tests … if these tests succeed he will check for the best time to apply the update to all users and roll it out … or perhaps he is doing staged updates and gives it to a small subset of his users first …

Now imagine the package management actually offers to have these tests included in the package by upstream, so admins can submit their use case tests to be shipped and run automatically (including auto-rollback) by the package management… it also has a scheduling feature and rollout control …

What snappy tries to do is not take away trust from anyone, but improve and encourage automation by providing an easy environment for it. If there is any trust shifted around then it is actually shifted towards developers and their ability to ship good tests.

The final target is completely self-maintained machines through automation, the developers working on this (including the ones from the community i met) are way to excited about the technical aspects and possibilities of this to actually think about trust or dis-trust or any other political topics :wink:


Snapcrafters GitHub repo release process
#38

In the case of an IoT device, would an application snap be able to use that same mechanism to schedule updates of the core or kernel snap if those updates would interrupt operation? I haven’t read as much about the update of those snaps or how their updates interacts with the system. It would be good to have more information on.


Weird udev_enumerate error
#39

Indeed they would. Both the scheduling and the deferring would work for all snaps, including kernel, gadget, core, and any other application pre-seeded into the device as well.


#40

It’s certainly very exciting stuff! :smiley: