-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation on signing Windows and MacOS apps #250
Comments
There's nothing conceptually preventing the use of sigstore services for the Windows or MacOS ecosystems, but since the sigstore public Fulcio instance isn't in the trust stores of either operating system by default, you would still have the same UX of having to click through a warning. We could document the current path but I think most users would be left with the same frustration you described. Solving this for Windows and MacOS is definitely on our radar but we have a bit of a 🐔 / 🥚 problem :/ |
So if fulcio is the "Let's Encrypt for code signing" then this begs the question:
So then the questions that follow are:
And also: |
Just my own two cents, but I think documenting this would have a positive effect on adoption. Right now you're not going to have the attention of any Windows or macOS devs because they won't even be able to figure out how to sign their own apps, even if it's just for the purposes of playing around. But if you do document it you might garner some interest, which may reach the ears of Apple and Microsoft. |
For Microsoft there are a few options since Microsoft Authenticode is effectively used for codesigning under Secure Boot. I have written a lot of code for this in Go so writing a utility to get valid signing for EFI executables was fairly trivial: https://github.com/Foxboron/authenticode-fulcio But I'm not sure how this would fare on an real Windows binaries. Hooking it up certificate generation from What is the codesigning utility for macOS? |
I tried to sign a PE file with my tooling + a few others to see if I could get something valid. But it seems like there is something missing in the certificate chain as none of the tools are capable of creating a valid signature. There is also an issue where the binary would only have a valid signature for 20 minutes so I'm not super sure about the practical use-case yet. Need to try read a bit more up on Microsoft Authenticode and figure out what is missing. |
Any update on this? Free signing for Windows and macOS apps would be pretty great. |
There are no current plans to include the Fulcio root in the macOS or Windows trust stores. The way that Sigstore manages and updates its roots of trust through TheUpdateFramework is incompatible with the OSs' trust store requirements. As for the short expiration, Authenticode supports including a signed timestamp. Sigstore is working on spinning up a timestamping authority (TSA), though you could also request a signed timestamp from a TSA like Digicert's. For any TSA where its root is not trusted by the OS, you will run into the same warnings. re: #250 (comment), there may be some X.509 extension or additional value that needs to be set in a Windows code signing certificate. We have a specification for issued certificates in our docs. Happy to include documentation in this repo if someone wants to explore how to use Fulcio to sign Windows or macOS apps. |
Just a note here, but Smart Screen (which IMHO is the main reason to sign code on Windows) treats OV and EV certificates differently. EV certificates are trusted by default (assuming the CA is trusted) while OV certificates just allow you to pool the reputation of all the executables they have signed. Here are some examples:
If you are forced to use OV certificates (for example because EV code signing certificates are not available to individuals) there are 2 tricks to minimizing warnings:
I say all this to say: 10-minute OV certificates are not useful with respect to Smart Screen. I would love it if we could convince Microsoft that a subject rather than a certificate should build reputation, but I imagine you would need some serious pull with Microsoft to make that happen. |
Another reason for code signing is that it is needed for "modern" Windows 10/11 applications.
Why would you want it besides migrating away from ancient MSI/exe installers? It provides better integration with OS because it now has an actual concept of "application" instead of a bunch of random values in registry, it provides easier ways to do basic tasks such as registering file type associations, and more importantly: some new Windows APIs simply won't work if your app is not an "application" in Windows 10 terms. However, because for such apps code signing is now enforced by OS, many people are unable (including myself) or unwilling to package their apps in a modern way. Having open source and free tool for code signing will go a long way to help this. I hope Microsoft realises it too at some point. |
@9072997 the other main reason is to have the UAC prompt be from a "verified publisher," and not be an intimidating yellow |
MISX is a complete dumpster fire. I tried it in a production environment last year and I can link you the litany of bugs that microsoft refuses to fix or in some cases even acknowledge. Bugs with multi-page lists of loyal windows developers panicking that they are going to get fired for failing to be able to deploy a working application to their customers. In the end I had to write a lot of custom code to work around janky implementation mistakes in the MSIX and Windows application installer libraries. Given that, and the comments on this issue, I feel like the best way forward is for everyone to start telling users 'we don't support windows anymore, there is a version you can install but you will have to jump through some hoops to get it working. Report your problems to windows or switch OS.' Their market share is dropping and linux is getting easier to switch to. Let's put the ball back in their court. |
Just dropping support for Windows completely sounds like a terrible idea, sure the market share might be dropping, but it's still the most popular OS by a long shot. Also, the signing situation on Windows just got worse. You used to be able to sign your apps with an OV signing certificate, which was available for "just" 100$, However, those prices just tripled, because now you have to store the private keys on FIPS compliant hardware. Having a way out for open source projects is more important than ever, however Microsoft, as usual, just pretends we don't exist |
I've been following this issue for some time, in the hopes that free or low-cost code signing may soon become available for Windows distributions. After re-reading the topic, can anyone help me understand why the following two workarounds aren't tenable?
|
Probably as was stated here #250 (comment) the certificates don't comply with trust requirements, as Authenticode trusted certificates also certify the legal identity of the signer, so if a CA cross-signed fulcio they would probably get untrusted as for why users not being able to install the certificate idk |
In my opionion that basically defeats the purpose; you can already ask users to install any self-signed cert/ca and then install your app signed with it. Indeed, tools like Zadig self-sign the automatically generated drivers it creates, installs the cert and then installs the driver all in one "admin approved" operation. Someone security conscious would certainly prefer to install a CA like Fulcio rather than any "random developer" CA, however in reality most users are not that security literate. |
If not by being accepted into the root stores or even cross-signed, then I have to wonder if convincing users to install the master/root CA may be the only option. It would require an education campaign, maybe explain how security requires establishing trust and how Fulcio works in that regard. But if we want to break into what feels like a proprietary walled garden and start building a network of trust in the FOSS world, I think it's going to take some convincing of the masses. |
Adding onto #250 (comment), the requirements for inclusion into a trust root are not feasible for an open source project. For example, Microsoft's requirements include a yearly audit, which would be prohibitively costly. As for "Ask the user to manually install the Fulcio CA into their cert store", there are no technical blockers for users who choose to include the Fulcio root in their trust store. As I noted in #250 (comment), Sigstore distributes its roots of trust using TheUpdateFramework. Users would have to monitor Sigstore's TUF repository to keep up to date with the latest roots. This isn't a great UX. Also note that a key part of Sigstore's threat model includes transparency for signing events. Artifact inclusion into a transparency log is checked by Sigstore clients, but would not be checked by the operating system. If someone would like to author documentation for using Sigstore with Windows/macOS, or create a daemon that loads Fulcio's root from TUF into the OS trust root, I'd be happy to review. |
I am also looking into this as an individual developer of open source Windows applications. The current state of affairs doesn't make financial sense for small/individual projects. How about a solution like the following:
Trust model:
Anyone seeing a problem in this approach? I have no experience with Mac so I don't know if the same model could be used. |
I am not sure if using a $300/year certificate of one vendor for such a use case is against their contracts, so this should be checked first. Maybe it is also possible to contact such a vendor or Microsoft and create a special contract for this organization. Uploading files to a central organization has some drawbacks. Maybe this can be reduced by only uploading file hashes? Pros of using hashes:
Drawbacks of using hashes:
Also, there should be some validation of the developer and transparency of what has been signed. Therefore, I suggest the following:
|
@JoanCharmant Well this organization has to assume the responsibility for the signed binaries. If the org will be working only with a small closed circle of vetted developers, I guess it may work, but it does not change the big picture, and a bunch of developers can just as well start a company together for that purpose today (or some sort of non-profit or unofficial partnership). However if this organization will actually try to be open and allow anyone to sign their binaries, some malware will inevitably slip through, and the cert will be revoked by the parent CA. Even if the org tries to do thorough identity verification of developers similarly to what existing CAs do, since it is not officially a CA it is not as "protected" from actions of its users as regular CAs, and legally signs binaries on its own behalf. I would expect the cert of the org to be revoked very quickly. |
@ChristianGalla file hashes do not provide cryptographic authenticity. They provide integrity. To securely transfer the authenticity of a set of files, you'd need signatures -- not hashes (or a manifest file with hashes that itself is signed). |
@maltfield of course I mean normal digital signatures using hashing (HMAC). Usually, a digital signature / certificate is computed and used the following way:
This way, a digital signature guarantees authenticity and integrity, because both are needed. In my proposal, step 1 could be computed on the local computer of the developer and only step 2 in the environment of the organization. |
@JoanCharmant I think you’re looking for the SignPath Foundation. They sign Windows binaries for projects like Mumble or Vim. See also here. |
I think the price of 500$ defies the reason to use it in the first place. |
Disclaimer: I work for SignPath |
From what I can tell (https://about.signpath.io/product/editions), it's a standard (OV) certificate, not EV certificate. So, people would still get warnings (as per #250 (comment)). |
Hi @agarny, that's correct, there are warnings until Microsoft SmartScreen has seen the software often enough in the wild and decides that it can omit the warnings, then they go away. We are considering providing EV certificate for OSS projects at SignPath also, but are not quite there yet. |
We are looking forward to it :) Since usually open source projects it's common to have bursts of releases, and "desert" time periods with no releases at all, instead of having timely releases, waiting for SmartScreen to decide when an application is "safe", is not a viable solution. |
It seems GitHub now has its own Root CA that supports Fulcio: Idk if that means if the Root CA is actually trusted by Microsoft. But given it's a Microsoft product I would hope that it is? |
@arianvp that GitHub root CA isn't in the Windows trust store: https://learn.microsoft.com/en-us/security/trusted-root/participants-list I'd be surprised if there were any plans to trust the CA, because GitHub are using TUF (like Fulcio) which doesn't meet Microsoft's requirements: #250 (comment) For Windows codesigning, it's worth considering Azure Trusted Signing: https://azure.microsoft.com/en-us/products/trusted-signing |
Closing this issue as there are no other topics for discussion. |
Just wanted to follow up on @pl4nty's comment: |
After reading your
README.md
, the elephant missing is: how do I actually sign my releases using a fulcio-issued code signing certificate for Windows and MacOS?Context: I maintain an open-source project. I sign my releases with PGP and provide documentation to my users on how they can cryptographically verify the authenticity of my releases using
gpg
. However, despite this, my Windows and MacOS users get annyoing alerts about "untrusted software".Because I'm an Open Source project without a budget, I'm not about to go pay $100/year for a code signing certificate to be used in the Microsoft ecosystem or an additional $200/year for another certificate for Apple.
So when I saw that sigstore provides temprory-issued code signing certificates like Let's Encrypt does for websites, I was stoked that I may be able to smooth-out this annoyance for my users. But I couldn't find a guide on how to do this.
Please document:
The text was updated successfully, but these errors were encountered: