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.

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

Can you explain the process of adding attestation to source only tarballs. If I don't distribute binaries/have a GA doing a build, is attestation added to the process GH performs to create a source tarball when a new release is created?

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.

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

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..

🤔 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.

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?

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.

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 thlived X.509 key?

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?

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.

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 command, state of workbefore and after, etc). This is possib if you create a composite for each action of intere. but it's a lot of work. Ideally we could switch in-toto attestations on and get them, mostly, for all workflows.

T

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 😄.

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.

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.

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 In your case do you want an individual attestation per artifact or would you prefer to have 1 attestation with many subjects?

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.

@martincostello In the latest build, the subject limit has been bumped from 64 to 2500

Hi! Artifact attestations use signing and a special metadata format - the attestation predicates you linked - to handle authenticity and digest validation. The attestations are signed, which provides authenticity, and the digests are stored within the dsse envelope & attestation predicates.

Hope that helps,

Thanks for reporting this! Fwiw, in our opinion, if you distribute builds of your software in general it is very useful to attest their provenance – above and beyond whether you include a bill of materials 😄.

Sure, but when including an sbom is almost as easy as just doing provenance I'll gladly go the next step.
I believe that just including provenance is not enough for most cases, especially when considering what happened to xz and log4j.

In the case of log4j the damage could/can be assessed for almost all publications, since in maven and gradle dependency information is published alongside the release artifact.

When looking at Attestations with sbom's I see a way to do the same thing with arbitrary files.

e.g.:
Let's assume we have a repo, where artifacts mostly have attestations with sboms.
This could then allow for automatic flagging of potentially vulnerable attachments of releases and tags on a repo.
Whenever you detect a dependency with a security issue you could scan all the attestations and look for the vulnerable dependency. Then you can flag all tag/release attachments on the repo with that hash.
Vulnerability information could then be shown for all individual release/tag attachments as additional information.

(Yes I'm aware, that scanning all attestations requires a significant amount of computational power when dealing with large numbers of attestations.)

Hello,

Yep! We use the sigstore-go library to do this. That said, my recommendation is to use our cli utility where possible, because setting it up correctly requires a lot of work: you will at the very least have to care about distributing key material from our tuf repository.

For more information, you can see how we've implemented it in our cli utility here: https://github.com/cli/cli/blob/trunk/pkg/cmd/attestation/verify/verify.go

In addition, I believe there is a Python implementation, and there may be one in progress in Rust.

The GitHub documentation states that you can list attestations for a given user, a repository, or an organization, but you'll need to provide a subject digest in the format of sha256:HEX_DIGEST as it's required.

• Organization: https://docs.github.com/en/rest/orgs/orgs?apiVersion=2022-11-28#list-attestations
• Users: https://docs.github.com/en/rest/users/attestations?apiVersion=2022-11-28#list-attestations
• Repositories: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#list-attestations

Do you mean listing all attestations with just a repo or organization name without specifying the hex digest?

Thanks @AptiviCEO,I saw those entrypoints but I'm interested to visualise all those details without specifying the hex digest. I can see the UI supports those details at the repo level: https://github.com/ORG/REPO/attestations.

OTOH, the name list-attestations is misleading, I see some other list-<entity> endpoints that don't need any further details, such as list-members, list-packages, list-pull-requests to 'list' a few

We're working on a feature which which will allow you to associate multiple subjects with a single attestation. This should help to clean-up the attestations list as anything which is attested as part of the same release will be represented by a single attestation.