opened 03:54PM - 05 May 26 UTC
cryptography
P: default
diagnosed
C: updates
affects-4.3
C: firmware
### Qubes OS release
Qubes OS 4.3
### Brief summary
The jcat file published a…t https://cdn.fwupd.org/downloads/firmware.xml.zst.jcat no longer contains a PGP signature (firmware.xml.zst.asc). `qubes-fwupdmgr refresh` requires this signature (maybe because it was the signature that could be verified with the lowest attack surface?), so it refuses to refresh.
Broader lesson: qubes-fwupd is making a bunch of assumptions about LVFS internals that have proven fragile (#10315, #10544, and now this). Is there anything we can/should do to make qubes-fwupd more maintainable long-term? Maybe ask the LVFS project to test their changes on Qubes OS before deploying to the production service so we have a chance to react and discuss solutions before ordinary Qubes OS users are broken? Is there any hope LVFS would agree to that, or are we just not important to them? I'm not familiar with the background here, and any inter-project negotiation is probably way beyond what I'd be willing or able to take on myself at this time, but I thought I'd bring it up in case someone else is willing and able.
### Steps to reproduce
1. Run `qubes-fwupdmgr refresh` in dom0.
### Expected behavior
Successful refresh.
### Actual behavior
Error:
```
[root@dom0 ~]# qubes-fwupdmgr refresh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 15055 100 15055 0 0 102k 0 --:--:-- --:--:-- --:--:-- 102k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1806k 100 1806k 0 0 1090k 0 0:00:01 0:00:01 --:--:-- 1090k
Validating directories
cat: /home/user/.cache/fwupd/metadata/firmware.xml.zst.asc: No such file or directory
Failed to refresh remote 'lvfs': qvm-run: Copying metadata signature failed!!
```
### Additional information
A [forum thread](https://forum.qubes-os.org/t/qubes-fwupdmgr-error/40889/2) reporting the same problem.
Regarding a possible fix: The only signatures left in the jcat file are two p7b (PKCS7) signatures. (Apparently one is post-quantum and the other isn't.) Assuming the requirement of Qubes OS's security model is to verify one of these signatures with low attack surface before passing the data on to fwupd in dom0, we would have to find a tool to do that. Alternatively, we could try to convince LVFS to start publishing a PGP signature again. (In a quick web search, I wasn't able to find an announcement or rationale for the decision.)
Regarding the settings needed for signature verification if a suitable tool were found: Currently, the non-post-quantum p7b file comes later in the jcat file and consequently "wins" during extraction (see #10315), and it appears to be signed with `/etc/pki/fwupd-metadata/LVFS-CA.pem`. I confirmed that by running the following command in `/home/user/.cache/fwupd/metadata` in the UpdateVM after the failed `qubes-fwupdmgr refresh`:
```
openssl cms -verify -inform PEM -in firmware.xml.zst.p7b -content firmware.xml.zst -binary -CAfile /etc/pki/fwupd-metadata/LVFS-CA.pem -no-CApath -no-CAstore -purpose codesign -out firmware.xml.zst.p7b.out
```
(If it became unpredictable which p7b file "wins" during extraction, then we could just attempt to verify the file we get against both CAs.)
I haven't tried it, but if the above command were dropped into [fwupd_receive_updates.py](https://github.com/mattmccutchen/fwupd/blob/qubes-fixes-20260112/contrib/qubes/src/fwupd_receive_updates.py) in place of the PGP verification, I presume the refresh would succeed but it would not meet the security standards of Qubes OS (and indeed may not be much better than passing the jcat file through without sanitization). I guess it's up to users to decide what to do as long as this issue remains unfixed depending on their own threat models: go without firmware updates, modify qubes-fwupd locally as I described, or boot into another Linux distribution to run fwupd.