feat(package): sing windows binaries [NR-489681]

[sigilioso]

Implementation details

Implements Windows binary signing for newrelic-agent-control and newrelic-agent-control-cli executables using PFX code signing certificates during the GoReleaser build process.

The implementation uses a containerized Docker-based signing workflow that integrates with GoReleaser's post-build hooks. When Windows binaries are compiled, a signing script is executed. It uses osslsigncode for signing.

Pipelines

The GitHub Actions workflow exposes signing credentials as environment variables to GoReleaser. When the skip_sign input parameter is set to true, both packages signing and Windows executable signing are disabled (SKIP_WINDOWS_SIGN environment variable disables Windows executable signing).

Manual testing

To test the signing implementation locally with self-signed certificates:

1. Generate Test Credentials:

   ./build/scripts/windows-exec-sign/generate-testing-credentials.s

2. Sent environment variables:

   export PFX_CERT_BASE64=$(cat local/testing-pfx-cert/certificate_pfx_base64)
   export PFX_PASSPHRASE="TestPassword123"

3. Run goreleaser or sing directly

   # Test signing a single executable
   export EXECUTABLE=/path/to/your/binary.exe
   ./build/scripts/windows-exec-sign/sign.s
    # goreleaser (--skip=sing) skips package signature only, windows binaries are signed
    goreleaser release --skip=publish --skip=sign --clean --verbose --snapshot --verbose 

4. Check signature (on Windows):
   The self-signed certificate will not be trusted by Windows but we still can check that the binary contains the signature.

   File properties example

   

Checklist

• Provided a meaningful title following conventional commit style.
• Included a detailed description for the Pull Request.
• Documentation under docs is aligned with the change.
• Follows guidelines for Pull Requests in CONTRIBUTING.md.
• Follows log level guidelines.

[DavSanchez]

Looking good! A few doubts

[gsanchezgavier]

LGTM, wonder if makes sense to have some sort of test (outside this task) that validates that we are releasing signed binaries , i think we are covering with linux due to the gpg check when installing from package managers

[gsanchezgavier]

would make sense to pass this as secrets , using them only in the pre-release wf to make more difficult to sign testing assets? i think same for the GPG

[sigilioso]

It makes total sense!

[gsanchezgavier]

i pasted somehting complealty unrelated in the link 😆 , just updated it

[sigilioso]

I got the point anyway, thanks!

[sigilioso]

I've changed it here: 475b1e1 LMKWYT

[sigilioso]

wonder if makes sense to have some sort of test (outside this task) that validates that we are releasing signed binaries , i think we are covering with linux due to the gpg check when installing from package managers

🤔 I also think we should check it. I can trigger a nightly before merging and, at very least, check manually that the binaries are signed as expected. Once that is verified, we can figure out a way check the signature on Windows machines (when packages are signed and uploaded)

[sigilioso]

I've just triggered a nightly and checked the signature of the corresponding binaries. It works as expected 🎉

Signature check

> Get-AuthenticodeSignature .\newrelic-agent-control.exe


    Directory: C:\Users\calvarez\Downloads\newrelic-agent-control-windows_x86_64-pc-windows-msvc


SignerCertificate                         Status                                                       Path
-----------------                         ------                                                       ----
99C80227B0FD6238225C5E27227115F511EC0C1A  Valid                                                        newrelic-agent-control.exe


> Get-AuthenticodeSignature .\newrelic-agent-control.exe | Format-List *


SignerCertificate      : [Subject]
                           CN="New Relic, Inc.", O="New Relic, Inc.", L=San Francisco, S=California, C=US

                         [Issuer]
                           CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, O="DigiCert, Inc.", C=US

                         [Serial Number]
                           01C331132C221038E2DEBD4E825F51CD

                         [Not Before]
                           7/11/2024 2:00:00 AM

                         [Not After]
                           9/10/2027 1:59:59 AM

                         [Thumbprint]
                           99C80227B0FD6238225C5E27227115F511EC0C1A

TimeStamperCertificate : [Subject]
                           CN=DigiCert SHA256 RSA4096 Timestamp Responder 2025 1, O="DigiCert, Inc.", C=US

                         [Issuer]
                           CN=DigiCert Trusted G4 TimeStamping RSA4096 SHA256 2025 CA1, O="DigiCert, Inc.", C=US

                         [Serial Number]
                           0A80EF184B8DF10582D1C476A7957468

                         [Not Before]
                           6/4/2025 2:00:00 AM

                         [Not After]
                           9/4/2036 1:59:59 AM

                         [Thumbprint]
                           DD6230AC860A2D306BDA38B16879523007FB417E

Status                 : Valid
StatusMessage          : Signature verified.
Path                   : C:\Users\calvarez\Downloads\newrelic-agent-control-windows_x86_64-pc-windows-msvc\newrelic-agent-control.exe
SignatureType          : Authenticode
IsOSBinary             : False

I'm trying to add a validation step to check the binaries are signed right after packaging

[sigilioso]

The validation for Windows binaries signatures was added in the latest commit. After triggering a nightly, the check is working as expected: workflow execution

[danielorihuela]

Why are we using that instead of ${{ secrets.GITHUB_TOKEN }}?

[sigilioso]

We are using it to accomplish this. I decided to name them differently (using the lowercase and gh_token instead of github_token to avoid colliding with a Github reserved word) to be very explicit when using the workflow (and prevent us from using secrets: inherit again).

[danielorihuela]

Question: This is not used anywhere right? What's the purpose of adding it? Future tests or manual tests?

[sigilioso]

Its purpose is having a quick way of testing the signature part locally, in case we are changing the goreleaser script or anything that could affect the windows binaries. Is it clear enough or does it needs more docs/comments?

[gsanchezgavier]

Thanks!