Thanks for your provided GitHub issue link.
Personally, it would be enough for me if an error is displayed and nothing happens. Then I can go to TemplateVM and fix it myself.
I want to have full control over my updates. As far as I know, this is not possible with non-interactive updates.
I don’t know if it is possible to make non-interactive more robust. If you change many source.list files of the repository, it depends on the specific change each time.
Where can I learn about the security risks of doing updates with my described “normal” Linux update method? Can you please provide me a link?
You can find an extensive discussion of this in the Forum - for example
in the thread
Recommendation against "qubes-dom0-update" - biut it
has been mentioned many times.
In brief, the salt mechanism is used to push out system configurations,
fixes etc relating to updating. If you manually update the templates you
will not have these automatically.
If you pay attention to the QSB then you can make the necessary changes
for yourself before manually updating.
Additionally, I would like to point out that using VMs becomes more fingerprintable if you do all updates at the same time (or at least 4 is the default). It should be a better option to create a script that updates one VM at a time with random (long) pauses between the next.
I don’t understand.
Are you concerned about “fingerprinting” the fact that you are using
Qubes leaks that information all the time in default configuration, in
time checks, update checks, and (most likely) usage. You can take steps
to mitigate this but this is intermediate to advanced Qubes use.
The same goes for changing the number and frequency of updates.
You can roll your own script to do this, iterating over the templates
with random sleeps between calls to
qubesctl --skip-dom0 --targets=<target_qube> ..