Replace built-in Qube Manager update functionality with the Qubes Update tool

[andrewdavidwong]

The problem you're addressing (if any)

There are currently three methods for updating things in Qubes OS:

1. Direct commands (e.g., qubes-dom0-update, dnf update, apt update).
2. The Qubes Update tool / equivalent qubesctl commands.
3. Selecting a VM in the Qube Manager and pressing the "Update" button.

(1) and (2) have clear use cases and their own advantages. (3) is a weird in-between method that is inferior to (2). For example, historically, not all of the Salt fixes applied by (2) have been applied by (3), which is a security problem.

It is also suboptimal and confusing to users to have and maintain two different GUI update methods. It also would significantly complicate the Updating Qubes OS documentation (and this proposed announcement), which currently just pretend this third method does not exist, for the sake of user comprehension.

Describe the solution you'd like

Get rid of this weird, third update method. Replace it with the Qubes Update tool.

The simplest, easiest way to start would be to simply open the Qubes Update tool whenever the "Update" button in the Qube Manager is pressed.

There are ways to make this nicer. For example, whichever VM is selected when the button is pressed could already be "checked" for you in the Qubes Update tool.

Where is the value to a user, and who might that user be?

All users who are confused about how to update Qubes OS, whether to use the Qube Manager update functionality, etc.

Describe alternatives you've considered

Leaving things as they are, updating the documentation to explain, "Well, you see, there's also this third method, which is not exactly the same as either of the other two methods and has no clear use case aside from the other two. You can use it if you want, and it will probably be okay, but that hasn't always been the case in the past..."

Users have to make this murky choice between very similar options and try to puzzle out what to do.

It's much easier to be able to say, "Here's how to update Qubes OS: Use the Qubes Update tool."

That's why I've chosen to keep the documentation (and this proposed announcement) simple and pretend that the weird third method doesn't exist, but that doesn't stop it from existing or stop users from discovering it, trying to use it, and becoming confused by it.

Additional context

• User discovering that using the weird, third method to try to update dom0 appears to do nothing: https://github.com/QubesOS/qubes-issues/issues/4652
• Users (including me) confused about weird, third method and discovering that using it to update dom0 actually does do something, just doesn't show or tell you anything: https://qubes-os.discourse.group/t/recommendation-against-qubes-dom0-update-use-qubes-updater-instead/4131/7?u=adw

Related, non-duplicate issues

I thought we already had an issue for this, but I can't find one.

As mentioned above: https://github.com/QubesOS/qubes-issues/issues/4652

[GWeck]

For fedora and debian templates (and some others), clicking the update icon in Qubes manager starts a window which first retrieves which updates should be performed, displays the list and gives the user the choice of performing the update or deciding not to do so - which may be desirable in some cases, e.g. if the proposed update has to download a significant amount of data, which may be undesirable at the current moment.

For this reason, I use this method more often than the Qubes updater which just starts and later tells me what it has done.

If the updater would give me the choice to see beforehand what it intends to do and then allow me to decide for each VM if it should be updated, that would be a great help. On the other hand, this probably will be very difficult to implement, since the current solution shows information obtained within the templates whereas the updater runs outside.

[qubicrm]

could this be solved by notification? I share @GWeck thoughts on the advantage to decide to update or not, based on the info I read at the terminal (methods 1 and 3) and I also use that methods often I guess a notification that says "there is updates available, but be sure to use Qubes Update Tool / qubesctl this time" could solve the problem, yet keeping the various methods. ( BUT This does not solve the increasing complexity of documentation)

[unman]

On Tue, May 25, 2021 at 02:26:24AM -0700, Dr. Gerhard Weck wrote:

For fedora and debian templates (and some others), clicking the update icon in Qubes manager starts a window which first retrieves which updates should be performed, displays the list and gives the user the choice of performing the update or deciding not to do so - which may be desirable in some cases, e.g. if the proposed update has to download a significant amount of data, which may be undesirable at the current moment.

For this reason, I use this method more often than the Qubes updater which just starts and later tells me what it has done.

If the updater would give me the choice to see beforehand what it intends to do and then allow me to decide for each VM if it should be updated, that would be a great help. On the other hand, this probably will be very difficult to implement, since the current solution shows information obtained within the templates whereas the updater runs outside.

This is the difference between an interactive and non-interactive update process. The Qubes updater is supposed to be non-interactive. It could, I suppose, be changed to be interactive, but for whose benefit? How many users are able to make the decision as to whether to apply (some) updates or not? Interestingly, Debian and Ubuntu have moved to an unattended upgrade model where updates will be applied automatically. This feature is disabled in Qubes.

[andrewdavidwong]

@GWeck:

[...] Qubes manager starts a window which [...] gives the user the choice of performing the update [...] For this reason, I use this method more often than the Qubes updater which just starts and later tells me what it has done. If the updater would give me the choice to see beforehand what it intends to do and then allow me to decide for each VM if it should be updated, that would be a great help. [...]

@unman:

This is the difference between an interactive and non-interactive update process. The Qubes updater is supposed to be non-interactive. It could, I suppose, be changed to be interactive, but for whose benefit?

Improved support for interactive updates is a separate issue: https://github.com/QubesOS/qubes-issues/issues/6624

I see @GWeck's use case as a reason to improve the Qubes Update tool (tell you what it's going to do before it starts doing anything) or do #6624 first, not a reason not to do this.

---

@qubicrm:

could this be solved by notification? [...] I guess a notification that says "there is updates available, but be sure to use Qubes Update Tool [...] [...] could solve the problem, yet keeping the various methods.

This is already how it works. By default, when available updates are detected, there is an icon in the Notification Area that opens the Qubes Update tool. See: https://www.qubes-os.org/doc/updating-qubes-os/

This issue is not about that. This issue is about the update functionality built into the Qube Manager. There would be no point in implementing another update notification mechanism into the Qube Manager to accommodate the extra update mechanism there. That's the exact opposite of the direction we should be going.

[qubicrm]

This is already how it works. By default, when available updates are detected, there is an icon in the Notification Area that opens the Qubes Update tool

yes, of course. What I mean is you never know when there advantage to use qubesctl / salt thing (in case there are updates that can not be delivered by sudo qubes-dom0-update). That could be addressed by notification (inform the user) Sorry for the lack of clarity.

[andrewdavidwong]

What I mean is you never know when there advantage to use qubesctl / salt thing (in case there are updates that can not be delivered by sudo qubes-dom0-update). That could be addressed by notification (inform the user)

Still a bad idea. The user should never have to understand which types of updates are available and make a decision on that basis about which update tool to use. That's just asking for all sorts of trouble. Users will get confused, use the wrong tool, etc., not to mention that it creates extra work and requires extra thought from the user for no good reason. Thankfully, the user doesn't have to do this even now, as long as they follow the documentation and stick with the Qubes Update tool. The proper eventual solution is to make updates automatic (#4282).

[GWeck]

Making updates automatic is a very dangerous method. Windows 10, which has this feature, is practically unusable in a professional environment, because updates happen during execution of professional tasks and may even wreck a completely sane system. In a certified environment, updates may even be completely forbidden, so that automatic updates are completely out of scope. For these reasons, I would strongly recommend against automaatic updates.

[DemiMarie]

Making updates automatic is a very dangerous method. Windows 10, which has this feature, is practically unusable in a professional environment, because updates happen during execution of professional tasks and may even wreck a completely sane system.

Qubes OS allows reverting any update via the qvm-volume revert TemplateVM:root command. Further reverts can usually be done via the distribution package manager. Stable distributions like Debian and openSUSE Leap aim to minimize the likelihood of breakage due to updates. Finally, updates in Qubes OS are applied to TemplateVMs, and do not interfere with the usage of AppVMs based on these TemplateVMs. The updates are applied when the AppVM is rebooted.

In a certified environment, updates may even be completely forbidden, so that automatic updates are completely out of scope. For these reasons, I would strongly recommend against automaatic updates.

Qubes OS is not suitable for such environments, as the lack of security patches mean that Qubes-provided isolation would eventually be broken. Systems that need to guarantee isolation even without security patches should use a formally verified hypervisor, such as seL4, together with static partitioning, such as provided by CAmkES. Qubes OS does not use seL4 as the tooling is currently insufficient for highly dynamic systems.

[marmarta]

Making updates automatic is a very dangerous method. Windows 10, which has this feature, is practically unusable in a professional environment, because updates happen during execution of professional tasks and may even wreck a completely sane system. In a certified environment, updates may even be completely forbidden, so that automatic updates are completely out of scope. For these reasons, I would strongly recommend against automaatic updates.

I mean, Qubes will never do the Windows-10 thing of rebooting your system (or VM) randomly. You need to reboot the VM yourself to see changes.

[ninavizz]

All-everything related to updating, needs to somehow be exposed to the user to promote user agency and knowledge around what's happening on their device. We tell people every time a VM opens or closes, we should also be just as transparent about updates.

Without sounding too dramatic, I'd like to nominate the entire Qubes updating experience for a refresh; namely, because I feel it's quite scattered, is opaque about things "for my own good" that I'd at least prefer it be transparent about, and lacks the opt-in/opt-out controls users need. Contextual notifications and UI flags can let folks know what is really outside their best interest. Security paternalism is bad. :)

Qubes users would also have a better general experience with Qubes, if notifications were better handled as "families" that either do passive task-bar-only type messaging, longer-form toast bubbles, or accept/deny dialogs. Today's firehose of black toast bubbles and the window layering/focus problems presented with dialog actions being blocked because the user just never saw the window, are overwhelming.

[andrewdavidwong]

Comments about automatic updates are off-topic here. Please take them to #4282 instead.

Without sounding too dramatic, I'd like to nominate the entire Qubes updating experience for a refresh; namely, because I feel it's quite scattered, is opaque about things "for my own good" that I'd at least prefer it be transparent about, and lacks the opt-in/opt-out controls users need. Contextual notifications and UI flags can let folks know what is really outside their best interest. Security paternalism is bad. :)

This is incredibly inaccurate (Qubes is the opposite of security paternalism) and also off-topic here.

[ninavizz]

@andrewdavidwong You said: The user should never have to understand which types of updates are available and make a decision on that basis about which update tool to use. That's just asking for all sorts of trouble. Users will get confused, use the wrong tool, etc., not to mention that it creates extra work and requires extra thought from the user for no good reason.

What you describe is paternalistic, and removing agency from users. In fact, survey respondents have asked to know what types of updates are available—and I've always questioned why this isn't surfaced more clearly.

[andrewdavidwong]

@andrewdavidwong You said: The user should never have to understand which types of updates are available and make a decision on that basis about which update tool to use. That's just asking for all sorts of trouble. Users will get confused, use the wrong tool, etc., not to mention that it creates extra work and requires extra thought from the user for no good reason.

What you describe is paternalistic, and removing agency from users.

"The user should never have to understand..." means that the user should never have to understand and make a decision. It does not mean that the user should not be allowed to understand and make a decision. It does not mean that the user should not be informed. It means exactly what it says, nothing more.

What we're talking about here is an obscure technical distinction: updates that can be delivered via the underlying conventional package manager vs. actions that have to be performed via Salt. There is no reason that a Qubes user should be forced to understand this distinction and be forced to identify it when an update occurs and be forced to choose the correct update tool that will properly handle the update depending on which type it is... all just to make sure that Qubes is keeping itself as secure as when the devs shipped it. In fact, the user should not be forced to do any special work just to keep Qubes secure. Qubes should be secure by default and keep itself that way by default, unless the user says otherwise.

In fact, survey respondents have asked to know what types of updates are available—and I've always questioned why this isn't surfaced more clearly.

Do you really think that when users in that survey say "types of updates" they mean "updates that can be delivered via the underlying conventional package manager vs. actions that have to be performed via Salt"? Isn't it more likely that they mean things like "required vs. optional updates," "security vs. non-security updates," "urgent vs. low-priority updates," "updates for pre-installed vs. user-installed apps," or something along those lines?

More generally, why would you assume the worst? Why would you assume that I mean something nonsensical and anti-user rather than the opposite? Does my track record and the history of my actions on this project count for nothing?

[unman]

On Wed, May 26, 2021 at 01:37:11PM -0700, Nina Eleanor Alter wrote:

@andrewdavidwong You said: The user should never have to understand which types of updates are available and make a decision on that basis about which update tool to use. That's just asking for all sorts of trouble. Users will get confused, use the wrong tool, etc., not to mention that it creates extra work and requires extra thought from the user for no good reason.

What you describe is paternalistic, and removing agency from users. In fact, survey respondents have asked to know what types of updates are available???and I've always questioned why this isn't surfaced more clearly.

I think there's an issue here Nina - you want to make Qubes available to, and usable by, non-technical users,(Good), but you don't want to have them understand the technical background to what they do in Qubes.(Bad) You think that a good UX will replace the technical understanding. That is paternalism by UX, common in Apple world. It does remove agency from users.

I think the survey comments probably meant "What do I have to do now?" as opposed to "What should I do when I feel like it?", rather than talking about mechanisms. But speculating about what comments might have meant seems fruitless.

We have moved wildly off topic. For what it's worth, I think that the original suggestion was right - the multiplicity of routes to updates isn't helpful at the moment, when they (seem to) do different things. Either they should perform a common task, or one or other be removed: neither seems particularly difficult to implement.

[DemiMarie]

I think there's an issue here Nina - you want to make Qubes available to, and usable by, non-technical users,(Good), but you don't want to have them understand the technical background to what they do in Qubes.(Bad) You think that a good UX will replace the technical understanding. That is paternalism by UX, common in Apple world. It does remove agency from users.

Form my perspective, having technical understanding will obviously be helpful, but it should never be necessary.

[GWeck]

@unman

Either they should perform a common task, or one or other be removed: neither seems particularly difficult to implement.

Exactly: There are many ways to Rome, but they all lead there, and it should be up to the user which onen s/he chooses. If theym all lead to the same result, it is possible to use the one that fits best to one's needs.

[ninavizz]

@unman I promise you, I do not want to "dumb down" tasks for users. At all. Ever. I want to make entry points intuitive and accessible to them, as well as inviting—and to then provide clear paths within the UI to learn more, as well as points in the UI to external documentation for them to grow their knowledge. Which I believe is what all of us want. Apple Paternalism ≠ good, in my book. I'm a Mac user, and I resent their paternalism so much (yet remain a Mac user for many reasons, most of which being that most other designers are also on Macs and for work I have to have a Mac).

Folks like you and @andrewdavidwong and so many others, have taken great pains to write phenomenally helpful and thorough technical documentation. I want users consuming that stuff! It's just a crappy reality, that most humans are too lazy to self-initiate the consumption of technical information, without it being plopped in front of them with a need of their own as context for that learning—as well as the available time to learn. Which, per a note from Andrew in a different forum last night, they need to make—but we should never force when they chose to make that time for deep learning and knowledge development.

Look, I really do believe we all want the same things. Which I don't want to beat to death in writing or philosophical theorizing, but will hope you consider when I share wireframes and prototypes. I communicate with visuals, far better than I do with remote and asynchronous words.

@andrewdavidwong I believe users meant "Security" vs "Feature" vs "BugFix" updates, in their survey comments. Enabling users to have easier visibility into and management of non-RPM and Salt stuff, is a totally separate dragon to slay that I'd eventually like to tackle, but not with this or other existing issues.

What you're advocating for with this issue, I want. We both want. Please know that. I also have ideas I'd like to wireframe, for how to improve/focus the updating experience from how it is today—which I can share in a more general issue, in a few weeks. Please do know that I am not trying to fight you, though. As such, I'll bow out of the rest of this thread, as I don't feel I've "helped" and have instead distracted a lot, from its intent.

[unman]

On Thu, May 27, 2021 at 11:26:20AM -0700, Nina Eleanor Alter wrote:

@unman I promise you, I do not want to "dumb down" tasks for users. At all. Ever. I want to make entry points intuitive and accessible to them, as well as inviting???and to then provide clear paths within the UI to learn more, as well as points in the UI to external documentation for them to grow their knowledge. Which I believe is what all of us want. Apple Paternalism ??? good, in my book. I'm a Mac user, and I resent their paternalism so much (yet remain a Mac user for many reasons, most of which being that most other designers are also on Macs and for work I have to have a Mac).

@ninavizz I actually have no problem with dumbing down - an introductory Qubes which has been set up with a custom menu focussed on activities not qubes, and as little access to templates, Manager, and policies is a great introduction. We did talk years ago about having "flavours" of Qubes, and I still think this is a good way to go. My experience mirrors Andrews - most naive users do not need access to (most) policies at all. Once they have gained experience in working with Qubes then they can be introduced to templates/policies and the like. Even then there should be a strong steer away from some areas and some combinations of policy.

I cant say how pleased I am that you are bringing your experience to the project. It's something I have advocated many times over the years. There is one difficulty. :-( You have said you communicate best in images (although your words belie this) - that isn't good for me. Keep plugging away.

[ninavizz]

@unman Right—and what you're describing, does not follow best practices for users, under any circumstances. Even though I appreciate it's what security advocates w/o direct experience in user research, have advocated for. For years. Which is why all of this is hard, and we're all working together to solve these hard problems.

"Visual" would have been a better descriptor, than "Images." But, more concretely, speaking to specific problems we're both working on, with specific solution ideas, vs the more broad philosophical stuff, is closer ground towards my own ideal of "Visuals." I value your insights a great deal—and if visual examples (eg: wireframes) don't work for you, I'd love to know what might. That doesn't involve code—as, regrettably, my brain can't go there (really, I've tried). Like... alt-text-ish descriptions of wireframes and interactivity to specific problems?

[andrewdavidwong]

Would you all please take the off-topic discussion elsewhere? I shouldn't have to keep asking. This kind of flagrant disregard for our issue tracking guidelines by official team members sets a poor example for the rest of the community (not to mention that I'm getting tired of having to collapse all of these comments).

[andrewdavidwong]

Example of user confusion over the two different update methods:

https://www.reddit.com/r/Qubes/comments/o65jin/update_templatevm_in_qubes_update_or_qubes_manager/

[ninavizz]

Ok. I think I misunderstood the topic of this issue, initially, then. So: You're highlighting @andrewdavidwong that there are currently two entirely different vehicles for performing updates, not just two different places in the UI to invoke identical actions—and this issue is to remove the path from Qube Manager, replacing it instead with a redundant UI invocation of the action in Updater?

[andrewdavidwong]

Ok. I think I misunderstood the topic of this issue, initially, then. So: You're highlighting @andrewdavidwong that there are currently two entirely different vehicles for performing updates, not just two different places in the UI to invoke identical actions

Correct.

and this issue is to remove the path from Qube Manager, replacing it instead with a redundant UI invocation of the action in Updater?

Whatever is the best solution. I just don't want users to continue to be confused by the existence of these two different update methods. My hypothesis is that it makes the most sense to make it so that trying to update something from the Qube Manager just opens up the Qubes Update tool, but I leave it up to you to decide the best UX approach.

