Replies: 13 comments 19 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.
-
Another feature to lock down the users to a single platform? |
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.
-
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] |
Beta Was this translation helpful? Give feedback.
-
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.
-
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.
-
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.
-
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.
-
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.
-
The hosted runner: GitHub Actions 22 lost communication with the server. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error. |
Beta Was this translation helpful? Give feedback.
-
So I understand these 3 level of verification: Can the attestation replace the signing process in all aspects ( authenticity, digest validation etc)? |
Beta Was this translation helpful? Give feedback.
-
Приветствую, можете помочь разобраться .23:11, 31 мая 2024 г., Yaniv Paz ***@***.***>:
So I understand these 3 level of verification:
1.Digest
2. Singing
3. Attestation
Can the attestation replace the signing process ?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
-- Отправлено из мобильного приложения Яндекс Почты
|
Beta Was this translation helpful? Give feedback.
-
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