After more thought, I now heavily doubt that purchasing a code-signing cert is worth it. It appears, Windows has no real protection from tampering by default, only a domain administrator may configure something. A brand new installation of e.g. Home edition allows any program to install a self-signed certificate into the system trust store without questions (for instance, using the built-in certutil.exe prog), so I don't really get what's the idea behind the restriction on signing driver packages...
Moreover, we could have a tool that does approximately (np, I can really write it if necessary, all just to save the user from a reboot): 😀
- creates a temporary self-signed certificate in volatile memory;
- signs the driver catalog file;
- installs the certificate to the system store (easily done, since the driver installer already implies administrator permissions);
- installs the driver (being in fact signed but untrusted) silently;
- remove the helper certificate from the store and happily finish.
So, I'd avoid throwing away a couple of hundred $ just to have an illusion of protection. Because I personally have nfi who are those people signing certificates at all; how could I trust them if they trust in $ only as it seems? Atm, I 100% agree with the point of Dennis Zimmer about the existing digital certification approaches, so if it comes to code security for the project (by popular demand), I see exactly CodeNotary as a clear winner.
But back to the matter at hand, I hope a chance will come and M$ will hear our demand to stop this hassle and offer a saner API for software synths, so a developer doesn't have to jump through the hoops to make his synth merely accessible to other applications.
P.S. Interesting to note, that the new tool infinstall I've recently added (in order to install the driver "properly", yeah) sometimes fails to register the legacy MIDI driver entry(!), meaning that drvsetup remains the most reliable and the least annoying way of installing the MIDI driver for the user.