search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
534 stars 47 forks source link

Automatic updates #4282

Open DemiMarie opened 6 years ago

DemiMarie commented 6 years ago

Important features:

Nice to have:

Constraints: Automatic updates should be a background process that does not interfere with active use of the system. In general, it should never force the users to do anything they don't want to do and should never interfere with their work. (If users choose to sacrifice security for uptime by not rebooting when prompted, for example, that's on them.) In practice, this means ideally using system resources only when the system is idle, or at least limiting CPU usage, disk I/O, bandwidth usage, and memory usage. Since downloading updates requires starting sys-net and sys-firewall, and downloading updates over Tor requires additionally starting sys-whonix, it may be necessary to delay this if too many VMs are already running. This also raises the point that, for download-now-install-later cases, there must be somewhere to store the updates while they wait to be installed.

Original issue description: ### Qubes OS version: R4.0 ### Affected component(s): qubes-core-admin --- ### Steps to reproduce the behavior: Look for an automatic updating feature ### Expected behavior: There is a way to tell QubesOS to automatically check for updates, and automatically install any it finds. Afterwards, it would prompt the user to reboot any affected VMs. ### Actual behavior: No such automatic update feature ### General notes: Windows already does this. --- ### Related issues:
marmarek commented 6 years ago

This depends on https://github.com/QubesOS/qubes-issues/issues/2718, if it isn't a duplicate of it.

andrewdavidwong commented 6 years ago

Duplicate of #2718

andrewdavidwong commented 6 years ago

This appears to be a duplicate of #2718, since the description of #2718 states:

Qubes needs a way to handle multiple OS updates automatically since managing these processes individually is disruptive to the user.

If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

andrewdavidwong commented 3 years ago

Actually, I no longer believe that this is a duplicate of #2718, since automatic updates are not the same as a tool for performing multiple updates at the same time. (However, there is a risk that this will turn out to violate the rule that every issue must be about a single, actionable thing. We'll see.)

Copying my own comment from https://github.com/QubesOS/qubes-issues/issues/6299#issuecomment-749322108:

I've been thinking about this lately too. Ideally, I think Qubes should install all mandatory updates (especially mandatory critical security updates) automatically, in the background, without any user awareness (much less action) required. There should be options for not downloading updates over metered connections and for advanced users to opt out entirely. There should also be options for downloading (but not installing) non-mandatory updates and automatically installing all updates. (The appropriate defaults for non-mandatory updates are more open to debate.)

One of the biggest pain points is that updating can take a very long time, especially with many templates, especially over Tor. There's no reason that a human should be have to sit and wait while update data is being downloaded. It should be downloaded in the background (when appropriate, as unobtrusively as possible).

Another problem is users not knowing what exactly to do or not taking the appropriate action at the right time when a critical security update is released, such as when a new QSB is issued. For virtually all normal users, we already know that they want to install security updates when those updates are stable (and some even earlier, i.e., from security-testing). So, the logical default is for all stable security updates to be installed automatically. Qubes should be secure by default and keep itself that way by default.

Xen and kernel updates will require a dom0 reboot, but requiring a reboot after certain updates is nothing new for an operating system. Just handle this in the usual way: by notifying the user that a reboot is required and letting them choose when to do it. (Of course, the system should never forcibly reboot. The user gets to control the system; not the other way around. Which is, again, why there should also be an option to opt out of all of this.)

andrewdavidwong commented 3 years ago

Updated issue description.

ninavizz commented 3 years ago

I've been thinking about this lately too. Ideally, I think Qubes should install all mandatory updates (especially mandatory critical security updates) automatically, in the background, without any user awareness (much less action) required.

I disagree with the opacity nod for users; some level of user awareness should always exist, but I agree, it all needs to be far more streamlined, holistic, and customizable, than it is today. And, I think we're both on the same page in spirit, which is simply that updates should not be "a job" for users. I even think it'd be terrific if non-RPM and Salt involved updates could somehow be tied-into a complete "Updating All The Things" experience.

In the AppMenu survey, we've also had some requests for "security updates from the UI." No idea what that meant—but, FYI.

@marmarek The next thing on my plate is Policy Manager. Where do you see a new Updater experience, as a design and research priority, after Policy Manager?

marmarek commented 3 years ago

@marmarek The next thing on my plate is Policy Manager. Where do you see a new Updater experience, as a design and research priority, after Policy Manager?

Yes, after Policy Manager. I imagine the most work on updates would be about the backend (make it faster and lighter), as the UI is (and IMO should be) rather minimal.

andrewdavidwong commented 3 years ago

I've been thinking about this lately too. Ideally, I think Qubes should install all mandatory updates (especially mandatory critical security updates) automatically, in the background, without any user awareness (much less action) required.

I disagree with the opacity nod for users; some level of user awareness should always exist, but I agree, it all needs to be far more streamlined, holistic, and customizable, than it is today.

The difference is between "awareness is required" and "awareness should exist." Many users, especially overwhelmed novices and non-techies, can be somewhat oblivious in their computer usage. Even if you shove a dialog box right in their face that they have to click "OK" to dismiss, many of them will click it away as fast as possible without even reading it, as if their brain only sees "Click OK to get rid of this annoying pop-up" rather than whatever important message it actually says. A less intrusive notification near the corner of the screen could easily go entirely unnoticed. If awareness is required, then these users are out of luck. Thankfully, there is no reason that these users have to be aware that Qubes (or, really, any operating system) is keeping itself up-to-date, so we can still keep them safe in that respect.

And, I think we're both on the same page in spirit, which is simply that updates should not be "a job" for users.

Yes, but I think it goes beyond that. Even users who think they are willing to take on the "job" of keeping their systems up-to-date often perform that job poorly. For example, they may delay checking for, downloading, or installing security updates for too long, whether because they forgot or because they have misconceptions about the appropriate interval at which to perform such actions.

I even think it'd be terrific if non-RPM and Salt involved updates could somehow be tied-into a complete "Updating All The Things" experience.

I'm not sure that any such updates exist. This is about updating dom0, TemplateVMs, and StandaloneVMs, which should cover everything in Qubes OS. In any case, that would probably be a separate issue.

In the AppMenu survey, we've also had some requests for "security updates from the UI." No idea what that meant—but, FYI.

There are at least two things that could be referring to. See here: https://github.com/QubesOS/qubes-issues/issues/6299#issuecomment-846451060, https://github.com/QubesOS/qubes-issues/issues/6299#issuecomment-846452255

@marmarek The next thing on my plate is Policy Manager. Where do you see a new Updater experience, as a design and research priority, after Policy Manager?

I think we should keep this issue separate from any UX issues about the Qubes Updater experience or any GUI frontend for managing automatic updates. I would like to give this issue the highest chance of actually getting implemented, meaning keeping it reasonably small and tractable for the devs, rather than huge and overwhelming to the point where no one even knows where to begin. As mentioned above, this may already be too big to to be a single issue, in which case we could make an "Automatic Updates" project instead with individual issues inside that project. @marmarek, @DemiMarie, would you prefer that? The problem is I don't know exactly what the individual issues inside such a project would be (i.e., the most logical way to break this up into smaller tasks), so I'm afraid that if I try to do it for you, it may be unhelpful.

DemiMarie commented 3 years ago

@marmarek The next thing on my plate is Policy Manager. Where do you see a new Updater experience, as a design and research priority, after Policy Manager?

I think we should keep this issue separate from any UX issues about the Qubes Updater experience or any GUI frontend for managing automatic updates. I would like to give this issue the highest chance of actually getting implemented, meaning keeping it reasonably small and tractable for the devs, rather than huge and overwhelming to the point where no one even knows where to begin. As mentioned above, this may already be too big to to be a single issue, in which case we could make an "Automatic Updates" project instead with individual issues inside that project. @marmarek, @DemiMarie, would you prefer that? The problem is I don't know exactly what the individual issues inside such a project would be (i.e., the most logical way to break this up into smaller tasks), so I'm afraid that if I try to do it for you, it may be unhelpful.

Automatic updates are actually completely trivial to implement: just add a cron job or systemd timer that spawns qubesctl. The hard part, of course, is implementing them properly. At a minimum, that means updating only the qubes that need updates, not consuming massive amounts of CPU and I/O, and providing human-readable and reliable indications of success or failure.

andrewdavidwong commented 3 years ago

Automatic updates are actually completely trivial to implement: just add a cron job or systemd timer that spawns qubesctl. The hard part, of course, is implementing them properly. At a minimum, that means updating only the qubes that need updates, not consuming massive amounts of CPU and I/O, and providing human-readable and reliable indications of success or failure.

Agreed, but I thought this was already obvious (at the very least, it should be obvious that anything we implement, we want to implement properly). However, it is probably a good idea to be explicit about these constraints and extra desired features, so I've added a new "Constraints" section to the issue description and added a couple more items to the "Nice to have" list.

ninavizz commented 3 years ago

A less intrusive notification near the corner of the screen could easily go entirely unnoticed. If awareness is required, then these users are out of luck. Thankfully, there is no reason that these users have to be aware that Qubes (or, really, any operating system) is keeping itself up-to-date, so we can still keep them safe in that respect.

I honestly wasn't even thinking of notifications of any kind. If the "Automatic Updates" are just opted-into by default, and with a lot of "Hey now, you REALLY don't want to do this" fanfare should the user choose to opt-out. "Visibility" can happen in many ways, including just having functionality grayed-out as "Locked" but shown as currently "On" in a control panel.

ALSO: I am keen to keep UI facing things out of this, for the most part, as I am also with Andrew in wanting to see this go through.

DemiMarie commented 3 years ago

A less intrusive notification near the corner of the screen could easily go entirely unnoticed. If awareness is required, then these users are out of luck. Thankfully, there is no reason that these users have to be aware that Qubes (or, really, any operating system) is keeping itself up-to-date, so we can still keep them safe in that respect.

I honestly wasn't even thinking of notifications of any kind. If the "Automatic Updates" are just opted-into by default, and with a lot of "Hey now, you REALLY don't want to do this" fanfare should the user choose to opt-out. "Visibility" can happen in many ways, including just having functionality grayed-out as "Locked" but shown as currently "On" in a control panel.

ALSO: I am keen to keep UI facing things out of this, for the most part, as I am also with Andrew in wanting to see this go through.

I would very much like to have a UI for viewing update logs, but it doesn’t need to be on the front page, so to speak.