Skip to content
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

Merged
merged 1 commit into from
Nov 18, 2024
Merged

ci: attest build only on push #50

merged 1 commit into from
Nov 18, 2024

Conversation

fmoessbauer
Copy link
Member

@fmoessbauer fmoessbauer commented Nov 18, 2024

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]

@@ -94,6 +94,7 @@ jobs:

- name: attest extension artifacts
uses: actions/attest-build-provenance@v1
if: github.ref == 'refs/heads/main'
Copy link
Collaborator

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?

Copy link
Member Author

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.

Copy link
Collaborator

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]>
@fmoessbauer fmoessbauer changed the title ci: attest build only on main ci: attest build only on push Nov 18, 2024
@fmoessbauer fmoessbauer merged commit 70d5f22 into main Nov 18, 2024
3 checks passed
@fmoessbauer fmoessbauer deleted the fm/ci-run-on-pr branch November 18, 2024 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants