-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Sign release binaries and installers for Windows #1034
Comments
It wouldn't at this moment AFAIK. Furthermore, Chocolatey Gallery has integration with Virus Total so packages are as safe as it can get because they are not going to be approved if there are more then couple of false positives on entirety of 70+ antivirus engines. In the case of latest version there is one false positive result: Previous version has 2 results. This is the list of AV's used, there is no Windows Defender tho. |
After a couple of days of diving into the Windows certificate world 😅, I finally managed to produce a signed binary and installer. 🎉 You can see the CI changes and download the signed MSI from here. I opted to not use any third-party GH Actions for this because of security reasons:
Anyway, here's how it looks like in Windows: However, having a signed installer doesn't get rid of the "Windows protected your PC" warning dialog... 😭 Now it shows the same screen just with the correct publisher information, whereas before it showed "Unknown publisher": This SO answer and this linked one suggest that in order to remove this warning a publisher can either "gain" trust with SmartScreen over time, presumably by a lot of users choosing to ignore and run this signed installer anyway, but I don't see any guarantees of when or if that will eventually happen... Or, we can outright "buy trust" with an EV certificate, which the current one that Robin provided is not. These are usually much more expensive than regular certs and it's a plain scam if you ask me, but perhaps it might be worth it as a shortcut to get rid of this warning. @robingustafsson @na-- @mstoykov What do you think? |
Here's an idea of the time and number of installs it takes for SmartScreen to gain trust in a publisher without an EV cert:
And the other answer for that question mentions that even an EV cert is not guaranteed to get rid of this warning, but it probably speeds things up. Given this, I'm inclined to suggest that we start using this non-EV cert from v0.30.0 and just wait for MS to trust it. I reckon we can hit ~2K installs in a couple of weeks. |
Hmm not sure if we should buy into the MS EV certificate racket. Even this basic signing gets rid of the other "unknown publisher" warning, and puts Regarding signtool.exe - I think you made the right decision. osslsigncode seems interesting and I'm glad it exists, but since we're already running on a windows VM for other reasons, we have no need to use it. |
* Sign Windows release binary and installer Closes #1034 * Use more generic signtool path Resolves #1746 (comment) * Update change in secret name Resolves #1746 (review) * Remove PFX file after signing Resolves #1746 (review)
As illustrated by this recent issue, we might benefit from signing our binary releases with a valid key for Windows.
To be honest, I'm not sure if that would prevent or even decrease future antivirus false-positive results, but even if we just make that "Do you want this app from an unknown publisher to make changes to your PC" warning dialog less scary, it's probably worth it.
Some resources on the topic:
Potentially connected issues:
Since it's a Microsoft service, it's worth investigating whether there is some sort of a better way to do binary signing there. I'm somewhat worried about just uploading our future code-signing key to a random CI service, so maybe they have some sort of a key enclave or managed signing or something that adds a bit of security and transparency to the process.
Worth investigating if chocolatey, being a package manager, would actually benefit from this whole binary code-signing business. In the Linux world, it's not the binaries that are signed, but the different rpm/deb/apk/pacman/etc. packages...
The text was updated successfully, but these errors were encountered: