DNF torproxy

[aintaint]

The problem you're addressing (if any)

dnf updates for Fedora qubes are currently configured to implicitly use a Whonix tor gateway as a transport. An option that could be discussed is explicitly using the dnf torproxy plugin instead.

Describe the solution you'd like

I'm ambivalent currently, editing the configuration file to comment out the proxy is convenient because the default behavior is reset on reboot. It's handy to temporarily switch tunnels when one is slow or being deliberately disrupted. Exit nodes will be getting systems fingerprinted, some tor exit nodes are always going to be attack vectors.

However it's usually better to be explicit in design then to rely upon implicit behaviors. Using the torproxy plugin allows the system's default configuration to say, "use tor, or fail"

However an additional software module introduces additional points of attack and failure.

Where is the value to a user, and who might that user be?

Describe alternatives you've considered

Additional context

Relevant documentation you've consulted

https://dnf-plugins-extras.readthedocs.io/en/latest/torproxy.html

Related, non-duplicate issues

[marmarek]

The current approach is much more in the direction you prefer ("use tor, or fail") than what you propose. The TemplateVM simply have no other network access than through sys-whonix tunneling stuff over Tor. Of course if you indeed select to use Tor (via Whonix) for updating templates - this is not the default setup. The alternative you propose lives a room for dnf or other update mechanism to simply not use that torproxy plugin and connect to the network directly. And this is not just theoretical - you are probably unaware that PackageKit (used by gnome-software and some other GUI interfaces) uses libdnf directly, not dnf (I know, this is confusing...), which bypasses all the dnf plugins and the whole /etc/dnf/dnf.conf. So, in your approach it would be really easy to actually misuse it. With Qubes default approach, TemplateVM has no alternative network access - if something will try to bypass the UpdatesProxy (which is the thing that can be directed through sys-whonix), it will fail to connect. And indeed, PackageKit by ignoring dnf configuration fails (#3815).

editing the configuration file to comment out the proxy

This may work only if you additionally set direct network access to such VM (set netvm to something other than none).

Please note this all is about running package manager in TemplateVM - where the installed updates will persist. If you run it in AppVM, it will use whatever network access that AppVM has (which again, you can redirect by setting such AppVM's netvm to sys-whonix or whatever you want)

[marmarek]

Also, this sounds rather like a topic for forum/mailing list discussion than for the issue tracker. See https://www.qubes-os.org/doc/reporting-bugs/#issue-tracker-guidelines

[aintaint]

It looks like dnf needs a bunch of enhancements, honestly. If the additional transport wouldn't be picked up by the library functions, what's the point of having plugins? Is this not unix?