Restore the mechanism for overriding torified-updates-proxy-check

Development
1

Should merge requests also be tracked in this forum? Here’s one from a while ago: Honor skip-torified-updates-proxy-check qvm-service (!1) · Merge requests · Whonix / qubes-whonix · GitLab

1 Like
2

Yes.

I didn’t notice this until now. What’s the purpose of that?

3

It’s to force an update of a Whonix template through a non-Whonix qubes.UpdatesProxy VM. For example, qubes-updates-cache works better on Fedora (because Debian Buster’s Squid doesn’t support OpenSSL).

With qubes-whonix package < 15.4 it was possible to override the safety check by running e.g. qvm-service --enable whonix-ws-15 whonix-secure-proxy, but not anymore since commit 53ff72a. The merge request restores this possibility.

4

I see. The qvm-service probably shouldn’t be named whonix-secure-proxy?

  • One day, perhaps QVMM lists all the possible qvm-services that one could enable. Then whonix-secure-proxy would sound secure. And everybody wants security. Users might enable it and then be unsafe.
  • A user who already has enabled whonix-secure-proxy due to being told so in some instructions and having unrelated issues (such as networking / qubes-updates-cache) issues) might change Networking or UpdatesProxy. whonix-secure-proxy would also imply security while that’s actually for advanced users / insecure if used wrong.

Naming suggestions?

This could be used to update over clearnet. Maybe useful for some. Maybe even required in some situations if there is some severe bug or user error short of Whonix re-installation. updates-proxy-clearnet comes to mind but that would be confusing if a qubes-updates-cache would actually be torified.

No good name comes to mind. updates-passthrough perhaps? Better suggestions?

1 Like
5

Hmm how about skip-torified-updates-proxy-check?

1 Like
6

That is a bit long but OK.

1 Like
7

Done (and rebased on HEAD).

Yeah it’s kind of verbose, but OTOH it’s also just skip-<scriptname>.

1 Like