feat: sign release

[maxday]

👋 hey team,

In order to respect best security features, it's recommended to sign release (if they contain a artifact) as documented here: https://github.com/ossf/scorecard/blob/cd152cb6742c5b8f2f3d2b5193b41d9c50905198/docs/checks.md#signed-releases

Doing this will bump or score from 0 to 8 in the future (as documented: This check looks for the 30 most recent releases associated with an artifact. It ignores the source code-only releases that are created automatically by GitHub.)

I've tried it on my fork and it's working:

1. release is signed: https://github.com/maxday/opentelemetry-lambda/releases
2. score is 8: https://scorecard.dev/viewer/?uri=github.com/maxday/opentelemetry-lambda

This has been implemented by other repo in the open-telemetry GitHub org such as:

1. https://github.com/open-telemetry/opentelemetry-java-instrumentation
2. https://github.com/open-telemetry/opentelemetry-java-contrib

Here are some related PRs:

• Sign releases opentelemetry-java-contrib#1686
• https://github.com/open-telemetry/opentelemetry-java-contrib/blob/124993ee049a46580570a0725ce7def3c476e295/.github/workflows/release.yml#L133
• open-telemetry/opentelemetry-java-instrumentation@f9671e7

If we want to proceed, we would need a admin to create a new secret with the private GPG key value here are the steps I've done to generate the key on my fork (feel free to adjust)

Here is what I've done

1. Generate a GPG config file (replace name and email), %no-protection means no passphrase which is OK for automation. If you want we could also have a passphrase but since they're stored at the same place, I'm not sure it adds any value.

cat <<EOF > gpg-batch.conf
%no-protection
Key-Type: RSA
Key-Length: 4096
Subkey-Type: RSA
Subkey-Length: 4096
Name-Real: YOUR_NAME
Name-Email: YOUR_EMAIL
Expire-Date: 0
%commit
EOF

2. Generate the GPG key using the config file created above.

gpg --batch --generate-key gpg-batch.conf

3. Export the private key. cat the private.key file and paste it into a GitHub secret named GPG_PRIVATE_KEY and delete the local file

gpg --armor --export-secret-keys YOUR_EMAIL > private.key

Let me know what you think!

If that sounds good to you

• I'll port the change to other layer releases as well, I've just done it for the nodejs layer just to try and get your early feedback.
• We will need to publish the public key so everyone could check the integrity of the signed releases

Thanks!
Max

[pragmaticivan]

👋🏽 Wondering if we should consider attestation api/scope instead https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds#generating-artifact-attestations-for-your-builds

[tylerbenson]

Looks like @pragmaticivan's suggestion would also achieve the same goal as it should generate sigstore files. This has the added benefit of not requiring any GPG key generation or management. @maxday would you mind exploring that approach instead?

[tylerbenson]

If the alternate option doesn't work and we do need to sign things, we would need to generate our own keys and publish the key details on the otel website.