Closed
Description
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:
- https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
- https://www.rahulpnath.com/blog/code-signing-in-azure-devops-pipeline/
- https://stackoverflow.com/questions/252226/signing-a-windows-exe-file
- https://docs.microsoft.com/en-us/windows/desktop/SecCrypto/cryptography-tools
- https://docs.microsoft.com/en-us/windows/desktop/SecCrypto/signtool
Potentially connected issues:
- Use Azure Pipelines for CI Use Azure Pipelines or GitHub Actions for CI #959:
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. - Chocolatey installation (this new PR Add chocolatey gallery installation method #1027 and the current windows installation instructions)
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...