Wow, I missed out on some fun discussions. Let me clarify how this works, and what Armory has done (and failed to do).
- You can use openSSL to generate your own SSL certificate (offline if you want), and send just the [effective] public key to the CA for signing. In this way, the private part of your certificate can be protected in exactly the same way as we do GPG.
- The certificate provider/signer will verify your identity before they sign any certificate claiming "Joe's Fish Shop" is the provider of this software.
- A single compromised CA cert could be used to impersonate just about anything. Your system trusts any number of probably 100 certificate roots, and a signature from any one of them pretty much gives the green light, unless you are manually inspecting the certificate chain and know that certain certs are lower security and/or compromised. It's the job of the OS and the browsers to track which CAs are still trustworthy and help update your CA lists to make sure that any compromised providers are no longer trusted.
- The MS/authenticode system is not good for verifying specific certificates. Ideally, for high-security apps, the publisher would publish their public cert and everyone would verify that the signatures from that cert, though it's a bit of work to do this. Instead, they just check whether there's any valid certificate chain and shows you "Yes/No" that the signature is valid.
- For this reason, I don't care much for Authenticode-signed certs. They avoid the unsightly "Unknown Publisher" when you go to run the installer, but that can be a false sense of security.
- I stand by the notion that the GPG signatures are the most secure. Our offline GPG fingerprint is everywhere, and it's simple to check via command-line. It's also easy to integrate into our release scripts.
Here's what Armory has done to this point:
- I have a Class 2 object code signing certificate, signed by StartCom. Though at this point it might be expired. However, it is in my name ("Alan Reiner")
- Getting a cert associated with the company requires quite a bit of ID verification work, including supplying tax returns. We haven't been keen to do this, though I suspect we will at some point. This would be needed for it to show "Armory Technologies, Inc." on the "Verified Publisher:" line.
- Before version 0.90, Armory used my personally-verified cert. I generated it on an offline windows machine, and integrated an three extra steps into my release process to make sure the windows installers made it to that machine for authenticode signing before going to the offline Linux box for GPG signing. This is quite a pain ... you can't sign afterwords or else the GPG hashes/sigs break.
- There is technically a way to do this in linux, but it didn't work with the type of .exe I was signing. I was left with no choice but to use a dedicated offline Windows box
.
- Before version 0.90, I did go through with all this. You should be able to run the 0.88 installers and see my name as the verified publisher
- Since version 0.90, we have been using NSIS to package up our installers. The signing process that I previously used no longer works. I believe it has to do with the chained installer architecture: the outer shell of the installer is signed, but it's only purpose is to unpack the real installer and run it... which is not (easily) signed. This means that if you take the .exe posted on the website (if it were signed this way), you could view its properties in Windows and see the signature is there. But when you run it, you still see "Unknown Publisher."
With all this in mind, I hope you'll forgive me that I wasn't excited about going through a lot of work, to provide what I felt was less security than the GPG sig, and complicates the heck out of my signing&release process. Is it useless? Not exactly. But I'm comfortable with the idea that the user either checks the GPG sig and knows it's good, or they don't and know it's not verified.
However, it
is possible that the new installer format works with linux authenticode tools, so that it
could be easily integrated into the release process. If anyone wants to try that out for us and provide a recipe for doing it, I will take a shot at it. But I'm not anxious to put a lot effort into what is already a complex and inconvenient process (low convenience but high security!).
