feat: sign uds core zarf packages - #2945
Conversation
|
@greptileai @codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Greptile SummaryThis PR adds keyless signing and verification for standard and functional-layer UDS Core Zarf packages and restructures releases around tag-based provenance.
Confidence Score: 5/5The PR appears safe to merge, with no outstanding correctness or repository-rule findings. The previously reported signer regex is now fully anchored, release-branch creation again waits for successful publication and checkpointing, and the projected package-version concern was explicitly accepted and conceded in its resolved thread. The latest environment and credential-name changes are internally consistent with the ADR. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Push to main or release branch] --> B[Release Please]
B --> C[GitHub App creates semver tag]
C --> D[Tag triggers release.yaml]
D --> E[Build and validate packages]
E --> F[Keyless sign packages]
F --> G[Verify OIDC identity]
G --> H[Publish packages]
H --> I[Run checkpoint]
I --> J{Minor release tag?}
J -->|Yes| K[Create release/X.Y branch]
J -->|No| L[Release complete]
Reviews (6): Last reviewed commit: "chore: align github env and secret names" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f78a378ab
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@greptileai @codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf65e43f45
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@greptileai @codex review |
| - name: Create GitHub App token | ||
| id: app-token | ||
| uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0 | ||
| with: | ||
| app-id: ${{ secrets.UDS_RELEASE_PLEASE_APP_ID }} | ||
| private-key: ${{ secrets.UDS_RELEASE_PLEASE_APP_PRIVATE_KEY }} |
There was a problem hiding this comment.
Tracking the need to use an app here so that tag triggered workflows kick off, but this also has the side effect of automatically triggering the workflows on the release PR. That's probably not desirable since those run lengthy CI including IaC tests (and would get run/re-run on every commit to main)?
Likely could add some sort of label/other mechanism gate on the PR before running other checks...
There was a problem hiding this comment.
Yeah this is a very good callout here... I think i found a way with release please to create the PRs with a github token but do the actual tagging with the github app token. Essentially skip creating the pull request when running with the github app token, and then create the pull request with the github token. Two different steps. I pushed up these changes to show what that would look like.
| Release package verification will use this certificate identity regex: | ||
|
|
||
| ```text | ||
| ^https://github\.com/defenseunicorns/uds-core/\.github/workflows/publish\.yaml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$ |
There was a problem hiding this comment.
The one thing we might want to look into as well is adding a renovate for these strings to lock them version to version so that when a consumer updates core it updates these versions as well - that way we have more specificity with what we expect ideally mostly "for free".
There was a problem hiding this comment.
yea totally agree. i updated the adr to call out what the exact match could look like and call out that these strings can be updated with something like renovate. it would be very easy for us to have a standard rule in uds-common once we start signing packages: fc3342d
|
@greptileai @codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fc3342d730
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@greptileai review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fa3f75a420
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
3 participants
Description
Implements signing of UDS Core zarf packages (standard and functional layers). This uses a keyless signature with GitHub's token as agreed upon in: https://app.notion.com/p/defense-unicorns/UDS-Package-Signing-38ee512f24fc8026aa5fdc81b38d1e0e?source=copy_link.
In order to implement tag based provenance like zarf, we will need to update our release workflows to be triggered on a tag push instead of a merge to main. This has some consequences:
Note: Downstream consumers will need to update their package references to include the keyless verification spec or decide to skip package signature with UDS CLI.
Related Issue
Fixes CORE-41
Type of change
Checklist before merging