GitHub Artifact Attestations now in Public Beta

[chrispat]

Hey, Y'all!
I’m excited to announce that GitHub Artifact Attestations are in public beta🎉

❓ What does this mean❓

Artifact Attestations allow project maintainers to effortlessly create a tamper-proof, unforgeable paper trail linking their software to the process which created it. Downstream consumers of that metadata can then use it as a foundation for new security and validity checks through policy evaluation via tools like Rego and Cue. We’re starting with verification support based on GitHub CLI, but will expand to bring these same controls to the Kubernetes ecosystem as well later this year.

📑 Want to learn more? Here are some resources:

• Where does your software really come from about software attestations
• Our blog post with an overview of the new capabilities
• The docs give you all of the details about how repository rules work.

❔ Still have queries❔

• Feel free to post here for feedback.

[teo-tsirpanis]

That's really nice, thanks!

How would this interact with Release artifacts, given that Actions artifacts are not permanent?

[chrispat]

While actions is required for creating attestations you can use those actions to attest any artifact regardless of where you are storing it. So you could have your workflow attest all of the binaries you are publishing to a release.

[teo-tsirpanis]

Oh I see, you attest arbitrary files, the word artifact confused me for a bit. Very cool, thanks!

[prabhu]

Another feature to lock down the users to a single platform?

[phillmv]

Hopefully, not!, for two reasons:

1. All attestations generated on our platform can be downloaded and stored elsewhere.
2. Attestations generated for public repos use the Sigstore public good instance. These "open source" attestations can then be verified without any infrastructure that GitHub owns or controls.

[finnigja]

Is there any reason why I wouldn't be able to create an assertion in one GHA workflow, then verify that assertion in another GHA workflow? Both workflows live in the same repo.

I'm experimenting with this over at https://github.com/finnigja/stunning-broccoli. It builds & attests a release successfully in this workflow.

If I download the attested artifact locally I can verify it:

$ gh attestation verify ~/Downloads/stunning-broccoli-v0.0.2.tar.gz -o finnigja
Loaded digest sha256:699a957d21b31bf2513d8d6a191745fd846b0c6602489bd4aa2707afbcef8822 for file:///Users/jsf/Downloads/stunning-broccoli-v0.0.2.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:699a957d21b31bf2513d8d6a191745fd846b0c6602489bd4aa2707afbcef8822 was attested by:
REPO                        PREDICATE_TYPE                  WORKFLOW
finnigja/stunning-broccoli  https://slsa.dev/provenance/v1  .github/workflows/build-attested-release.yml@refs/tags/v0.0.2

But if I try to download it & verify inside a GHA (using this workflow), the workflow run fails:

gh attestation verify stunning-broccoli-v0.0.2.tar.gz -o finnigja
Failed to verify the artifact: failed to fetch attestations for subject: sha256:699a957d21b31bf2513d8d6a191745fd846b0c6602489bd4aa2707afbcef8822

It has the correct SHA for the artifact, which I think suggests the artifact is downloaded correctly but there's maybe a problem with retrieving the assertion to verify against?

It's definitely there... https://github.com/finnigja/stunning-broccoli/attestations/789050.

I've tried swapping the tokens that the gh step is using so it's the same PAT I'm using locally instead of the default workflow token, but get the same error.

[phillmv]

Hello!

Is there any reason why I wouldn't be able to create an assertion in one GHA workflow, then verify that assertion in another GHA workflow? Both workflows live in the same repo.

No, there is no reason why! Thanks for this very tidy report with a convenient public repo for me to poke at.

I forked your repo and tried it on on my end and the unsatisfying answer is…………

the version of gh that ships in Actions does not support the current version of provenance attestations our tool generates 🤦‍♀️.

I'm going to follow up with the Actions team to see if we can refresh the ubuntu-latest image accordingly.

Thanks!

$ ./bin/gh version
gh version 2.48.0 (2024-05-07)
https://github.com/cli/cli/releases/tag/v2.48.0
$ ./bin/gh at verify ~/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz -o phillmv
Verifying attestations for the artifact found at file:///Users/phillmv/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz
Failed to verify the artifact: failed to fetch attestations for subject: sha256:2c1108441c85e2dbeff3251145f3bce33f0e9e7550b0201a4e21a3a116085049
$ gh version
gh version 2.49.0 (2024-04-30)
https://github.com/cli/cli/releases/tag/v2.49.0
$ gh at verify ~/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz -o phillmv
Loaded digest sha256:2c1108441c85e2dbeff3251145f3bce33f0e9e7550b0201a4e21a3a116085049 for file:///Users/phillmv/Downloads/stunning-broccoli-fork-v0.0.3.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:2c1108441c85e2dbeff3251145f3bce33f0e9e7550b0201a4e21a3a116085049 was attested by:
REPO                            PREDICATE_TYPE                  WORKFLOW
phillmv/stunning-broccoli-fork  https://slsa.dev/provenance/v1  .github/workflows/build-attested-release.yml@refs/tags/v0.0.3

[finnigja]

Ahh, that explains it.. if I do an update of gh in a test workflow, the attestation works as expected. 🎉

Thanks! Looking forward to playing with this some more..

[kbdharun]

Thanks for the new feature, the attestations tab still seems to reference the old deprecated action in github-early-access org instead of the one from the actions org. [Even if the README has a deprecation warning, this link should probably be fixed]

[steiza]

This has now been fixed, thanks for letting us know!

[trungnt2910]

Would be nice if in the (far?) future this could be used for signing executables (such as PE binaries) or packages (such as .msix files).

[hfhbd]

Do you have any sample how to use this with Maven Central? Maven Central already requires a signing certificate, uploaded to a public key server. Can I use the short-lived X.509 key to do the signing by myself (using maven/Gradle) without the GitHub Action? If so, how do I get the short-lived X.509 key?

[phillmv]

🤔 skimming over the maven requirements, i fear the answer is "sort of but not really".

You could in theory configure our signing setup to use a long lived key – or upload the ephemeral key to Maven – but then why bother? Once you set up your actions workflow to have access to a specific key that Maven recognizes you'd done all the hard work of signing; one of the points/goals/advantages of Sigstore and our Artifact Attestations feature is that it reduces the burden of distributing public keys down to the security of your GitHub account.

For Maven in particular, Artifact Attestations are a complement, an additional feature to be used alongside their GPG signing.

[hfhbd]

But wouldn't it possible to create the short live key, convert it to GPP format (?) and upload it to a public key server in a setup action, exposing it as an output/environment variable to use it with maven? 🤔

Then I don't need to maintain my personal GPG key that also expires. And shouldn't it also simplify the validation of the signed artifacts by only trusting GitHub certificate, and not each personal certificate?

[phillmv]

But wouldn't it possible to create the short live key, convert it to GPP format (?) and upload it to a public key server in a setup action, exposing it as an output/environment variable to use it with maven? 🤔

I think it is possible! You could create the key, use it to sign with gpg, upload the key to maven, then use the same key to sign the attestation, and then throw it away. I just don't think that in this case it buys you anything 🤔 to have the same key used for both the gpg maven signing and for signing the attestation.

The time-saving trick you're performing here is storing your Maven credentials as a secret on your repo, and having the workflow generate and upload the key for you. You can make this work today and save yourself from managing the long lived key without making that key be the same key used for the attestation 🙂.

And shouldn't it also simplify the validation of the signed artifacts by only trusting GitHub certificate, and not each personal certificate?

In Sigstore, the trust we're verifying lies in the certificate authority's key that generates the certificate. It's the cert authority (aka Fulcio) that verifies the authenticity of the signing request. When we verify artifacts signed with Sigstore, we check for the validity of the Fulcio certificate and the values embedded inside that certificate. (Did this artifact originate from the your-name/your-repo? yes or no?)

The way forward to simplify our lives would be for Maven to support verifying that attestations coming from your-name/your-repo have been signed using Sigstore 😄, i.e. what we did with npm, in addition to GPG keys.

[Forrin]

Support for multiple subjects within an Attestation would be useful and something I'd like to see. The current solution will create an attestation for each subject, however many of the predicates expect that multiple subjects will exist.

Furthermore, I'd like to be able to add subjects without having to reference a file. A good example is the git commit as a subject.

I think supporting other signing tools could be useful, though allowing a privately run Fulcio would be a good first step.

I think much of this can be done with the libraries that exist.. or forking them and making some adjustments. I'm sure I'll see more as I work with this tooling.

Something else I'm interested in is creating attestations for each supply chain step (collecting data on the step... the action/command, state of work dir before and after, etc). This is possible if you create a composite for each action of interest... but it's a lot of work. Ideally we could switch in-toto attestations on and get them, mostly, for all workflows.

Thanks

[phillmv]

Support for multiple subjects within an Attestation would be useful and something I'd like to see.

We'll likely introduce support for this later this year.

To help us design the feature, could you give us some examples of attestations/predicates you want to create?

[Forrin]

Vulnerability scans, test results, etc. In many cases we probably want the git commit sha in the subject. For test results, we may want the tested files to be in the subjects (or a dir hash?), especially for a mono repo.

[dalcinl]

Is it possible to remove/delete attestation entries from org/repo/attestations list? I got a couple entries there after testing the new feature. However, I would like to remove them because I would like to have there just final release artifacts once I publish my next release.
https://github.com/mpi4py/mpi4py/attestations

[phillmv]

We have planned to add this ability, but unfortunately we didn't get to it in time for our public beta. If you happened to attest something that absolutely needs to be deleted (i.e. for legal reasons), please reach out through support and we'll do it manually.

For right now, for what its worth, from your users' perspective you should be directing them to use the gh attestation verify -o mpi4py <filehere> command – and there they won't see any of the extra attestations 😄.

[dalcinl]

We have planned to add this ability, but unfortunately we didn't get to it in time for our public beta.

Great. I just wanted to provide feedback on feature that would be nice to have.

use the gh attestation verify -o mpi4py command

To clarify: This would still work even if the artifact filename (and attestation name) is the same for different attestations? As you can see in the attestation list of my project, all entries are named mpi4py-4.0.0.dev0.tar.gz.

[phillmv]

This would still work even if the artifact filename (and attestation name) is the same for different attestations?

Yep! We take the artifact digest and ignore the filename. As long as the contents of the file are the same, then it should work.

[dfunkt]

1.Are there any plans for supporting multiple SBOM files? Using "BUILDKIT_SBOM_SCAN_STAGE=true" in a multi-stage Dockerfile creates additional files (https://docs.docker.com/build/attestations/sbom/#scan-stages) which should be included in the attestation process.

2. Are there any plans for some sort of auto sourcing the SBOM files from a Docker container that has been built with "sbom: true"? (talking about those built with bake-action/build-push-action prior to the SBOM attestation step of the workflow)

[phillmv]

Is there any reason why I wouldn't be able to create an assertion in one GHA workflow, then verify that assertion in another GHA workflow? Both workflows live in the same repo.

Interesting! Do you have any samples for us to look at? I think the short answer is… if you have multiple SBOM files for a single specific image manifest digest, then feel free to create multiple SBOM attestations for that one digest.

• But if we're talking about "one manifest, but each layer has its own SBOM" then we'll have to gather some feedback on how users interact with the layers (vs the top level manifest)

Are there any plans for some sort of auto sourcing the SBOM files from a Docker container that has been built with "sbom: true"?

We're still figuring out how the community wants to interact with SBOMs. Due to the nature of a software bill of material, it's very hard to provide a generic solution / snap to any particular solution. Our inclination at the moment is to say "you tell us where your sbom is and we will make sure it's associated with your container image" – but we're very much open to feedback.

[martincostello]

I just discovered that there's a 64-file limit to the number of items that can be attested, which is preventing me from using attestation on a handful of repositories where we produce ~100 binaries/packages. Can this limit be raised?

[chrispat]

@martincostello In your case do you want an individual attestation per artifact or would you prefer to have 1 attestation with many subjects?

[martincostello]

I assumed that we should be doing an attestation per artifact (our users don't necessarily use all of them, they might just use one). If there's a different scenario we should be doing that's the other way around that's effectively the same for the end-user to do "this file came from this build" that would be fine.