Code Signing Woes
Dirk Lemstra (via Hacker News, tweet):
Today [ImageMagick’s Windows] code signing certificate will expire. For many years LeaderSSL sponsored us with a code singing certificate but they are no longer able to do so. Since June of 2023 the CA/B Forum requires that OV code signing private keys be stored on a FIPS 140-2 Level 2 or Common Criteria Level EAL4+ certified device. This means we are no longer able to export our code signing certificate with its private key and use this in GitHub actions. We would now either need to have our own GitHub agent and hardware token or use a cloud solution (e.g. digicert). Our preference would be to use a cloud solution that integrates with GitHub. Digicert seems to be our only option now but a certificate there would cost $629 (tax excluded) for a single year.
Windows code signing has one big problem: it’s too expensive 🫰 and difficult to deal with for most open source projects, where it’s often coming out of someone’s personal money, not from a business that can well afford it
TIL that Code Signing policies had changed for the worst. Signing is now more expensive, requires a physical device and no longer can be a automated step on build agents such as GitHub Actions. 😵💫
Code signing now requires the private key to be stored in an HSM, but you can use Azure Key Vault for that, after which you can switch to AzureSignTool or one of the many alternatives that can call Azure Key Vault during the signing operations.
It sounds like code signing on Windows is even worse than on the Mac. We “only” have to pay $99/year, but then some percentage of our customers are scared away by spurious “‘App’ is damaged and can’t be opened. You should move it to the Trash.” errors.
Previously:
8 Comments RSS · Twitter · Mastodon
Ouch. This is a pretty big deal for open-source/freeware projects like mine, even at Apple's rate. For what I get, $99 is way more than I am willing to spend annually, given that I already use "free" time maintaining TeX Live Utility, and recent maintenance has mainly been working around Apple's capriciousness and incompetence (like removing Python from the OS, or changing the bizarre code signing/notarization process). It doesn't help that I think code and notarization are a waste of my time, and security theater that makes people more likely to download shady stuff because they think the OS will protect them.
An indie developer once told me that I had a bad attitude and if I really cared about quality and the users, I'd spend $99 annually. Personally, I think the opposite is true, but the TeX Users Group is paying the fee for now, since my program is distributed with MacTeX.
@Adam: It cannot be anything other than security theater since no one from Apple does a thorough code review. It's a social mechanism to replace a technical mechanism. You could say "safety violations will be punished" or you could put seatbelts in airplanes. Here the idea is that people are so terrified of losing their livelihoods that they will police themselves. It's pretty lame, since employees with grudges, ex-employees, or hackers like the NSA, could add code to million line projects in ways most people would not notice. But never mind logic, if you don't agree with Apple spun illusions, your attitude is bad... My suggestion: ignore ignorant indie developers who behave like fanboys.
The social mechanism doesn’t even fully work. I make the payment and go through the hassle of notarization, and I still get Apple support people telling my customers that my app is the reason someone hacked their Mac’s login password or the reason that Mail is buggy even after uninstalling my app. The latest one is that Apple is suspicious of my app because Apple doesn’t “have any contact information for my business.” The customer should be wary when downloading an app because there’s no way to know who’s behind it. Of course, the app is signed. And Apple has my address, phone number, driver’s license, tax ID, DUNS number, etc. Even if you jump through all the hoops they still blame third-party apps.
@Old Unix Geek:
Of course you're correct... but that's an idealized world. The reality is that the code signing Apple does probably at least eliminates some of the low-hanging, low effort riff raff. No, it's not stopping sophisticated attackers. But it's better than nothing. But it is way too much of a hassle for developers in its current incarnation.
Windows code signing is a bit of a mess at present. There are three routes:
If you're a small shop and willing to sign by hand using a USB token, that works.
The cloud-based services are rather expensive.
If you're a large operation, the easy way is to buy a turnkey signing appliance (or more than one, if you operate 24/7). If you do a lot of signing, this rapidly becomes cheaper than a cloud service.
The issue that Microsoft and the certificate authorities try to ignore is testing. Applying a Windows Authenticode signature alters a binary. So, obviously, you should sign anything that you might ship before you test it. That means you need automated signing as part of your build system, which is not compatible with keeping a USB token in a safe to prevent it being lost or stolen. When certificates could be had as files, it was easy to set up automation, but that's not secure.
I got to ask the Microsoft signing team about this, and they said "Oh, everyone signs after testing. Nobody has any trouble with that." I asked if they'd take liability for their signing tool corrupting binaries, and they backed away fast enough to have a visible redshift. My employer ended up buying signing appliances.
…say what you will about notarization, but at least you _can_ make it part of a CI (albeit slowly) without hardware contraptions.
>I asked if they'd take liability for their signing tool corrupting binaries
That seems like a stretch to me. The signing tool fills a metadata field with a pointer to the signature, then appends the signature at the end. Surely that's been battle-tested at this point. (If anything, my critique would be that, like so many Microsoft things, they haven't iterated on the tool in like two decades.)
@Sören Well, I did run into a months long Mac App Store fiasco where it turned out that Apple’s re-signing of my binary was breaking it.
> It sounds like code signing on Windows is even worse than on the Mac.
It's a mixed bag. The toolchain isn't great, and the Smart Screen behavior is intransparent. (Smart Screen is a mechanism introduced in Windows 8 where, even if your app is signed — but not EV-signed — , users will see a scary and deliberately confusing dialog, _unless_ either your app has gained enough reputation that it's fine, _or_ you have bought an EV cert. This hurts apps that either never will have a lot of users, or don't _yet_ have a lot of users.)
One advantage, in theory, is that you don't have to buy the cert from a single vendor (unlike with Apple). In practice, this doesn't really buy you anything. Effectively, we buy both a regular cert (for apps which have enough users that the Smart Screen reputation thing isn't an issue), and an EV cert (for apps where user count may be low, and the OOBE matters a lot), because the latter — which in our case is USB stick-based — is annoying to deal with.
On the Apple side of things, automatic signing has improved matters a ton, but I still wouldn't call it great. Migrating certificates to a new Mac is too much effort. They have figured this out on the consumer side where keeping keys in sync is basically seamless between multiple Apple devices, but their developer story still requires manual exporting and reimporting.
Oh, and then there's the joy — no matter whether Apple, Windows, or the Web — of dealing with the various arcane, bizarre certificate forms like pfx, p12, pem, whathaveyou, with obscure `openssl` commands to convert between them. Let's Encrypt has at least improved this for _many_ web sites, but in some of our cases, it's not an option or too cumbersome to deal with: sites that don't have a public endpoint, and/or sites that need a wildcard.