vmupdate: apply whonix settings when downloading dom0 updates - #221
Conversation
2e5fafa to
db50c7d
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #221 +/- ##
=======================================
Coverage 71.42% 71.42%
=======================================
Files 12 12
Lines 1344 1344
=======================================
Hits 960 960
Misses 384 384 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@adrelanos @ArrayBolt3 take a look at this (and the linked issue). This PR basically duplicates https://github.com/Whonix/uwt/blob/master/usr/bin/dnf-3.anondist wrapper. I'm not a big fan of it (layering violation), but also I don't have much better idea. For the proxy config part, I guess Whonix could drop some config snippet in addition to / instead of --setopt in the wrapper; but that doesn't help with the "wait for tor start" part... |
|
Unless there's some way to hook into DNF's API with something that runs arbitrary code before any action that does network access, I don't think there probably is a better way. If I remember correctly, I think there was some specific reason we used I don't see anything wrong with the implementation. The only thing that initially seemed worrying is that a non-CSPRNG is being used to create the password, but I really doubt that's needed here, all that matters is that the password is unique compared to previous runs and even a simple counter could pull that off. So IMO this looks good. |
Whonix Gateway adds a wrapper for /usr/bin/dnf, which adds proxy-related options. This works fine as long as it's called as a standalone process, but when qubes-vm-update calls DNF via Python API, the wrapper is not used, and the options are not set. This way even generic uwtwrapper is not used, which makes DNF attept connections directly (without any proxy), which is (intentionally) blocked. Fix this by adding the dnf's uwt wrapper logic into vmupdate code, when it's using API. This basically covers two parts: - waiting for Tor daemon to be running - configuring dnf to use Tor as a proxy Fixes QubesOS/qubes-issues#11034
db50c7d to
90059d9
Compare
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026082421-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests7 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 31 fixed
Unstable testsDetails
Performance TestsPerformance degradation:16 performance degradations
Remaining performance tests:95 tests
|
Hm, I don't remember either. But it might be something about the dom0 update script forcing alternative config (copied from dom0) instead of using the default one.
Actually, there might be. We use DNF plugins for notifying dom0 about template update status on Fedora, something like this could be used here maybe? And with all that, given the config path case above, it would still need pointing at some specific plugins directory (or simply ensuring it would load plugins from default directory, instead of the alternative one). Honestly, after looking at this, maybe the extra complexity isn't worth it and the current PR isn't that bad... |
4 participants
Whonix Gateway adds a wrapper for /usr/bin/dnf, which adds proxy-related
options. This works fine as long as it's called as a standalone process,
but when qubes-vm-update calls DNF via Python API, the wrapper is
not used, and the options are not set. This way even generic uwtwrapper
is not used, which makes DNF attept connections directly (without any
proxy), which is (intentionally) blocked.
Fix this by adding the dnf's uwt wrapper logic into vmupdate code,
when it's using API. This basically covers two parts:
Fixes QubesOS/qubes-issues#11034