GitHub Community
Replies: 23 comments 34 replies
-
|
That's really nice, thanks! How would this interact with Release artifacts, given that Actions artifacts are not permanent? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Oh I see, you attest arbitrary files, the word artifact confused me for a bit. Very cool, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Another feature to lock down the users to a single platform? |
Beta Was this translation helpful? Give feedback.
-
|
Hopefully, not!, for two reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
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: But if I try to download it & verify inside a GHA (using this workflow), the workflow run fails: 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 |
Beta Was this translation helpful? Give feedback.
-
|
Hello!
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 I'm going to follow up with the Actions team to see if we can refresh the Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Ahh, that explains it.. if I do an update of Thanks! Looking forward to playing with this some more.. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
Would be nice if in the (far?) future this could be used for signing executables (such as PE binaries) or packages (such as |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
🤔 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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
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 🙂.
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 The way forward to simplify our lives would be for Maven to support verifying that attestations coming from |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Great. I just wanted to provide feedback on feature that would be nice to have.
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
@martincostello In your case do you want an individual attestation per artifact or would you prefer to have 1 attestation with many subjects? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@martincostello In the latest build, the subject limit has been bumped from 64 to 2500 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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, |
Beta Was this translation helpful? Give feedback.
-
|
I love what I'm seeing, but unfortunately after testing it a bit (C0D3-M4513R/time#3) I ran into one show stopper:
Effectively I cannot generate a sbom from my cargo.toml under windows, which of course stops me from doing attestation with an sbom there (but with the current setup of one matrix build it would mean no sbom for any attestation effectively). |
Beta Was this translation helpful? Give feedback.
-
|
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 😄. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, but when including an sbom is almost as easy as just doing provenance I'll gladly go the next step. 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.: (Yes I'm aware, that scanning all attestations requires a significant amount of computational power when dealing with large numbers of attestations.) |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
For those of us who want to verify artifacts within an application as opposed to an environment where we can run executables (e.g., within a V8 sandbox), is there any library that we could call that serves the same function as |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
My build process generates a lot of artifacts: https://github.com/stdedos/junit2html/actions/runs/10125546240
I may not be understanding attestations at all, so be nice 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/orgs/community/discussions/122028#discussioncomment-11126236 |
Beta Was this translation helpful? Give feedback.
-
|
@stdedos the latest release introduces support for multi-subject attestations: https://github.com/actions/attest-build-provenance/releases/tag/v2.0.0 |
Beta Was this translation helpful? Give feedback.
-
|
is it possible set a rule in order to create attestation only from protected branch? |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to list all the attestations for a given GitHub repository or GitHub Org using the Rest API? |
Beta Was this translation helpful? Give feedback.
-
|
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
Do you mean listing all attestations with just a repo or organization name without specifying the hex digest? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
We generate about 100 attestations per release. The attestation view |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
The latest release introduces support for multi-subject attestations: https://github.com/actions/attest-build-provenance/releases/tag/v2.0.0 |
Beta Was this translation helpful? Give feedback.
-
|
Are there any plans to make this available to user-owed private repos? Otherwise please add some sort of notice to the Attestations page. Twas rather annoying to go through the trial and error of setting it all up only to finally be met with
|
Beta Was this translation helpful? Give feedback.
-
|
At this point, there are no plans to support this feature on private repos unless you are on the GitHub Enterprise Cloud plan. This is described in the docs and we've updated the READMEs for the attestation actions to include this information as well. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Any particular reason that there is no means of removing attestations? And there may be occasions where you specifically want a binary not to pass an attestation check (e.g. when delisting a package). |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your feedback! This is currently being worked on. We plan to add capabilities to delete and bulk manage attestations soon. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, after playing around with it a little bit i have encountered some friction points that i think may be interesting to share with you. To keep it concise i mainly emphasized on the bad experiences, but overall i had a good time, github artifacts seems like a really good feature with easy integration with github actions and a promising future. 1. GHCR use some kind of "bundle" format for attestations that makes it a little more tricky to interact with the popular 3rd party tool cosignIt's not really a major problem but it doesn't feel very clear, like here's an exemple :
TAG=latest
GITHUB_REPO=pracan/docker-like-name-generator
regctl manifest get --format raw-body ghcr.io/${GITHUB_REPO}:${TAG} > manifest.json
DIGEST="sha256-$(sha256sum manifest.json | awk '{ print $1 }')"
regctl artifact get ghcr.io/${GITHUB_REPO}:${DIGEST} > bundle.json
cosign verify-blob-attestation --bundle bundle.json --new-bundle-format --certificate-oidc-issuer="https://token.actions.githubusercontent.com" --certificate-identity-regexp="https://github.com/${GITHUB_REPO}/\.github/workflows/.+*" manifest.json
# verify image with public key stored in GitLab with project name
cosign verify-attestation --key gitlab://[OWNER]/[PROJECT_NAME] <IMAGE>
#or
# verify image with public key stored in GitLab with project id
cosign verify-attestation --key gitlab://[PROJECT_ID] <IMAGE>While it's not a major problem i think it lacks simplicity and it can be improved by either a contribution to The reason i'm posting this is that i've seen different posts about it that leads me to believe that i may not be the only one that have asked myself the question "How can my end-users verify my artifact if they're not using gh-cli ?" : Maybe this is more of a 2. "https://slsa.dev/provenance/v1 page" is an interesting summary tool but you can't query itA quick comparison to highlight my problem (i'm using a public repo) :
I think it's very important to add a Ps : Why are all my artefacts named "https://slsa.dev/provenance/v1" in my 3. Weird "is it public/login-only ?" experienceThis one really is a minor inconvenience. I've made a public repo with `Apache-2.0` license, but some of my project are fully public and available for anyone to see and some are restricted to github users. On the
On the
On the
In an hypothetical case where i would like to provide attestation to my end-users it's important for me that my end-users can actually access the attestation i supply them. I don't really think it's an issue and i understand that different end-points need different level of protection from things like bots for exemple. I'm just sharing a feedback. Maybe what i'm looking for would be :
|
Beta Was this translation helpful? Give feedback.
and others
-
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:
❔ Still have queries❔
Beta Was this translation helpful? Give feedback.
All reactions