Implement UUID support in qrexec

[DemiMarie]

Open questions:

• How should dom0 be informed of the intended call target? Should it be SERVICE-NAME REMOTE-DOMAIN-NAME uuid UUID-OF-TARGET or SERVICE-NAME REMOTE-DOMAIN-NAME name @uuid:UUID-OF-TARGET?
• Should the target be informed of the source VM’s UUID? This allows race-free “boomerang” calls, but requires an API change.
• Probably more
  Fixes: Consider UUID syntax in qrexec policy qubes-issues#8510

[DemiMarie]

PipelineRetryFailed

[DemiMarie]

PipelineRetryFailed

[marmarek]

* [ ]  Should the target be informed of the source VM’s UUID?  This allows race-free “boomerang” calls, but requires an API change.

Definitely not instead of the name, as most(?) services needs actually the source name (things like subdir in QubesIncoming, or split-gpg prompt). As for extra data, its usefulness would also be limited (generally, the source qube is running during the connection, and the name cannot be changed while qube is running). And adding extra info to the protocol would be an API change anyway so needs to wait for R4.3.

[DemiMarie]

This version is quite a bit simpler than I thought, but it has no fallback to the name if the UUID symlink is not present, and doesn’t set up the UUID symlink itself. Therefore, it does not work.

Would it be possible to use an environment variable @marmarek? That could help avoid circular dependencies during upgrade. Of course, an alternative is to use snapshots to make the entire upgrade atomic, which is probably a better solution as so many things can fail.

[marmarek]

Forcing updating core-admin and core-qrexec at the same time via dependency is okay. There is no need to handle new qubesd starting old qrexec-daemon. Since it isn't necessary, I'd prefer to simply use a command line parameter for UUID, which is much cleaner than giving name via cmdline and UUID via environment.
And also, it's qrexec-daemon who should maintain the UUID symlink, since it maintain the other symlink already (again - consistency).
What might be useful (mostly for testing, as actual release upgrade needs reboot anyway) is to keep working with already running old qrexec-daemon - which basically means a fallback to name-based symlink.

[ben-grande]

Please add a test with uppercase letters that don't raise a syntax error. RFC 4122 allows case insensitive characters on input:

Each field is treated as an integer and has its value printed as a
zero-filled hexadecimal digit string with the most significant
digit first. The hexadecimal values "a" through "f" are output as
lower case characters and are case insensitive on input.

Meaning it is syntactically correct for the user or program to write the uuid value using uppercase letters, but the Qrexec parser should evaluate them with case insensitivity and always output it in lower case.

[codecov]

Codecov Report

Attention: Patch coverage is 63.27684% with 65 lines in your changes are missing coverage. Please review.

Project coverage is 77.51%. Comparing base (adbf4a2) to head (9e3790a).

Files	Patch %	Lines
daemon/qrexec-daemon.c	69.64%	17 Missing ⚠️
libqrexec/ioall.c	0.00%	15 Missing ⚠️
daemon/qrexec-daemon-common.c	31.57%	13 Missing ⚠️
qrexec/policy/parser.py	62.96%	10 Missing ⚠️
qrexec/utils.py	10.00%	9 Missing ⚠️
qrexec/tools/qrexec_policy_exec.py	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #135      +/-   ##
==========================================
- Coverage   77.75%   77.51%   -0.25%     
==========================================
  Files          54       54              
  Lines        9498     9601     +103     
==========================================
+ Hits         7385     7442      +57     
- Misses       2113     2159      +46     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.