qubes-dom0-update opening terminal window of UpdateVM confuses some users

[blockisec]

How to file a helpful issue

Qubes OS release

4.1 (current-testing)

Brief summary

If i run qubes-dom0-update a terminal window gets opened of the update vm.
I tested different vms (e.g. sys-firewall, sys-net, sys-whonix, ..)

Steps to reproduce

Open Terminal in dom0 and run qubes-dom0-update.

Expected behavior

Don't open other windows like it was in previous releases.

Actual behavior

A new terminal windows gets opened of the update vm (sys-net in the screenshot).

[andrewdavidwong]

@blockomat2100, does the update actually succeed? What happens next?

[blockisec]

Yes the updates always run successfully.
The output gets copied to dom0 terminal (at least for the default updates process) and the terminal of the update vm closes itself (If I remember correctly). I get asked to confirm the update process by pressing "y" like normal from within the dom0 terminal

If I search using action=search the output stays at the update vm terminal (and gets lost) if I press Enter as the update vm terminal says.

[ghost]

AFAIK this is security feature in 4.1
I seem to remember it as a duplicate, but couldn't find one.
cc @DemiMarie

[DemiMarie]

@ivpn786 is correct ― this is a security feature added in R4.1, to prevent untrusted data (the output from the UpdateVM) being displayed in a dom0 terminal. That said, that this is confusing users indicates that the UX isn’t sufficiently clear. @ninavizz suggestions?

[SaswatPadhi]

this is a security feature added in R4.1, to prevent untrusted data (the output from the UpdateVM) being displayed in a dom0 terminal

Can this be completely silenced (by default)? So basically no output from from UpdateVM would be displayed, but dom0 would only display the list of validated packages that are going to modified

[marmarek]

There is an qubes-dom0-update --console option to avoid the terminal window. As for not having that window by default, I'm not sure if that is a good idea - it would mean no info about the download progress, which may be quite frustrating...

[ninavizz]

As a quick fix, I would recommend a Notification (the black bubble style with just text in it) telling the user that updates for dom0 are run through (whichever qube is set as the update vm), and that both it and its Terminal will be opening to manage that task.

Text I'd recommend for that bubble, for a user whose update proxy qube is set to be sys-net, is as follows:

Updating dom0 Through sys-net

All updates for dom0 are set to run through sys-net.

sys-net is opening a terminal window to run those updates. Upon completion all logs will be copied over to dom0. Any mid-process commands you may need to respond to, will be presented in your dom0 terminal window.

Users like it that Qubes gives us TMI at all times, through the notifications system. I'm hypothesizing that just letting folks know what is going on, that way, will suffice for now.

1. Keep it short
2. Just tell the user what they need to know, prioritizing plain language
3. Name all VMs; don't name the role of the VMs (name the update vm, don't just speak to it as the update vm presuming the user remembers that setting)
4. The more text that is shown, the more likely the user is to miss important things. Especially since we cannot do line-spacing in the Notifications bubble widget. Gawd I wish we could increase the Notifications' line-spacing!
5. Even the first line in my above proposed text, may be too much. The second and third sentences in the second paragraph, feel most important—along with the header text.

---

Longer-term, I feel all of this is part of the broader "Update Experience" that needs to be re-thought; with resulting outputs, being an improved updater UI, an improved updater Tray icon and UI, and improvements to how qubes in need of updates are shown in the qube manager.

[andrewdavidwong]

Bear in mind that the problem reported in this issue arises only when the user manually enters the qubes-dom0-update command in a dom0 terminal, which is not the recommended way to update Qubes OS. Most users should not be doing or experiencing this as part of their routine update practice. They should be using the Qubes Update tool instead, which AFAIK does not exhibit this problem of popping up an unexpected terminal window in 4.1.

Related: #6635

[ninavizz]

Yes @andrewdavidwong TY for the "ahem, we are a resource constrained project" tip of the hat. :)

Per the above, my inclination is to consider this issue solve'able by simply updating the docs to manage user expectations that in fact, this will happen—that logs are saved back to the qube being updated—and the user's system is not compromised when this activity happens. I expect CLI users to be more attentive to the docs, than GUI dependent users—so would rather go that route to solve for this, than something that would require a developer's time.

I began composing something in a PR, and stopped when I realized it was either incorrect, or just poor grammar (or both). So, it would at a minimum be easier if folks iterated, here, and then I can file a PR later—or someone else here can file a PR.

On the page https://www.qubes-os.org/doc/how-to-update/

Above the "In addition, advanced user..." line* and below the Salt formulae, insert:

When updates are performed from the command line, a terminal will be automatically opened in your update vm (the qube that proxies your updates, or the qube you are seeking to update if you have no proxies setup). The log from that terminal will be saved back to the VM that was updated.

* I'd also recommend adding an "s" to "users"

Do y'all feel this process simply being more transparently addressed in the docs, would make a sought product fix a "non-issue"?

@blockomat2100 had you consulted the docs before invoking this update (asking as a user researcher, so no judgement!)? It would honestly be helpful to know that, before recommending a solution. If this is new behavior and you've been doing your updates this way all along and suddenly things happened differently, that feels like a different approach would be needed.

[blockisec]

@ninavizz No I did not consult the documentation for a while. It makes sense that opening the terminal window is a security feature, I just did not recognize it as one ;). So even if I did not look at the documentation, a short hint in the docs would maybe help other users.

If this is new behavior and you've been doing your updates this way all along and suddenly things happened differently, that feels like a different approach would be needed.

I use 4.1 for a longer time now (a year or so) and it was there from the beginning, if I remember correctly, so it is nothing new. I had always done the updates for dom0 this way in previous releases.

[unman]

On Mon, Sep 06, 2021 at 11:51:05PM -0700, blockomat2100 wrote: @ninavizz No I did not consult the documentation for a while. It makes sense that opening the terminal window is a security feature, I just did not recognize it as one ;). So even if I did not look at the documentation, a short hint in the docs would maybe help other users. > If this is new behavior and you've been doing your updates this way all along and suddenly things happened differently, that feels like a different approach would be needed. I use 4.1 for a longer time now (a year or so) and it was there from the beginning, if I remember correctly, so it is nothing new. I had always done the updates for dom0 this way in previous releases.

Bear in mind that 4.1 is wip, and documentation is also wip. You cant expect a beta release to be fully documented. There are some use cases where a manual call is useful, particularly with the `--action=` parameter. Output in a terminal window is fine there, except that it isn't easy to parse/control the output.

[ninavizz]

@blockomat2100 per @unman's mention, my question was pure inquiry—to predict the likelihood of a note in the docs as an adequate solution to close this. Zero admonishment intended! :)

I'll go ahead and open a PR, following Marta's "Eh, eff-it" advisement to just purge my existing forks of the docs and make a new one. :D

[ninavizz]

PR per above: QubesOS/qubes-doc#1193

[github-actions]

This issue is being closed because:

• This issue is believed to affect only Qubes OS 4.1 (and possibly earlier).
• Qubes OS 4.1 has reached end-of-life (EOL).

If anyone believes that this issue should be reopened, please leave a comment saying so.
(For example, if a bug still affects Qubes OS 4.2, then the comment "Affects 4.2" will suffice.)