New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh attestation verify fails with a reusable workflow. #9045
Comments
Thanks for filing this issue ❤ Actually I think it works as expected, but there are a some improvements we can do here from our side, both on the documentation and the error messages. The reason it fails now is because the artifact comes from one repo, but it's signed with a (reusable) workflow from another repo (which is also in another org, but it doesn't really matter). This is because the reusable workflow is where the build provenance attestation is created. So even if we can assure that the artifact comes from the repo you specified, the identity of the signer is not known/trusted. That is why the extra parameter is needed. The regex version can also be used here: gh attestation verify ghcr-reaper_0.0.1_linux_amd64.deb \
--repo thepwagner/ghcr-reaper \
--cert-identity-regex 'https://github.com/thepwagner-org/actions/.github/workflows/golang-release-attest.yaml.*' If the repo the artifact originates from and the signer is identical, we trust the signer and so no extra parameter is needed. |
Understood, a different error message will help. FWIW, that model surprised me. My assumption was the Specifically I expected (Bias: everything I've written prefers verifying the extensions to the SAN, if there's a good reason to prefer the SAN I'd like to learn!) |
Yes, there are some options to chose from (different extensions). One of the reason to not trust the value in the extension in your example is that the identity of the issuer (SAN) is not known. So even if the extension's value matches your, how can you trust it when the signer is unknown? The reusable workflow may perform arbitrary actions prior or during the build. So the answer is sort of yes to both. The extension's values are where the data should be sourced from, but only if we trust the signer. Makes sense? |
oh, hey @thepwagner! This turned out to be a good test case. Thanks for kicking the tires. |
v2.49.1 includes documentation when invoking |
Closing this as documentation for this use case has been added in v2.49.1. |
Describe the bug
The
attestation verify
feature matches the certificate SAN against the repository name. When the workflow uses aworkflow_call
/reusable worfklow, the SAN is the workflow name, which is not necessarily the same as the repository name.This causes verifying artifacts produced by the target repository to fail.
Steps to reproduce the behavior
Example artifacts: https://github.com/thepwagner/ghcr-reaper/releases/tag/v0.0.1 from this workflow https://github.com/thepwagner/ghcr-reaper/blob/v0.0.1/.github/workflows/release.yaml
Expected vs actual behavior / Logs
I expect the provided examples to work:
I can workaround by passing the workflow reference as an additional argument, but that's not expected:
Related
The text was updated successfully, but these errors were encountered: