Page 1 of 1

No more code-signing options

Posted: 2017-12-26, 23:37
by Moonchild
It is with great disappointment that I have to announce this, but our code-signing of Windows binaries will come to an end in January 2018.

For a number of years we have supplied Pale Moon with digital signatures attached to the executables themselves on Windows (Authenticode signing), which allowed users to verify that the installer or updater was actually officially supplied by me and unaltered, which would also show in the UAC (User Account Control) prompt when performing administrative tasks (with the exception of setup.exe which due to technical limitations was never signed in the packaging process).
We've been able to do this thanks to the flexible service offered by StartSSL who have reliably issued certificates for this purpose after Identity Verification of me as an individual (Class 2 IV).
Because of the relentless pursuit by mainstream browser vendors after their newly-acquiring parent company WoSign caused them to become distrusted on all platforms, despite immediately taking action to separate from WoSign and starting a re-validation process as a trusted CA, StartCOM and StartSSL have now been forced into foreclosure with no ability to extend or issue new certificates for code signing. They will effectively terminate as a CA because of continued resistance to get themselves re-authorized after a lengthy verification process.

This means that a different code-signing certificate vendor was looked for. Unfortunately, the list of available options for individual developers is extremely short, as code-signing certificates are only issued by the mainstream Certificate Authorities to registered organizations which have gone through either an Organization Validation (OV) process or Extended Validation (EV) process, neither of which are available to individual developers (and are very expensive due to the insurance backing that comes with such certificates). IV is only available as a rare exception and requires notarized documents of a nature I cannot provide, as I found out when attempting to get a certificate from Comodo.

This brought me to the only available option left for me as an Open Source developer: Certum (by Asseco Data Systems SA). This is a CA based in Poland offering a special class for Open Source developers with a simplified validation process similar to what StartSSL required. I've gone through this process with them, getting a cryptographic card for 2-factor code signing (the only option they offer) and a certificate issued to me as an Open Source Developer by them (at substantial cost to purchase the hardware and certificate), to find out after a number of headaches and lots of trial and error that their card reader/driver/management software only allows code-signing using SHA-1 signatures. SHA-1 is not an acceptable digest algorithm for signing, since it is not strong enough to prevent tampering and cannot sufficiently guarantee the authenticity of the file. As such, modern versions of windows require SHA-2 based signatures (SHA-256). As far as I can tell, their driver/software and/or card reader simply do not support SHA-256, which makes their code-signing certificates completely useless for any developer.
I tried contacting Certum about this, but after their previous assistance getting the certificate issued which required some back-and-forth with their helpdesk, they simply ignored my attempts at contacting them with this issue. I tried contacting them 3 times over the last month with 0 response, and can only conclude at this point that they are aware of the issue and do not wish to provide assistance or updates or any sort of solution or compensation for selling me a pig in a poke (a "cat in a bag"). I'm therefore also extending a warning to any Open Source developer out there looking for code-signing to not consider Certum to be a CA they can trust to deliver usable code-signing certificates.

Having crossed the one viable CA for code-signing left off the list, this leaves me with one option: We will no longer code-sign our windows executables with an authenticode certificate.

To be able to verify the authenticity and integrity of our binaries, we will continue to provide both secure hashes for downloads (SHA256 checksums) and PGP/GnuPG cryptographic signatures (.sig) for all binaries (both Windows and Linux). Windows and some antivirus packages may complain about software not being authenticode signed any longer, but there is simply no option left for us to make this happen at this time; and not for lack of trying.

I hope this announcement has sufficiently clarified the situation.

Re: No more code-signing

Posted: 2017-12-28, 23:24
by Moonchild
As an update to the previous announcement: code-signing might be technically possible after all using Certum's code-signing certificate and crypto card, but it's a PITA and the workaround to get it to behave is not something discoverable even for tech-minded developers (in short: it requires undocumented hackery). As such my recommendation remains against it, unless operating systems are going to hard-require everything to be signed, and because of the still-broken system that is cumbersome to deal with I won't be code-signing the windows binaries in 2018 unless I am forced to do so by Microsoft.

In more detail

Certum's helpdesk finally got back to me after Christmas, potentially nudged by my announcement here, and provided an essential setting in their software options that needed to be changed. It was counter-intuitively called "EV signing", which completely changes the way their card reader talks to the system and which I wasn't able to make work at all previously because of "no driver found" issues when plugging in the USB reader (see below), which made me opt for what is normal for card reader signing: using the crypto service provider (CSP) in Windows, which worked fine and as-expected, but only for SHA1. Certums "card manager" software also seems specifically designed for SHA1 and nothing else (meaning it's woefully outdated and obsolete).

After 2 days of tinkering I've found out a workaround (a dirty hack, really) for their broken signing system, allowing SHA256 to be used as signature algorithm.
Now, to get to that point involved manually downloading a driver package from the card reader manufacturer directly, instead of what Certum provided, and carefully massaging the Windows Device manager (and manually selecting a driver for the smart card that's in the reader) and a lot of trial and error to finally get a fragile driver and software combo set up to make SHA256 signing possible. So, what they sold me is technically capable of signing with SHA256, but not in any way close to what their documentation provides, not in a discoverable way, and not for anyone who doesn't know exactly how the device manager handles driver installation and selection. I also have no idea if the same trick works on other versions of Windows than what I use on my workstation. Because of the pain it is to use this way, it's not something that can be easily integrated in our release engineering at this time either, hence my decision to stop signing unless absolutely forced to do so by the O.S. vendor.