Distillation

Date: Aug 29, 2026

• 🟡 [requested-security-review] (13:09) User requested a read-only, substantive security review of the current working tree’s release approval gate; explicitly requested no edits. Scope: privilege boundaries, GitHub token identities, workflow expression/shell hazards, TOCTOU races, forged labels/comments/events, API failure paths, cleanup, and auto-approve provenance.
• 🟡 (13:09) User specified review targets: .github/workflows/publish.yml, .github/workflows/ci-poller.yml, src/modules/approval-attestation.js, src/modules/approval-authorizer.js, src/publish/authorize-approval.js, src/publish/current-accepted-event.js, src/publish/record-ci-ready-attestation.js, src/publish/validate-approval-attestation.js, and tests.
• 🔴 [requested-report-format] (13:09) User required a substantive report with file:line evidence; every finding classified PASS, CONCERN, or MUST-FIX; report must end exactly MERGE or DO-NOT-MERGE; user prohibited an empty response.
• 🟡 (13:10) Test files identified: /home/byk/Code/getsentry/publish/src/publish/__tests__/validate-approval-attestation.js, /home/byk/Code/getsentry/publish/src/publish/__tests__/authorize-approval.js, /home/byk/Code/getsentry/publish/src/modules/__tests__/approval-attestation.js, /home/byk/Code/getsentry/publish/src/modules/__tests__/approval-authorizer.js, /home/byk/Code/getsentry/publish/src/publish/__tests__/current-accepted-event.js, and /home/byk/Code/getsentry/publish/src/publish/__tests__/record-ci-ready-attestation.js.
• 🟡 (13:10) .github/workflows/publish.yml triggers on issues labeled events; concurrency group is ${{ github.event.issue.title }} with cancel-in-progress: false; default permissions are contents: read, issues: write, and packages: write.
• 🟡 (13:10) In .github/workflows/publish.yml:26-167, waiting-for-ci runs in environment: production only when the added label is accepted, the issue is open, and title begins publish: ; it checks out with actions/checkout@v6 and persist-credentials: false.
• 🟡 (13:10) .github/workflows/publish.yml:40-67 creates a sentry-internal-app token via actions/create-github-app-token@v3 using vars.SENTRY_INTERNAL_APP_ID and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY; independently attempts a Release Bot token using vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, and owner: getsentry, with continue-on-error: true; authorize-approval.js receives APPROVAL_TOKEN, APPROVAL_ACTOR: ${{ github.actor }}, issue number, repository, and title.
• 🟡 (13:10) .github/workflows/publish.yml:69-91 records the authorization output as an issue comment using GH_TOKEN: ${{ github.token }}, then validates it using validate-approval-attestation.js with APPROVAL_TOKEN: ${{ github.token }} and APPROVAL_ATTESTATION_AUTHOR: github-actions[bot]; validation has continue-on-error: true.
• 🟡 (13:10) .github/workflows/publish.yml:93-111 removes accepted, posts “Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.”, and exits 1 whenever authorization, attestation creation, or approval-attestation validation does not succeed.
• 🟡 (13:10) .github/workflows/publish.yml:113-129 resets an accepted release to ci-pending by removing ci-failed and ci-ready and adding ci-pending; comments say the ci-ready removal allows the poller’s later --add-label to generate a new labeled event after retries.
• 🟡 (13:10) .github/workflows/publish.yml:144-167 best-effort creates a CI poller App token using vars.CI_POLLER_APP_CLIENT_ID and secrets.CI_POLLER_APP_PRIVATE_KEY, sets repository variable CI_POLLER_HAS_PENDING to "true" if token creation succeeds, and invokes gh workflow run ci-poller.yml using the internal App token because GITHUB_TOKEN-originated workflow_dispatch events are suppressed.
• 🟡 (13:10) .github/workflows/publish.yml:169-206 publishes only on an open-issue ci-ready labeled event where labels include accepted and ci-ready, and exclude ci-pending and ci-failed; it validates the approval attestation again with REQUIRE_CI_READY_ATTESTATION: "true".
• 🟡 (13:10) .github/workflows/publish.yml:208-219 removes accepted, comments the invalid-approval message, and exits 1 if publish-time approval-attestation validation fails.
• 🟡 (13:10) .github/workflows/publish.yml:245-281 conditionally takes Craft config from protected target branches for exact repo/branch pairs: sentry-migr8/tmp-merge-target; sentry-javascript/v10, v9, v8, v7, or master; sentry-python/alpha; and sentry-wizard/1.x; it creates an all-getsentry Release Bot App token and checks out getsentry/${{ fromJSON(steps.inputs.outputs.result).repo }} at the conditional target branch or default branch with fetch-depth: 0.
• 🟡 (13:10) .github/workflows/publish.yml:283-325 uses JSON-derived CRAFT_PUBLISH_REPO, CRAFT_PUBLISH_PATH, CRAFT_PUBLISH_VERSION, and CRAFT_PUBLISH_TARGETS_JSON; computes a SHA-1 12-character hash of Craft’s canonical container cwd; sanitizes owner/repo/version; and writes the publish state file under $GITHUB_WORKSPACE/.craft-state/craft, outside __repo__/, to prevent repository contents pre-populating Craft state.
• 🟡 (13:10) .github/workflows/publish.yml:327-381 runs docker://getsentry/craft:latest with /bin/bash -e -c, changes directory using ${{ fromJSON(steps.inputs.outputs.result).path }}, and runs craft publish ${{ fromJSON(steps.inputs.outputs.result).version }}. It exposes the Release Bot token as GITHUB_TOKEN and GITHUB_API_TOKEN, GitHub Packages credentials via secrets.GITHUB_TOKEN, plus publishing/deployment secrets including CLOUDFLARE_API_TOKEN, COCOAPODS_TRUNK_TOKEN, CRAFT_GCS_TARGET_CREDS_JSON, CRAFT_GCS_STORE_CREDS_JSON, CRATES_IO_TOKEN, DOCKER_PASSWORD, HEX_API_KEY, TWINE_PASSWORD, NPM_TOKEN, GEM_HOST_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, NUGET_API_TOKEN, POWERSHELL_API_KEY, GPG_PRIVATE_KEY, GPG_PASSPHRASE, OSSRH_USERNAME, OSSRH_PASSWORD, PUBDEV_ACCESS_TOKEN, PUBDEV_REFRESH_TOKEN, and VERCEL_TOKEN.
• 🟡 (13:10) .github/workflows/publish.yml:383-409 invokes update-issue.js on cancellation or failure, posts cancellation/failure results via post-result.js, and closes/posts success via post-result.js success; these use PUBLISH_ARGS: ${{ steps.inputs.outputs.result }} and GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}.
• 🔴 (13:10) User stated the CI poller always allows workflow_dispatch for manual recovery.
• 🔴 (13:10) User stated the CI poller always adds ci-ready after checking CI.
• 🔴 (13:10) User stated a release must never move to ci-ready after it changes.
• 🔴 (13:10) User stated that a renamed or re-approved issue never reaches ci-ready.
• 🟡 (13:10) Visible CI-poller workflow evidence indicates it only checks issues carrying both ci-pending and accepted; it validates approval before inspecting CI, uses Publish’s title parser to target CI and publishing consistently, revalidates approval before the ci-ready transition, records a CI-ready attestation, comments it, and then adds ci-ready.