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

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

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

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.

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.

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,