This applies the changes from the separate Windows HSM signing prototype development to the official deployment workflow including:
1. Use of Azure Code Signing client
2. Sourcing signtool.exe from runner
3. Moving from batch to PowerShell for Windows signing script
4. Using the same signing process for .exe and .msi
Workflow is currently breaking because there are multiple versions of signtool
installed on runners. We face a challenge where we either hardcode this to a
specific version on the runner or always choose the latest version; this change
does the latter.
This update leverages GitHub Desktop approach of downloading Azure Code Signing DLL and wiring it up as part of the existing signing process used by Windows builds.
This commit is an initial prototype based on the deployment workflow, using the
Azure Code Signing service to sign Windows .exe and .msi files.
These changes have been isolated as much as possible to not affect existing
deployment workflows while also working around design issues with how GitHub
CLI workflow works with GoReleaser and now with ACS support. The biggest smell
was over whether to break from using GoReleaser or have GoReleaser control as
much about the release process as it has been versus opening / signing /
archiving the resulting GoReleaser artifacts; needless to say, the latter was
chosen for expedience as well as leaning into officially supported solutions.
- The certificate pfx file is now read from WINDOWS_CERT_PFX
- The password to decode the pfx is in WINDOWS_CERT_PASSWORD
- Quit reading from desktop-secrets repo
- Switch osslsigncode to take in pfx instead of individual certs
- 🔥 obsolete setup scripts
`script/build.go` could encounter an "Access is denied" error when the
project contains a symlink that could not be followed. This ignores such
errors with a warning and allows the build to resume.
The main build script for this project is `script/build.go` which
implements Makefile-like building of the `gh` binary and associated man
pages. Our Makefile defers to the Go script.
However, when setting GOOS, GOARCH, and other environment variables to
modify the target for the resulting binary, these environment variables
would affect the execution of `build.go` as well, which was unintended.
This tweaks our Makefile to reset variables like GOOS and GOARCH when
building the `build.go` script itself, ensuring that the built script
runs on the same platform, and adds the ability to pass environment
variables as arguments to `go run script/build.go`. This allows the
following usage on platforms without `make`:
go run script/build.go GOOS=linux
With this style of invocation, the GOOS setting does not actually affect
`go run` itself; just the `go build` that is executed in a child process.