[ninavizz]

If there is a clearly beneficial reason why the existing path from QM should remain, I would love to know it.

Off the top of my head, I could see why highly technical users may wish to run updates from a Template's terminal—but if that is the case, they should be able to invoke the download and to do it all themselves, without the GUI prompt in QM.

All methods to run updates from the GUI, should point/route through the Updater widget.

I'll propose something, here, shortly, for this specific Issue... thank you for clarifying this issue's purpose @andrewdavidwong!

[DemiMarie]

From my perspective, having the Qubes Manager offer to perform updates makes sense, but it should do the same thing as the Qubes Update tool does. Having it open the Qubes Update tool would be one way to do this.

[andrewdavidwong]

Off the top of my head, I could see why highly technical users may wish to run updates from a Template's terminal—but if that is the case, they should be able to invoke the download and to do it all themselves, without the GUI prompt in QM.

Right. As mentioned in my initial report, there are three methods in total: two GUI, one CLI. (Technically, I suppose the Qube Manager method is a hybrid, since it starts a terminal and runs commands in it for you. The problem is that it doesn't use the same underlying qubesctl command that the Qubes Update tool uses.)

I'll propose something, here, shortly, for this specific Issue... thank you for clarifying this issue's purpose @andrewdavidwong!

No problem!

[ninavizz]

Honestly, @DemiMarie's suggestion is what makes the most sense to me—and yet it's very confusing that the visual language is so different. So, something about the icons, I'll be submitting here—but the core action upon clicking, is that it should invoke that update action w/in the Updater (so, not just taking the user there and requiring they click one more thing to begin the action).

[andrewdavidwong]

Reopening due to problem described in https://github.com/QubesOS/qubes-issues/issues/8627. Here's a summary of the situation:

Expected result

Trying to update a qube from the Qube Manager opens the Qubes Update tool with that qube pre-selected. There is only one GUI update tool in the whole system, so the behavior is always consistent, regardless of whether an update GUI it is opened from the Notification Area (aka "System Tray"), Applications Menu (aka "Start Menu"), or the Qube Manager. For details, see https://github.com/QubesOS/qubes-issues/issues/6635#issue-899518404.

Actual result

Trying to update a qube from the Qube Manager still opens a GUI that behaves different from the normal Qubes Update tool. For example, with this Qube Manager update GUI, users can't select more than one qube to update, which the Qubes Update tool allows. In other words, the behavior is still different when trying to start an update from the Qube Manager compared to other locations. For details, see https://github.com/QubesOS/qubes-issues/issues/8627.

[GWeck]

Having the same user interface - i.e. the Qubes update tool - no matter how you invoke it, via the menu, from the Qube Manager for one or all qubes, surely simplifies the user experience: You are faced with a simple, powerful UX which is always the same.

Still, I am missing an important feature which was part of the old updater from the Qube manager. There, you could, before the update started, look at a list showing what is to be expected, especially how much data is to be downloaded. When working with a system on a slow connection, it may be essential to delay the update to a time when it does not block internet access for a long time when you need it right now. The decision may not be based on whether you should perform the update or not, but just on whether it is convenient do do it right now or later. Without knowing how much is to be downloaded you cannot decide this reliably.

This problem could be solved if the updater offered an option - normally turned off, or so - to show what will be done. I suppose that this information is available before executing the update, because even over salt the steps that are performed in the background will be based on dnf update or apt update, which will show it if called directly via a terminal. It would be very helpful if this could be shown optionally before starting the update process so that the user might decide to cancel it right now.

[andrewdavidwong]

@GWeck: That's off-topic here.

[marmarek]

Updating multiple templates at once from qubes manager is also supported - simply select multiple of them before clicking the update button. It will update them in parallel.