Use new TCP support in qrexec instead of calling socat #495
Conversation
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.2&build=2024050800-4.2&flavor=pull-requests New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.2&build=2024050210-4.2&flavor=update
Failed tests7 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/98585#dependencies 2 fixed
Unstable tests
|
marmarek
force-pushed
the
connect-tcp-direct
branch
from
bc8572a to
c98f106
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #495 +/- ##
=======================================
Coverage 69.89% 69.89%
=======================================
Files 3 3
Lines 475 475
=======================================
Hits 332 332
Misses 143 143 ☔ View full report in Codecov by Sentry. |
Enable exit-on-service-eof feature, since that is what socat did. QubesOS/qubes-issues#9037
Enable exit-on-service-eof feature, since that is what socat did. QubesOS/qubes-issues#9037
When qrexec-client-vm is called from a systemd unit connected to a socket, it the same socket on both stdin and stdout. Tell qrexec-client-vm about it, so it can use shutdown() instead of close() to properly deliver EOF. It will also make the qrexec-client-vm to use just stdin FD. QubesOS/qubes-issues#9169
StandardError defaults to "inherit", which would connect the socket from the package manager here. Do not send qrexec error messages as HTTP proxy response...
marmarek
force-pushed
the
connect-tcp-direct
branch
from
c98f106 to
7cddb88
Compare
qubes.UpdatesProxy and qubes.ConnecTCP are converted to use the built-in TCP support in qrexec. QubesOS/qubes-issues#9037
It isn't compatible anymore
|
I can see this breaking setups that use Is this feature going to be delayed to R4.3? Side note: Although |
It doesn't matter, as |
Ok, yeah. I guess third party packagers will have to keep up with this change. It is an API break though, maybe delay to R4.3? Although it is easy to handle with deb and rpm packaging targetting a certain Qrexec package version, installation via Salt will break as it is "set and forget" instead of always being updated.
That is very nice, thanks for the explanation. |
Well, if you use proper packages, it doesn't matter how you install them - installing newer qubes-core-agent will enforce installing newer qrexec too (or, if not available, installing newer qubes-core-agent will fail) - either way, you are not getting broken state you describe. If you do your own packaging, then yes, you need to take care of dependencies too, the qrexec one is not any exception here, and not even the only versioned one. The update here doesn't change cross-VM API, it's okay to use older |
|
Thank you! |
Convert qubes.UpdatesProxy and qubes.ConnectTCP services to use TCP support built into qrexec itself since QubesOS/qubes-issues#9037