search

smallstep / cli

🧰 A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, etc.
https://smallstep.com/cli
Apache License 2.0
3.57k stars 247 forks source link

Sign the winget packages published for Windows clients #1144

Open Nogal opened 3 months ago

Nogal commented 3 months ago

Hello!

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 commented 3 months ago

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

redrac commented 2 months ago

+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 commented 1 week ago

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.