There is also the little matter of Windows (since 7 I think?) requiring kernel drivers to be code signed, unless you want to run your system with a permanent "Development mode" text overlay, not to mention the arcane procedure required to activate that in the first place. (You can't add another cert to the trusted set, either.)
So that puts a little damper on the whole "open source" thing. Of course it is also not effective at all, Stuxnet was famously signed by Realtek.
The process to get a driver signed doesn't seem too hard for an open source project to do. Biggest hurdle is the certificate costing around $300/year as far as I can tell, so it would need to be a project with a reliable stream of donations or an author/s willing to pay it.
Not too long ago I had to do some INF editing to get a driver installed on Win10, and the editing did invalidate the signature so it (silently!) refused to install, but booting with the "disable driver signature enforcement" option made it install, and it continued to load and work normally even after I booted back into normal mode. This was only a few months ago so unless something drastic has changed since then, maybe it's not that hard to install drivers with bad (or missing, but that's really the same if you just have an arbitrary signature) signatures. I thought I'd be out of luck and have to resort to something deeper and less reliable like kernel patching (tools exist to do that, but they get marked as malware, and you have to do it after every update...) but that was an unexpected surprising positive.
Editing the INF de-authenticates the installation of the driver, which can also be bypassed by adding to the Trusted Publisher root store, which is mutable (as Zadig/libwdi does), but the actual kernel-mode .sys binary still needs to be signed by Authenticode unless the system is in driver Developer Mode. Your method worked for installing a modified INF file, but will not work for installing a modified binary.
Sounds like my Linux experience in the late 1990s: lots of weird invocations without understanding what they do, just to keep the system barely functional. The roles sure have reversed...
As for manually forcing a particular signed binary for a specific device, the “Have disk...” or “manually select from” route still works without that developer mode nonsense.
That’s trivially easy to get around by installing you’re own CA cert when you install the driver.
This is arguably worse security wise but it makes the driver install process identical to the way it used to be as far as the average consumer can tell. This is why (IMO) free software is so important, to the point where I’ve begun to agree with the radicals and think it should be mandatory.
There are two separate authentication processes for drivers on Windows: Authenticode, which is used for the kernel-mode driver (.sys) and is strictly enforced, and driver package signing (.cat/.inf installation packages), which has a mutable root storage called Trusted Publisher system store. Zadig works by adding its own certificate root to the Trusted Publisher system store and self-signing the installation packages, but the three possible installed drivers (WinUSB, libusb0, and libusbK) were all still signed by Authenticode.
Yes, it is its own list for software publisher signing specifically, and is separate from the Trusted Root Certification Authorities certificate store.
So that puts a little damper on the whole "open source" thing. Of course it is also not effective at all, Stuxnet was famously signed by Realtek.