Sign the winget packages published for Windows clients

[Nogal]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

The package installed on windows machines is unsigned, which is a security risk.

This can be achieved using "signtool" which is part of the Windows SDK:
https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool
https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/

Why is this needed?

Primarily, this lets any user be completely sure that the software they're installing actually came from you. Should a malicious actor get your publishing keys, they would also need to get a hold of your signing keys as well in order to really do damage.

We would like to restrict our client machines to only run trusted signed code. Currently to run step-cli this requires a whitelist exception in our policy for the executable, which of course changes between versions, and should a company implement an exception incorrectly (or even correctly depending on the limitations of their security software) it could result in malicious code taking advantage of the hole and infecting the network.

[tashian]

Looks like we could use mtrojnar/osslsigncode to sign the exe file for Winget.

[redrac]

+1 this is a common problem at our corp that the step CLI doesn't have FW access to public network because its not signed

[tashian]

Hi! I've been looking into code signing step.exe for Windows, and wanted to share an update.

GitHub being Microsoft, they have created a Trusted Signing action to do this, using a windows-2022 runner. Compared with mtrojnar/osslsigncode, this is a more modern, officially supported approach.

It integrates with Azure Trusted Signing via an Azure service account.

This action runs on Windows. In order to adopt this into our workflow, I think we'd want to use a GoReleaser split-merge build and running the Trusted Signing action after building for Windows.

One issue is, the "split" stage of the split-merge process will build the binary, zip it up, and hash the zip file.
Because the Trusted Signing action is a GH action, I don't think we could run it as a post-build hook in GoReleaser.
To add the Trusted Signing action between the split and merge steps in GoReleaser, we would have to do some surgery on the files produced by GoReleaser—re-archiving them and updating the artifact json with new hashes.
This is a brittle approach.

Ideal would be to use a post-build hook to sign the binaries, if possible. Here's the main block of PowerShell for this, but I don't love the idea of pulling all of this setup into our GoReleaser config.

I have asked @caarlos0 about Windows code signing support in GoReleaser, and it's coming soon. It may make sense to postpone this issue until that feature is rolled out in GoReleaser.