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!

[oreillymj]

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?

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

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

[ji-677]

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?

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

[ji-677]

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

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

[bdehamer]

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

[yanivpaz]

1. Can the attestation replace the signing process in all aspects ( authenticity, digest validation etc)?

• Signing -powerfull tool for ensuring the integrity of their software artifacts
• Artifact Attestation -same as Signing but more simple and flexible

2. how does the artifact attestation related to
   https://github.com/in-toto/attestation/tree/main/spec/predicates

[phillmv]

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,

[C0D3-M4513R]

I love what I'm seeing, but unfortunately after testing it a bit (C0D3-M4513R/time#3) I ran into one show stopper:

• Action has stopped working, fails to download syft anchore/sbom-action#472 which seems to be caused by Curl returns 000 http status codes on successful download actions/runner-images#10009

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

[phillmv]

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

[C0D3-M4513R]

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

[djahandarie]

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 gh attestation verify?

[phillmv]

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.

[stdedos]

My build process generates a lot of artifacts: https://github.com/stdedos/junit2html/actions/runs/10125546240

1. As someone might want to download the file and start using the product, they are all packaged with the same name junit2html, and with the version name appended (to avoid duplicates e.g. if someone wants to keep different versions around).
   However, that leads to not being able to find "the correct" attestation, unless someone starts "reverse": sha256 the result, find the correct link, and download the correct attestation. Is there a way to improve this, apart from fully-appending the filenames?
2. It seems to be a bit "excessive" that each artifact generates a separate json. Can they be somehow consolidated into one file? Or am I using the action wrong?

I may not be understanding attestations at all, so be nice 🙏

[chrispat]

https://github.com/orgs/community/discussions/122028#discussioncomment-11126236

[bdehamer]

@stdedos the latest release introduces support for multi-subject attestations: https://github.com/actions/attest-build-provenance/releases/tag/v2.0.0

[pmartu12]

is it possible set a rule in order to create attestation only from protected branch?

[v1v]

Is it possible to list all the attestations for a given GitHub repository or GitHub Org using the Rest API?

[AptiviCEO]

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?

[v1v]

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

[hfhbd]

We generate about 100 attestations per release. The attestation view https://github.com/ORG/REPO/attestations lists all attestations. Are there any plans to group the attestations per tag or similar?

[bdehamer]

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.

[bdehamer]

The latest release introduces support for multi-subject attestations: https://github.com/actions/attest-build-provenance/releases/tag/v2.0.0

[tinaheidinger]

@hfhbd we're currently working on revamping the attestations UI. Did the new "multi-subject attestations" feature solve your problem, or are you still looking for better filtering capabilities?

[j-m]

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

Error: Failed to persist attestation: Feature not available for user-owned private repositories. To enable this feature, please make this repository public.

[bdehamer]

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.

[Andy-commits-lgtm]

Гей, ви всі! Я радий повідомити, що атестації артефактів GitHub знаходяться в публічній бета-версії🎉

❓ Що це означає❓

Атестації артефактів дозволяють супроводжувачам проекту без особливих зусиль створювати захищений від підробки паперовий слід, що пов’язує їх програмне забезпечення з процесом, який його створив. Далі споживачі цих метаданих можуть використовувати їх як основу для нових перевірок безпеки та дійсності за допомогою оцінки політики за допомогою таких інструментів, як Rego та Cue . Ми починаємо з підтримки перевірки на основі GitHub CLI , але пізніше цього року розширимо, щоб перенести ті самі елементи керування в екосистему Kubernetes.

📑 Хочете дізнатися більше? Ось деякі ресурси:

• Звідки насправді походить ваше програмне забезпечення щодо атестації програмного забезпечення
• Наша публікація в блозі блозі з оглядом нових можливостей
• У документах ви знайдете всі подробиці про те, як працюють правила репозиторію.

❔ Ще є запитання❔

• Не соромтеся опублікувати тут, щоб отримати відгук.

