Test signing is only required for Windows 7 and only if the Qubes-supplied video driver is selected for installation. If you use Windows 10 or 11, which do not support this driver, or if you install QWT for Windows 7 without this driver, test signing is not required. The rest of QWT, including the signed Xen drivers, does not require test signing.
This situation will change only if/when a newer version of QWT using the promised new video driver is provided - which I await very much!!! - and if this version has a signed driver.
The requirement of using only signed drivers is imposed by Microsoft, and, regarding their security history, the value of such a requirement can clearly be doubted.
TLDR: I was asking why donât we just run new drivers and QWT in test-sign mode instead of waiting
No, this is not really what I mean. AFAIK, the new version exists, it is just not signed by microsoft (because the build server potentially got compromised, thus deeming any software with this signature potentially untrustworthy, and we wait for microsoft to release new certs to make new official release with a clean signature).
I wonder why old signed version is suggested instead of the new unsigned (that is still signed by xen and qubes devs, but not by microsoft (nobody asked their opinion anyway)), and require test sign mode.
It is not a requirement, just a way for users to build trust to devs that have official microsoft certs because microsoft trusts them. We, however, donât trust microsoft that much in the first place, and do trust qubes and xen devs (if not fully, than at least more than we do microsoft), thus reducing this whole arrangement to mere bureaucracy.
If I misunderstood the whole story, or wrong about some details, please correct me.
as far as I understood the issue, the server have been running with a pretty bad vulnerability, and nobody knows if the thing was compromised before it was patched, hence, the drivers can not be considered safe due to this.
I see. Using the new version would be clearly better, and I still hope that the devs will publish it, which they promised in issue #1861 some while ago. I am still waiting and looking forward, but nothing seems to have happened in the last weeks.
No. They are not signed by Xen devs. Citrix used to publish cross-signed drivers by demselves and Microsoft for free. At the moment, having access to signed ones require login and some paid subscription (maybe money is involved).
The major issue is lack of transparency. No PR is linked to 1861. It is not clear which repository and/or which branch is the current development branch for this work. Other devs can no follow. But we should consider that some of core-team members prefer to work in total isolation. Some might even have their entire Github profile hidden.
When I started this topic Aug 2023 I was not expecting that this major issue to be still in place in Oct 2024 and further. Once again, it is a regression of Qubes OS that was supporting Windows virtualization with QWT from R2 beta or something 10+ years ago. And now we have R4.2 that cannot properly run Windows with QWT.
Do we even have a guide to install Windows 10 + QWT even with some debug mode/self-signing steps for R4.2?
The QWT with potentially compromised Xen drivers still works fine in Qubes OS 4.2. Or do you mean you want a guide to install QWT with latest test-signed Xen drivers that are not compromised?
There are still open issues with QWT being used under R4.2, like #8328. So, for my application scenario, R4.2 is still not usable, and I still regard it as being in a beta state, as much as I regret this.
Thanks, was not sure if it is working or outdated.
The third guide I forgot to mention:
3. How to migrate Windows qube with QWT from R4.1 to R4.2 (pot. compromised and not).
Fixed it for you. Micro$haft manages once again to engage in expensive security theater rather than actually investing in tolerably secure code.
I do look forward to resolving this; a lot of things donât work quite right in my Windows qube. In the end, the best thing to do is minimize windows usage.