added Tor SocksPort 9125 for yum:
https://github.com/Whonix/anon-gw-anonymizer-config/commit/a2aa9e90b344cb4fc01cacc73ac2007b47e3f42e

added Tor SocksPort 9125 for yum:
https://github.com/Whonix/whonix-gw-firewall/commit/d6401bb5e310504a454ee2d65b8b3d46b4dbfdb3

added stream isolation wrapper for yum:
https://github.com/Whonix/uwt/commit/e86f3497832626f16721cd0fc493fb4ba4a12ee6

added stream isolation wrapper for yumdownloader:
https://github.com/Whonix/uwt/commit/ddc9fbc6822b643ff0bbf1cac872d65a86ff8c70

I think the 4 above commits made a), qubes-prefs --set updatevm whonix-gw possible. I was able to use dom0 sudo qubes-dom0-update now. Needs more testing. yum and yumdownloader can now connect through Tor on Qubes-Whonix-Gateway without manual configuration. (Whonix-Gateway does not provide a TransPort, i.e. there is no default fallback system DNS / TCP. All applications need to be configured to use a Tor SocksPort or be forced by uwt.) [I might have run into unrelated issues. (https://github.com/marmarek/qubes-core-agent-linux/pull/25)]

For this to work, the only things requiring network access, are only yum and yumdownloader in qubes-download-dom0-updates.sh, right? @marmarek

(resending)

re: yum + yumdownloader the only network accessing tool:

Yes, but note that there are more call to them there. How that wrapper
works? Is it placed instead of /usr/bin/yum?

Ah, qubes-dom0-update calls qvm-sync-clock first, but this is
probably irrelevant here. And independent thing to rework.

In T401#6629, @marmarek wrote:

(resending)
re: yum + yumdownloader the only network accessing tool:
Yes, but note that there are more call to them there. How that wrapper
works? Is it placed instead of /usr/bin/yum?

Short answer:
No modifications of any Qubes scripts required. /usr/bin/yum gets replaced.

Longer answer:
"Like other uwt wrappers." /usr/bin/yum is a symlink to /usr/bin/yum.anondist.
(https://github.com/Whonix/uwt/blob/master/usr/bin/yum.anondist)
(using config-package-dev)
It will exec to uwtwrapper.
(https://github.com/Whonix/uwt/blob/master/usr/lib/uwtwrapper)
It determines destination ip/port, config and other relevant stuff.
Which will then exec to uwt, which will then exec to torsocks.
(uwt is required, because torsocks does not support stream isolation by ip/destination port. [upstream feature request existing])

Ah, qubes-dom0-update calls qvm-sync-clock first, but this is
probably irrelevant here. And independent thing to rework.

Yes. This doesn't interfere here, because T384 was implemented. T397 remains TODO, but is an issue on a different level.

I thought, why not just add 2>/dev/null. That hides it. Created a pull request...
https://github.com/marmarek/qubes-core-admin-linux/pull/1
What do you think?

I think it isn't the best option - indeed such warning are not really
useful, but that would hide also errors (for example "No space left on
device"), so would be harder to find out what failed.

Also, this is exactly why there is qvm-sync-clock call.

Maybe there is a way to filter out just those messages? I can't find an
option for that. Some grep (and make sure LC_MESSAGES=C)?

Agreed.

Here is a proof of concept filtering this out using grep. (Missing LC_MESSAGES=C.)
https://github.com/marmarek/qubes-core-admin-linux/pull/2

But using grep increases dom0 attack surface or are there already other cases where dom0 grep processes VM data so this does not matter?

If so, I could try write a tar wrapper that runs within the VM that filters out that message.

New pull request:
https://github.com/marmarek/qubes-core-admin-linux/pull/3