Added commit signature verification with verified commit

[SpaceFace02]

Have tested with unverified commit

Summary by Sourcery

Enforce commit signature and authorship verification in all CI workflows before running tests, builds, and linting.

CI:

• Add a reusable commit verification workflow that checks PR commits are GPG/SMIME verified and authored by the PR owner.
• Wire the new commit verification job into Rust, Go, integration test, and lint GitHub Actions workflows as a prerequisite step.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: SpaceFace02

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sourcery-ai]

Reviewer's Guide

Adds a reusable commit verification workflow to enforce signed commits and matching authorship on PRs, and wires it into existing Rust, Go, integration-test, and lint GitHub Actions workflows as a prerequisite job.

Sequence diagram for commit signature and authorship verification

sequenceDiagram
    participant Workflow as Commit_Verification_Workflow
    participant Job as verify-commits_job
    participant GHCLI as gh_cli
    participant GitHubAPI as GitHub_API

    Workflow->>Job: start
    Job->>GHCLI: gh api repos/{repository}/pulls/{number}/commits
    GHCLI->>GitHubAPI: GET /repos/{repository}/pulls/{number}/commits
    GitHubAPI-->>GHCLI: commits list (verification, author)
    GHCLI-->>Job: commits JSON

    loop for each commit
        alt commit.verification.verified != true
            Job->>Job: print ::error::Commit is not signed
        else author.login != PR_AUTHOR
            Job->>Job: print ::error::Commit author does not match PR owner
        end
    end

    alt errors found
        Job->>Workflow: exit 1
    else no errors
        Job->>Workflow: echo All commits are signed and authored by PR owner
    end

Loading

File-Level Changes

Change	Details	Files
Introduce a reusable commit verification workflow that enforces signed commits and matching PR authorship for all PR commits.	Create a new GitHub Actions workflow that triggers on pull_request to main and via workflow_call Use the GitHub CLI to fetch all commits in the PR via the GitHub API Check each commit's verification status and emit GitHub Actions error annotations for unsigned commits, including the verification reason Validate that each commit's GitHub author login matches the PR owner and emit errors when they differ Fail the job if any errors were recorded; otherwise log a success message	.github/workflows/commit-verification.yml
Gate existing Rust CI jobs on successful commit verification.	Add a new verify-commits job that reuses the commit-verification workflow Declare tests-stable, tests-release-stable, tests-release-msrv, and tests-other-channels jobs as needing the verify-commits job	.github/workflows/rust.yml
Gate Go build CI on successful commit verification.	Add a verify-commits job that reuses the commit-verification workflow Configure the build job to depend on the verify-commits job	.github/workflows/go.yml
Gate integration tests on successful commit verification.	Add a verify-commits job that reuses the commit-verification workflow Configure the integration-tests job to depend on the verify-commits job	.github/workflows/integration-tests.yml
Gate linting CI on successful commit verification.	Add a verify-commits job that reuses the commit-verification workflow Configure the linting job to depend on the verify-commits job	.github/workflows/lint.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The reusable commit-verification.yml workflow relies on github.event.pull_request but is also invoked via workflow_call, which means it will break for non-PR triggers (e.g., push/schedule); consider passing PR metadata as inputs or guarding the job with if: github.event_name == 'pull_request' and avoiding direct github.event.pull_request access in the reusable workflow.
• By making all jobs needs: verify-commits, any non-PR runs of these workflows (e.g., direct pushes to main) will also depend on commit verification even though the PR context may not exist; if you want verification only for PRs, add an if: github.event_name == 'pull_request' on the verify-commits job in the caller workflows or split PR vs non-PR workflows.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The reusable `commit-verification.yml` workflow relies on `github.event.pull_request` but is also invoked via `workflow_call`, which means it will break for non-PR triggers (e.g., push/schedule); consider passing PR metadata as inputs or guarding the job with `if: github.event_name == 'pull_request'` and avoiding direct `github.event.pull_request` access in the reusable workflow.
- By making all jobs `needs: verify-commits`, any non-PR runs of these workflows (e.g., direct pushes to main) will also depend on commit verification even though the PR context may not exist; if you want verification only for PRs, add an `if: github.event_name == 'pull_request'` on the `verify-commits` job in the caller workflows or split PR vs non-PR workflows.

## Individual Comments

### Comment 1
<location path=".github/workflows/commit-verification.yml" line_range="11-12" />
<code_context>
+    branches:
+      - "main"
+  workflow_call:
+permissions:
+  contents: "read"
+
+jobs:
</code_context>
<issue_to_address>
**issue (bug_risk):** The workflow permissions likely need `pull-requests: read` for the `gh api` call to succeed on PR endpoints.

Because `permissions` is explicitly set, all unspecified scopes default to `none`, so the token used by `gh api` may lack access to the PR endpoint and start returning 403s. Please add:

```yaml
permissions:
  contents: read
  pull-requests: read
```

to ensure this workflow can read PR commits reliably.
</issue_to_address>

### Comment 2
<location path=".github/workflows/commit-verification.yml" line_range="25-34" />
<code_context>
+          PR_AUTHOR: ${{ github.event.pull_request.user.login }}
+        run: |
+          set -euo pipefail
+          errors=$(gh api "repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/commits" \
+             -q '
+              .[] | .sha[:12] as $s |
+              (if .commit.verification.verified != true
+               then "::error::Commit \($s) is not signed (\(.commit.verification.reason))"
+               else empty end),
+              (if (.author.login // "") != env.PR_AUTHOR
+               then "::error::Commit \($s) author (\(.author.login // "unknown")) does not match PR owner (\(env.PR_AUTHOR))"
+               else empty end)
+            ')
+          if [ -n "${errors}" ]; then
+            echo "${errors}"
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider failing fast on the `gh api` call itself to distinguish API errors from actual verification failures.

If the `gh api` call fails (network/permissions/invalid PR, etc.), `errors` stays empty and the job incorrectly reports success.

Add an explicit check on the `gh` exit status, e.g.:

```bash
if [ ${PIPESTATUS[0]} -ne 0 ]; then
  echo "::error::Failed to query PR commits via GitHub API"
  exit 1
fi
```

(or run the API call separately) so API/infrastructure failures cause the job to fail instead of silently passing verification.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Jakob-Naucke]

I gather you want the verification check to run before other tests, but is there a more unified way to order tests? (e.g. can we design this in a way that we won't forget the same gate when we add another test, or that we don't again need to edit 4 files if we want another test that goes before unit tests)

Then again, as long as GHA remains free for public repos, there isn't even a real incentive to do this itfp

[SpaceFace02]

Yeah, might not be needed because we aren't the ones paying for the GHA minutes anyways, but generally a good idea to try to preserve compute if we can as a community courtesy.

As these workflows are seperate files, GH doesn't yet have a way for like a global pre-check. There seems to be a way with Branch Protection Rules, although I can't comment on that

[Jakob-Naucke]

I'm kind of against this, not just because it makes the files fatter, but also because I saw now it runs per flow, so you get

• Commit Verification / Verify commit signatures and authorship
• Go / Build (pull_request)
• Go / verify-commits / Verify commit signatures and authorship (pull_request)
• Lint / Lints, pinned toolchain (pull_request)
• Lint / verify-commits / Verify commit signatures and authorship (pull_request)

etc.

e: so the "less compute time" argument is negated a bit anyhow

[SpaceFace02]

Yeah, it does run for each flow, although its relatively lightweight than running the jobs without gating, I think removing it is fine for now.

I am also open to closing this issue as the repo owner can configure both options(verify signatures and prevent merging until pipeline succeeds) from the Branch Protection Rules, although it will run on merge, not on a PR.

[SpaceFace02]

@alicefr What do you think?

[Jakob-Naucke]

Implemented by branch protection rules