os-vendor code signing

[Gankra]

Some platforms/app-stores complain if you run unsigned code, and want you to do some fiddly junk with them (...potentially giving them money to be part of their developer program).

This could be relevant to:

• apple platforms (mac app store, ios app store, "Gatekeeper")
• microsoft platforms (windows app store, "SmartScreen")
• android?

Not sure if this is in scope for dist or a different tool altogether, but I sure think about it a lot.

[cr1901]

Eventually I would like to "just use cargo dist" to automate the CI I have for non-embedded Rust stuff. In practice, with my semi-handwritten CI scripts, I've had code-signing problems on Windows (but interestingly, not on Mac- unless the person who tested for me just didn't mention it).

[mstange]

For macOS code signing it might be interesting to look at Gregory Szorc's work described in this post, especially the section titled "Remote Code Signing".

[Gankra]

I did a ton of research/design work on this for Windows, so here's a tl;dr (although I also recommend signpath's description):

You can codesign many things on Windows, most notably: exe, msi, and ps1 (yeah, they embed the signature in code comments).

Windows does not require code signing, but it is increasingly ramping up SmartScreen (its version of Gatekeeper) in newer versions of the Windows. Just like with macOS one can imagine that at worst they are pushing towards a world where unsigned apps are banned. At best they are definitely throwing up barriers that can confuse/off-ramp potential unsophisticated users of your app.

SmartScreen appears to currently only apply to files with the "mark of the internet" which is applied to files downloaded from the internet. This is something voluntarily applied by applications that are trying to be "responsible" (browsers) when they either download a new file, or unpack an archive that has the flag. "Irresponsible" applications are freely allowed to fail to set/copy the flag for files they write. This is why you don't see SmartScreen when you run a game downloaded with Steam or Itch.

When the mark of the internet triggers SmartScreen, it asks Microsoft whether the application is "trusted". Trust can be established in a couple ways:

1. Submit the application to Microsoft for manual inspection. After an indeterminate period (days to weeks it sounds?) they will register its signature in their databases.

2. Sign the application using Microsoft's SignTool (hashes the application, uses a certificate to sign the hash, staples the hash to the application), then wait for Microsoft to see enough installs of your applications for your certificate/signature to Become Trusted (more on that below).

We're talking about code signing, so let's assume we want to use that approach. A certificate Becoming Trusted is a very vague process, and how long it takes seems to depend on where you certificate comes from. Basically initially users will still get hit with SmartScreen, but after enough installs (sounds like dozens to hundreds?), Windows will stop throwing up SmartScreen on your apps. You can also multi-sign an application to build trust on new certificates before an old-but-trusted certificate expires.

The "better" your certificate is, the shorter this Becoming Trusted period will be, with the best option (EV) being instantaneous. I'm not totally clear on if totally self-signed certificates will ever Become Trusted -- what I do know is that Microsoft would prefer that you get a code signing cert from a proper authority.

There are two tiers of Proper code signing cert: OV ("regular") and EV ("premium"). Both kinds of certificate involve a lengthy corporate validation process from the certificate authority, with EV's being longer and more expensive. Rather than Microsoft being in charge of this process, they use the bog standard Certificate Authority infrastructure we all know from HTTPS. On the surface sounds really good, but in practice this means that code signing is liable to put you in the hole for $300-500/year, making Apple's closed system look like an absolute steal.

Historically there were also looser requirements on how OV certificates were managed, making them more desirable for "rolling your own" infra. Specifically you previously were allowed to just download the private keys for an OV cert, while EV certs had to be managed with an HSM ("yubikey"), which isn't something you can just plug into your Github SECRETS!

However as of June 2023 (yes, that recently!) the entire industry has enacted a new policy requiring OV certs to also be managed with an HSM, so there's no logistical benefits to using OV anymore. It's just a question of if you want to be extra $$$ to never have your users get SmartScreen'd, or if you're willing to save a few bucks to have the first few installs still be treated as sketchy.

As alluded to, this is a big problem for wanting to sign things that are built in Github CI, where your yubikey most certainly is not. To deal with this certificate authorities have been scrambling to introduce new cloud service offerings where you send them the hash of your app and they sign it using the certificate you bought from them. This completely fragments what "signing your app for windows" looks like, making it impossible to write any kind of docs or turn-key solutions.

I spent a fair amount of time experimenting with ssl.com's offerings, which was a ton of bespoke/frustrating work even though they did a great job streamlining things:

• eSigner is a cloud-based API for signing your applications
• CodeSignTool is an opaque Java blob that wraps up SignTool and their eSigner REST API
• sslcom/esigner-codesign is a Github Action that wraps up CodeSignTool

[cr1901]

Thank you for your effort in putting this info into one place. Unfortunately, a lot of my Rust CLI apps are niche "one-offs". Right now, I wouldn't consider spending hundreds of dollars a year just to have them code-signed. For ppl who would use my one-offs, it's simply easier to put a notice that "Microsoft does not make getting rid of Smart Screen easy, you'll need to use your own judgment when trusting my Releases". I'm still watching this issue w/ interest and hope the industry catches up to how software is deployed by ppl like me :P.

[Gankra]

I'm going to split off the apple signing to a separate issue since this ended up largely being the windows impl:

• signing: apple codesign #1121

---

In 0.15.0 the windows signing shipped with support for using ssl.com certificates, feel free to file issues for other providers. See these docs for details, and for why it's just one cert vendor (although I'm moving them here in a hot minute)

[Gankra]

See also:

• signing: windows Trusted Signing #1122