-
Notifications
You must be signed in to change notification settings - Fork 9
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
ci: attest build only on push #50
Conversation
fc0d517
to
8a3dffc
Compare
.github/workflows/build.yml
Outdated
@@ -94,6 +94,7 @@ jobs: | |||
|
|||
- name: attest extension artifacts | |||
uses: actions/attest-build-provenance@v1 | |||
if: github.ref == 'refs/heads/main' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will that help when run in forks? Shall it help in that case? Or what about making that dependent on the availability of the credentials at this stage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attesting in forks is fine, as the attestation contains data about WHAT and by WHICH workflow the artifact was generated. It's just that we can't attest from the https://github.com/siemens/linux-entra-sso/.github/workflows/build.yml@.*
when running on PRs from forks, as the secrets are not available in this context (for good reason!).
Or what about making that dependent on the availability of the credentials at this stage?
We could do this, but what's the advantage? We still have the situation that people from within the OU could create PRs that get attested without being reviewed by one of the maintainers. If the validation of the attestation is correctly implemented downstream, this imposes no risk, but we can easily avoid this attack vector by requiring that one of us maintainers had a look before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got the point about forks.
But that still leaves us with a rather imprecise filter: You want to filter out pull requests, but you use the branch name. Why not the trigger again?
When running the build for external PRs, we do not have access to secrets (for good reason). By that, we also cannot perform the attestation step. Just skip it in these cases. Signed-off-by: Felix Moessbauer <[email protected]>
8a3dffc
to
efc3ed3
Compare
When running the build for external PRs, we do not have access to secrets (for good reason). By that, we also cannot perform the attestation step. Just skip it in these cases.
Signed-off-by: Felix Moessbauer [email protected]