ci: enforce signed commits

[OmarMcAdam]

Summary

• sign automated repository/AUR commits with the OPENWORK_GH_AGENT GPG key
• add a pull_request_target workflow that closes PRs with unsigned commits
• use OPENWORK_GH_AGENT secrets for bot identity, token, and GPG material

Required secrets

• OPENWORK_GH_AGENT_NAME
• OPENWORK_GH_AGENT_EMAIL
• OPENWORK_GH_AGENT_TOKEN
• OPENWORK_GH_AGENT_GPG_PRIVATE_KEY
• OPENWORK_GH_AGENT_GPG_PASSPHRASE

Tests

• git diff --check
• ruby YAML parse for modified workflow files
• actionlint on modified workflows, if installed

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview, Comment	Jun 18, 2026 2:05pm
openwork-den	Ready	Preview, Comment	Jun 18, 2026 2:05pm
openwork-den-worker-proxy	Ready	Preview, Comment	Jun 18, 2026 2:05pm
openwork-landing	Ready	Preview, Comment, Open in v0	Jun 18, 2026 2:05pm

[cubic-dev-ai]

2 issues found across 4 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/release-macos-aarch64.yml">

<violation number="1" location=".github/workflows/release-macos-aarch64.yml:849">
P2: Third-party GitHub Action is pinned to a mutable tag instead of an immutable commit SHA. This introduces supply-chain risk in a privileged release job.</violation>
</file>

<file name=".github/workflows/aur-validate.yml">

<violation number="1" location=".github/workflows/aur-validate.yml:416">
P1: Third-party GitHub Action is pinned to a mutable tag instead of an immutable commit SHA. This creates supply-chain risk in the signing/publish job.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Third-party GitHub Action is pinned to a mutable tag instead of an immutable commit SHA. This creates supply-chain risk in the signing/publish job.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/aur-validate.yml, line 416:

<comment>Third-party GitHub Action is pinned to a mutable tag instead of an immutable commit SHA. This creates supply-chain risk in the signing/publish job.</comment>

<file context>
@@ -408,6 +411,18 @@ jobs:
 
+      - name: Import OpenWork GH Agent GPG key
+        if: env.PUSH_TO_AUR == 'true'
+        uses: crazy-max/ghaction-import-gpg@v6
+        with:
+          gpg_private_key: ${{ secrets.OPENWORK_GH_AGENT_GPG_PRIVATE_KEY }}
</file context>

[cubic-dev-ai]

P2: Third-party GitHub Action is pinned to a mutable tag instead of an immutable commit SHA. This introduces supply-chain risk in a privileged release job.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release-macos-aarch64.yml, line 849:

<comment>Third-party GitHub Action is pinned to a mutable tag instead of an immutable commit SHA. This introduces supply-chain risk in a privileged release job.</comment>

<file context>
@@ -835,12 +835,25 @@ jobs:
+          token: ${{ secrets.OPENWORK_GH_AGENT_TOKEN }}
+
+      - name: Import OpenWork GH Agent GPG key
+        uses: crazy-max/ghaction-import-gpg@v6
+        with:
+          gpg_private_key: ${{ secrets.OPENWORK_GH_AGENT_GPG_PRIVATE_KEY }}
</file context>

[Pablosinyores]

The pull_request_target trigger here is used safely — the job only calls the GitHub API (listCommits, createComment, pulls.update) and never checks out or runs PR-controlled code, so the usual pull_request_target code-injection risk does not apply.

One concern on the close behavior. The workflow runs on synchronize and reopened as well as opened, and closes the PR whenever any commit fails verification.verified. So a contributor who pushes a follow-up commit without signing, or force-pushes mid-review, gets the PR closed from under them even after a maintainer has started reviewing. Reopening works but it is a jarring loop.

Two options that keep the enforcement without the hostile UX:

• fail the check (core.setFailed) without pulls.update({ state: "closed" }), so branch protection blocks the merge but the PR stays open for the contributor to fix; or
• keep the close only for types: [opened, reopened] and just fail (not close) on synchronize.

Minor: verification.verified === true also covers SSH-signed and GitHub-web-UI commits, not only the GPG key imported in the release workflows here. That is probably the intent, just worth confirming that is the accepted signing surface.