Usage of GitHub Artifact Attestations

[pellared]

I propose to check if GitHub Artifact Attestations (which uses Sigstore cosign under the cover) would good for signing different type of release artifacts. Video

It looks to be the most user-friendly and straightforward approach for signing different type of artifacts (containers and files) when using GitHub. See here how easy it it to use, especially for binaries (or any files). actions/attest-build-provenance is a GitHub Action which does the signing. Verification can be done by using gh CLI.

I can give it a shot and test it for https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation. However, I would like the Security SIG to make a quick assessment if it is even worth testing. Please assign me if I should start testing it out.

If the approach would work and be acceptable then we should create guidelines/recommendations.

[mx-psi]

We don't use the attestation thing, but we do use cosign on the Collector: https://github.com/open-telemetry/opentelemetry-collector?tab=readme-ov-file#verifying-the-images-signatures

[pellared]

We don't use the attestation thing, but we do use cosign on the Collector: https://github.com/open-telemetry/opentelemetry-collector?tab=readme-ov-file#verifying-the-images-signatures

AFAIK Collector container images are signed but the released executables are not.

[mx-psi]

Yes, that's it, we would benefit from using this, just wanted to mention it as a "we are doing some of this"

[pellared]

@mx-psi, actually I see that Collector Releases are also publishing pem and sig files e.g. https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.112.0. Therefore, probably it is possibly to verify the binaries like described here: https://edu.chainguard.dev/open-source/sigstore/cosign/how-to-verify-file-signatures-with-cosign/.

@CodeBlanch, @Kielek told me that you recently added something similar here: open-telemetry/opentelemetry-dotnet#5880. PS. There are no user-facing docs how the users should use it.

At first glance, it looks like using GitHub Artifact Attestations is more user friendly for both maintainers and end-users.

The other good part of it is that the generated Sigstore bundle is stored with GitHub and is also written to an immutable transparency log that is publicly readable on the internet as opposed to storing the bundle in GitHub Releases artifacts and there is no transparency log. This is described here: https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds.

[CodeBlanch]

@pellared

PS. There are no user-facing docs how the users should use it.

I know, sorry. I have an issue tracking that: open-telemetry/opentelemetry-dotnet#5934

It sounds like where .NET is a bit different than Collector is we don't use release/artifacts to store the pem and sig files. We ship them inside the packages we push to NuGet. Check out: https://nuget.info/packages/OpenTelemetry/1.10.0-rc.1 (browse into the lib folder).

So as far as writing them to something immutable and transparent we are kind of already there.

That being said, I'm not opposed to using GitHub Artifact Attestations. Could switch to that or do both.

What I'm hoping is (eventually) NuGet comes around and adds first-class support for SigStore: NuGet/Home#12856.