Use Qubes GUI Updater for Better Troubleshooting

[deeplow]

Description

Currently updates are done through the SecureDrop launcher started on-boot. However, if something goes wrong in the update process, the user has to dig through logs to find what failed and try again.

How will this impact SecureDrop/SecureDrop Workstation users?

• less time spent digging into logs to understand what failed

How would this affect the SecureDrop Workstation threat model?

It shouldn't affect it.

User Stories

As a journalist, I want to have a visual understand of update failures so that I know how to act. For example, if it's a whonix failure, I know that I should just try again. If something non-whonix failed even after a retry, I should contact the workstation admin.

[deeplow]

All outstanding issues which blocked us from using the Qubes GUI updater in the 1.0.0 version of the workstation will be unblocked by https://github.com/QubesOS/qubes-desktop-linux-manager/pull/199. That PR implements a non-interactive mode, where we can fully control the updater properties we desire.

In particular we'd want something like this:

`qubes-updater-gui`:
  --target <SD_WORKSTATION_TEMPLATES> 
  --non-interactive  # don't require interaction from the user
  --apply-to-all  # force restarts of app qubes 

[rocodes]

That's... really great news @deeplow :) :) Thank you for nudging this along. I think this should be one of the things we look into as soon as 4.2 compat is released.

[deeplow]

According to my past self, these were the blockers for using the GUI updater:

Some updates on the GUI Updater upstream bug reports:

• GUI CLI integration "--restart" does not force restarts #9032

  • Turns out in my original report of the error was inaccurate so removed that part. I changed it slightly to stress more fact that for the GUI updater to work for us we need that the user cannot skip restarting qubes when --restart is a CLI parameter (ideally with no interaction).

• GUI CLI integration missing non-zero exit codes #9225

  • This is now its standalone issue (I originally had reported it coupled with the above issue, but they're clearly separate).
  • I have added some extra detail that situations where the user exits early should also yield non-zero exit codes (think: --restart forced but user bailed on restarting qubes).

From what I can see, they are both resolved. So we can green-light this. The only thing that we need to consider is any potential UX edge-cases of the the integration of both products. But if there are any, we'll probably only encounter them when testing.