[Zastai]

Any particular reason that there is no means of removing attestations?
I have a few generated from the PR that enabled the feature that are of no use to anyone, but it looks like they are going to be there forever.

And there may be occasions where you specifically want a binary not to pass an attestation check (e.g. when delisting a package).

[tinaheidinger]

Thank you for your feedback! This is currently being worked on. We plan to add capabilities to delete and bulk manage attestations soon.

[pracan]

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 cosign

It's not really a major problem but it doesn't feel very clear, like here's an exemple :

• Working with cosign and ghcr :

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

• Working with cosign and GitLab :

# 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 sigstore/cosign or by providing a API end-point that is serving "not bundled" certificates (via an URI or URL).

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 ?" : here, here, here and here

Maybe this is more of a cosign problem but i think ghcr could benefit from improving this point

2. "https://slsa.dev/provenance/v1 page" is an interesting summary tool but you can't query it

A quick comparison to highlight my problem (i'm using a public repo) :

• Let's retrieve an attestation from Rekor :

DIGEST=sha256:430c92bcf730bb1280980b1e0c721d92a58de1616a74766189b8a35cd76672b2

#Then you can find this image attestation at :

https://search.sigstore.dev/?hash=sha256:430c92bcf730bb1280980b1e0c721d92a58de1616a74766189b8a35cd76672b2

• Let's retrieve an attestation from GitHub :

#First you have to go here :

https://github.com/pracan/docker-like-name-generator/attestations

#and manually guess which UID is it linked to 

#here the lucky number was #4374308
https://github.com/pracan/docker-like-name-generator/attestations/4374308

I think it's very important to add a /?hash= query endpoint because without ease of access the "https://slsa.dev/provenance/v1 page" isn't really going to get adopted. Which would be a shame as it provides a pretty well made summary (which is better than Rekor's) and a good information hub with links to the commit, github actions build, container image and workflow file.

Ps : Why are all my artefacts named "https://slsa.dev/provenance/v1" in my https://github.com/user/repo-name/attestations page ?

3. Weird "is it public/login-only ?" experience

This 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 github.com part :

• https://github.com/pracan/docker-like-name-generator/attestations is fully public (don't require a login)
• https://github.com/pracan/docker-like-name-generator/attestations/4374308 is fully public (don't require a login)
• https://github.com/pracan/docker-like-name-generator/actions/runs/12751830241/attempts/1 is half-public (some of it infos require a login, like the attestation that is actually publicly available at the url linked above)
• https://github.com/pracan/docker-like-name-generator/pkgs/container/docker-like-name-generator is fully public (don't require a login)

On the https://ghcr.io/ part :

• https://ghcr.io/v2/pracan/docker-like-name-generator/tags/list is login only but the link above which arguably provides the same function is fully public
• https://ghcr.io/token/?scope\="repository:pracan/docker-like-name-generator:pull" returns error 404 (so you can't ask for a token without github account)

On the GitHub-CLI part :

• everything needs a login even the attestation verification (but you can use a tool like Regctl or Crane and interact with ghcr without a login)

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 :

• these links are meant to be shared to/used by your artifacts consumers
• these links are not

[phillmv]

Thanks for this great and detailed feedback, I'll pass it along and we'll take it into consideration.

Re: cosign, we are currently engaged in a long running set of contributions back to sigstore/cosign. The awkwardness you're experiencing comes from it taking a while for changes to the bundle format we introduced to percolate / land / etc in the ecosystem.

(Also, I believe verify-attestation is doing something very different from verify-blob-attestation; you really do need to specify an OIDC Issuer and a SAN value in order to be able to trust the artifact)

How can my end-users verify my artifact if they're not using gh-cli

Just an FYI, if the artifact was signed using a private repository you need access to GitHub's TUF repository. The intended paved path really is "please use gh" 😅 .

I think it's very important to add a /?hash= query endpoint

👍

Re: public vs non public links, you've nailed it - some of it has to do with bot protection & rate limiting. We'll think about how to open things up.

Again, thank you!

[MShekow]

Thanks for providing attestations. I particularly love the fact that we can now easily cryptographically sign files (e.g. binaries) uploaded to GitHub releases.

However, the whole effort is only worth it if more projects adopt it. And the best motivation to adopt it is to make it also very easy for the consumers of GH release artifacts to verify their attestations. I have a few thoughts about this:

• Don't require authentication: Like others mentioned in this thread, I don't understand why you require authentication for the attestation API endpoint, even when targeting public repos. This makes it harder to verify downloaded binaries. Suppose I am building a container image: I have to pass a GitHub PAT to my image builder, just so I can run gh attestation verify ...
• Simplify getting a verified gh CLI: While hosted runners come with gh pre-installed (and I "trust" that this CLI's signature is verified in your managed runner images...), people do not always have gh available. Think of self-hosted runners (where it is not preinstalled), or container builds. If you really wanted to make it as simple as possible, you could offer UNIX and Windows installation scripts that work in any environment (any Linux distro or container image), downloading gh, and verifying it, e.g. using a "bootstrapping approach" as done by cosign. You could also offer an official setup-action for the gh CLI (for self-hosted runners), which could use the proposed script.
  • To make consuming verified binaries even easier, you could offer an official action that downloads and verifies release files from public GitHub projects (similar to https://github.com/robinraju/release-downloader)
• Improve the documentation:
  • Include more information about the options for automatic verification of files. E.g., verification of binaries you curl'd in a container build.
  • Explain the why of doing attestations. With so many tools in this area, the docs feel like "written by security experts, for security experts". But you should assume that the reader is not an expert at all. You could provide at least some background on how attestations improve the supply chain security in practice. This could be as short as a reference to https://slsa.dev/spec/v1.0/images/supply-chain-threats.svg and stating that it mitigates F+G.

[katty115]

สวัสดีทุกคน! ฉันตื่นเต้นที่จะประกาศว่า GitHub Artifact Attestations อยู่ในเวอร์ชันเบต้าสาธารณะแล้ว 🎉

❓ นี่หมายถึงอะไร❓

การรับรองสิ่งประดิษฐ์ช่วยให้ผู้ดูแลโครงการสามารถสร้างเอกสารหลักฐานที่ป้องกันการปลอมแปลงและไม่สามารถปลอมแปลงได้โดยง่าย โดยเชื่อมโยงซอฟต์แวร์ของตนกับกระบวนการที่สร้างซอฟต์แวร์ขึ้นมา ผู้บริโภคปลายทางของข้อมูลเมตาดังกล่าวสามารถใช้ข้อมูลดังกล่าวเป็นพื้นฐานสำหรับการตรวจสอบความปลอดภัยและความถูกต้องใหม่ ๆ ผ่านการประเมินนโยบายผ่านเครื่องมือเช่นRegoและCueเรากำลังเริ่มต้นด้วยการสนับสนุนการตรวจสอบตามGitHub CLIแต่จะขยายเพื่อนำการควบคุมเดียวกันนี้ไปสู่ระบบนิเวศ Kubernetes ด้วยเช่นกันในช่วงปลายปีนี้

📑 ต้องการเรียนรู้เพิ่มเติมหรือไม่? นี่คือแหล่งข้อมูลบางส่วน:

• ซอฟต์แวร์ของคุณมาจากไหนกันแน่เกี่ยวกับการรับรองซอฟต์แวร์
• โพสต์บล็อกของเราพร้อมภาพรวมของความสามารถใหม่
• เอกสารดังกล่าวจะให้รายละเอียดทั้งหมดเกี่ยวกับวิธีการทำงานของกฎที่เก็บข้อมูล

❔ ยังมีข้อสงสัย❔

• โปรดอย่าลังเลที่จะโพสต์ที่นี่เพื่อรับคำติชม