Distillation

Current State

• Date: Aug 27, 2026. Active task: implement and harden the getsentry/publish release-approval authorization gate for issue #9355, after the user requested research first (13:46), implementation continuation (14:27, 14:55), and identified the critical invariant at 16:19: authorization “never binds that title or repository to later stages.”
• Repository: /home/byk/Code/getsentry/publish; private RBAC source locally accessible at /home/byk/Code/getsentry/security-as-code.
• Current branch/worktree state before the latest hardening work:
  • Modified: .github/workflows/publish.yml; broad Prettier had also modified existing source files including src/libs/__tests__/github.js, src/libs/github.js, src/modules/post-workflow-details.js, src/modules/process-end-state.js, src/modules/update-issue.js, src/publish/inputs.js, src/publish/post-result.js, src/publish/post-workflow-details.js, and src/publish/update-issue.js.
  • Added/untracked authorization work: src/modules/approval-authorizer.js, src/modules/__tests__/approval-authorizer.js, src/publish/authorize-approval.js, src/publish/__tests__/authorize-approval.js.
  • At 16:28, hardening work added src/modules/approval-attestation.js and modified src/modules/details-from-context.js and src/modules/approval-authorizer.js; exact latest contents/worktree validation remain to be inspected.
• Current hardening plan/status at 16:28:
  1. “Map current approval workflow and test coverage against review findings” — in progress/high priority.
  2. “Implement immutable approval attestation and fail-closed authorization” — pending/high priority.
  3. “Harden workflow cleanup and polling against approval drift” — pending/high priority.
  4. “Add adversarial regression tests and validate changes” — pending/high priority.
  5. “Process final security review findings” — pending/high priority.
• Blocking DO-NOT-MERGE findings from independent reviews:
  1. Critical approval/title binding: approval checks the mutable issue title snapshot on the accepted event but the CI poller and publisher later consume the current issue title. An approver could approve release repo A, retitle to repo B, and publish repo B without authorization.
  2. High auto-approval provenance: auto-approve.yml adds accepted using the internal-app token, so the subsequent label-event actor is the app—not getsantry[bot]; existing bot exception cannot safely establish provenance.
  3. High cleanup failure paths: checkout/internal app token failures precede the only label-removal/rejection step; GitHub Actions implicit success() skips cleanup after an earlier failed step, potentially leaving accepted.
  4. High bot bypass: non-allowlisted getsantry[bot] must never fall through to a live permission lookup and be authorized due to a write/maintain/admin result.
  5. High grammar drift: authorization must share Publish’s exact title grammar from details-from-context.js, fail closed on unsupported titles, and avoid accepting titles that later publish parsing rejects.
• Chosen intended remediation at 16:19–16:31: create an internal-app attestation tied to the latest accepted event and exact validated title; identify automated approval from immutable issue-creator/event provenance plus internal-app identity; validate proof immediately before CI transition and again before publication; require a fresh approval after rename; ensure rejected authorization always removes accepted.
• User constraints/invariants:
  • workflow_dispatch must always be allowed for manual recovery (stated 13:54, 14:44, 16:20).
  • CI poller always re-adds ci-ready after passing CI, even when present; this intentional re-addition triggers the publish workflow after the waiting-for-ci race (stated 13:54, 14:29, 15:26, 16:28).
• Last confirmed validation before the new review-driven hardening:
  • vitest run passed at 15:38: 7 test files, 33 tests.
  • Targeted Prettier passed after formatting src/publish/__tests__/authorize-approval.js.
  • Full lint remains blocked only by existing unrelated .github/workflows/cocoapods-keepalive.yml:1:7 yml/plain-scalar: “Must use plain style scalar” (1 error, 0 warnings; potentially fixable with --fix).
• Do not poll or duplicate prior background review work; background tasks ses_fbc205116ffesmEG8SWfAbIqaj and ses_fbc2027dbfferQZUN0ETLQ4agz completed with findings at 15:55 and 16:19, respectively.

Key Decisions

• Issue #9355 objective: prevent anyone who merely has triage or greater access to public getsentry/publish from approving/retracting releases for arbitrary SDK repositories, while allowing contractors with appropriate access to their own target repositories to approve releases.
• Chosen authority: live GitHub effective target-repository permission checks, rather than exposing or checking out private getsentry/security-as-code from public getsentry/publish.
  • Rationale: keeps private RBAC configuration private; GitHub reflects current access; GitHub App collaborator permission endpoint is feasible with Metadata: read and target-repo installation access; effective role_name incorporates repository, team, organization, and enterprise grants.
  • Allowed effective roles: write, maintain, admin.
  • Rejected roles: triage, read, none, unknown/undefined, and custom "Elevated Bot".
  • API failure must fail closed.
• security-as-code remains the infrastructure authority for granting limited getsentry/publish access, but is not read by the public workflow. Its repository configuration establishes production repo access authoritatively for normal production repositories.
• Do not implement a second-person/self-approval restriction as part of #9355:
  • A review found that target-repository requesters with write/maintain/admin could self-apply accepted, and requested requester identity enforcement.
  • Assistant explicitly decided at 15:35 to preserve #9355’s policy: authorize maintainers by target-repository access, not a second-person requirement.
• Bot exception policy evolved:
  • Initial exception trusted getsantry[bot] (and initially sentry-release-bot[bot]) broadly.
  • Evidence from historical events confirmed getsantry[bot] is the actor for auto-approval label events in existing behavior, e.g. Aug 15, 2026 issue timeline.
  • Narrowed decision: only exact auto-approve-repos.txt entries, including monorepo release paths, may be auto-approved; default is no bot bypass.
  • Review found current label actor is actually the internal app because auto-approve uses its app token. The next implementation must establish trusted provenance via immutable event/creator/app attestation rather than assume github.actor == getsantry[bot].
• Support both existing Publish title forms:
  • Qualified: publish: getsentry/repo[/path]@version.
  • Legacy unqualified: publish: repo[/path]@version, explicitly mapped to getsentry/repo.
  • Use shared PUBLISH_TITLE_REGEX from src/modules/details-from-context.js, not a divergent authorizer regex.
• Workflow sequencing:
  • Authorization must gate the accepted path before ci-pending, so invalid approval cannot reach the poller.
  • waiting-for-ci removes any preexisting ci-ready, adds ci-pending, and the poller later adds ci-ready; the newly added label event starts publishing.
  • Publish is triggered on ci-ready, not accepted, to avoid the waiting-for-ci race.
  • Future hardened workflow must ensure dispatch remains available for manual recovery.
• Fail-safe cleanup requirement:
  • API errors in authorization should lead to label removal and job failure.
  • Release-bot token creation had been made continue-on-error: true so internal token cleanup could still occur.
  • Reviews found this is insufficient for checkout/internal-app-token failures; cleanup needs an architecture that runs after every pre-authorization failure and has viable credentials.

Technical Changes

• Issue/repository research:
  • Issue: https://github.com/getsentry/publish/issues/9355, open, title “Use `security-as-code` to gate approver validity,” created 2026-08-27T11:30:52Z, updated 2026-08-27T11:54:23Z, author/assignee BYK / Burak Yigit Kaya (databaseId 126780), no labels. BYK comment at 11:54:23Z: cc @aldy505 @timfish @stephanie-anderson (1 thumbs-up).
  • Repository package: publish v0.0.1, private, Node 24.0.0, Yarn 1.22.22; scripts test: vitest run, lint eslint src .github --ignore-pattern '!.github'.
• Existing relevant Publish behavior:
  • src/modules/details-from-context.js exports PUBLISH_TITLE_REGEX, parsing:

    /^publish: (?:getsentry\/)?(?<repo>[^/@]+)(?<path>\/[\w./-]+)?@(?<version>[\w.+-]+)$/
    

    It accepts legacy unqualified titles, maps path to "." + path, parses dry-run, merge target, and targets.
  • src/publish/inputs.js calls detailsFromContext.
  • src/publish/update-issue.js invokes src/modules/update-issue.js.
  • src/modules/process-end-state.js comments outcome, closes issue only on success, and reports Sentry session.
  • src/libs/github.js#getGitHubToken() throws Error('No "GITHUB_TOKEN" environment variable found. Please ensure the workflow is configured correctly') if missing.
• Existing workflow behavior:
  • .github/workflows/auto-approve.yml: issues: [opened]; only actor sentry-release-bot[bot] or getsantry[bot], title starts publish: ; sparse-checkouts auto-approve-repos.txt; creates sentry-internal-app token and executes gh issue edit "$ISSUE_URL" --add-label accepted when title-derived release path exactly matches allowlist.
  • .github/workflows/ci-poller.yml: scheduled */5 * * * *; allows workflow_dispatch input attempt default "0"; job gate permits workflow_dispatch; polls open issues labeled both ci-pending and accepted; uses release-bot token for target repository APIs; checks statuses/runs; on pass removes ci-pending, adds ci-ready, comments; on failure removes ci-pending/accepted, adds ci-failed, comments; self-dispatches up to 60 attempts. It currently parses the current issue title and thus is part of title-mutation vulnerability.
  • .github/workflows/publish.yml: waiting-for-ci runs on an open issue’s accepted label event and title beginning publish: ; publish job runs on an open issue’s ci-ready event only if labels have accepted/ci-ready and lack ci-pending/ci-failed.
• Initial authorization files created:
  • src/modules/approval-authorizer.js
  • src/modules/__tests__/approval-authorizer.js
  • src/publish/authorize-approval.js
  • src/publish/__tests__/authorize-approval.js
• Initial authorizer final-known pre-hardening behavior at 16:28:
  • Imports PUBLISH_TITLE_REGEX from details-from-context.js.
  • ALLOWED_ROLE_NAMES = new Set(["write", "maintain", "admin"]).
  • Maps parsed release to getsentry/<repo> and optional exact releasePath = repository + path.
  • getsantry[bot] authorizes only if releasePath exists in supplied auto-approve allowlist; must reject non-allowlisted bot without lookup.
  • Other actors call getPermission({ owner: "getsentry", repository: title.groups.repo, username: actor }).
  • Returns authorization based only on allowed role_name.
• Initial entrypoint final-known pre-hardening behavior at 16:28:
  • src/publish/authorize-approval.js reads auto-approve-repos.txt in getAutoApprovedRepositories(), producing a Set of nonblank lines.
  • Calls GitHub endpoint:

    https://api.github.com/repos/${encodeURIComponent(owner)}/${encodeURIComponent(repository)}/collaborators/${encodeURIComponent(username)}/permission
    

    Headers include Accept: application/vnd.github+json, Authorization: Bearer ${process.env.APPROVAL_TOKEN}, X-GitHub-Api-Version: 2026-03-10.
  • Non-OK response throws:

    Could not retrieve ${username}'s permission for ${owner}/${repository}: GitHub returned ${response.status}
    

  • Requires GITHUB_OUTPUT and APPROVAL_TOKEN; appends authorized=<boolean>\n; direct execution logs errors and sets process.exitCode = 1.
• Initial workflow authorization wiring pre-hardening:
  • Checkout: actions/checkout@v6, persist-credentials: false.
  • Internal token: actions/create-github-app-token@v3 using vars.SENTRY_INTERNAL_APP_ID and secrets.SENTRY_INTERNAL_APP_PRIVATE_KEY.
  • Release token: actions/create-github-app-token@v3, continue-on-error: true, vars.SENTRY_RELEASE_BOT_CLIENT_ID, secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY, owner: getsentry.
  • Run node src/publish/authorize-approval.js with continue-on-error: true, APPROVAL_TOKEN, APPROVAL_ACTOR, APPROVAL_ISSUE_TITLE.
  • Existing reject condition:

    steps.authorization.outcome != 'success' || steps.authorization.outputs.authorized != 'true'
    

    It removes accepted, comments that approvers need write/maintain/admin on target repository, exits 1.
  • This was corrected earlier to remove accepted after permission lookup errors, but remains vulnerable before authorization because early failures skip rejection.
• New hardening file at 16:28:
  • src/modules/approval-attestation.js added. It is intended to carry immutable proof of exact validated title/repository across the approval → poller → publisher flow. Its actual API/content must be inspected before continuing.
• Tests:
  • src/modules/__tests__/approval-authorizer.js covers allowed human role names, disallowed roles, malformed/non-getsentry titles, API error propagation, unqualified titles, auto-approved exact release path and path preservation.
  • At 16:28 it had a stale/incorrect expectation for a non-allowlisted getsantry[bot]: it expected getPermission to be called despite the desired strict rejection; fix this.
  • src/publish/__tests__/authorize-approval.js covers exact allowlist paths including getsentry/sentry-javascript and getsentry/objectstore/clients, successful contractor permission fetch/output, and 404 failure/no output.
  • Missing adversarial coverage identified by reviews: bot with write role but nonallowlisted release; parser grammar divergence; post-approval retitle/repository mutation; auto-approve’s app-token label actor; checkout/internal-token failure cleanup; attestation/event binding validation.
• Validation history:
  • 14:42 initial focused tests failed because module nonexistent: src/modules/__tests__/approval-authorizer.js:5 required ../approval-authorizer.js; Vitest v4.0.17: 1 failed file, 0 tests, code 1.
  • 15:07 focused test passed: 11 tests, one file.
  • 15:13 focused tests: 2 files, 14 tests passed.
  • 15:22 full: 7 files, 30 tests passed.
  • 15:24 focused: 2 files, 15 tests passed; full: 7 files, 31 tests passed.
  • 15:38 full: 7 files, 33 tests passed; duration 890 ms / total command 1.36 s.
  • Reviews independently confirmed yarn test passed at 15:55 and 16:19 with 33 tests.
• Formatting/lint:
  • A broad Prettier command at 15:13 formatted/reported style in 13 source files beyond the task; be careful to distinguish those broad changes from intentional gate changes.
  • Targeted Prettier passed at 15:15, 15:24, and after one test-file format correction at 15:38.
  • Full ESLint failure is preexisting and unrelated:

    .github/workflows/cocoapods-keepalive.yml  1:7  error  Must use plain style scalar  yml/plain-scalar
    

• security-as-code findings:
  • rbac/env/prod-github/repo/publish.yml: repo_slug: publish, tag: prod; write: [engineering], triage: [bots-write], admin: [releng].
  • rbac/env/prod-github/team/release-approvers.tf: GitHub team “Release Approvers,” parent engineering, description “People authorized to approve releases from the getsentry/publish repo”.
  • rbac/env/prod/team/engineering/release-approvers.tf: direct members: alex.jillard@sentry.io, alexander.weber@sentry.io, bruno@sentry.io, dgriesser@sentry.io, fpacifici@sentry.io, francesco.novy@sentry.io, hubert.deng@sentry.io, indragie.karunaratne@sentry.io, james.keane@sentry.io, jan.auer@sentry.io, matej.minar@sentry.io, michael.hoffmann@sentry.io, pierre.massat@sentry.io, stephanie.anderson@sentry.io, thomas.hu@sentry.io, trent.schmidt@sentry.io; subteam team-devinfra@sentry.io; owner chadwhitacre@sentry.io.
  • rbac/env/prod-github/repo/_collaborator.tf uses github_repository_collaborators authoritatively for production; role order admin=6, elevated_bot=5, maintain=4, write=3, triage=2, read=1; mapping write→push, triage→triage, read→pull, elevated_bot→Elevated Bot.
• GitHub collaborator endpoint research:
  • GET /repos/{owner}/{repo}/collaborators/{username}/permission accepts IAT and requires GitHub App Metadata: read, target repository installation access; Administration is not required.
  • Effective role_name is highest across repository/team/org/enterprise grants, matching desired live-access behavior.
  • Observed results included {"permission":"admin","role_name":"admin"}, {"permission":"read","role_name":"read"}, and relevant automation target lookup {"permission":"none","role_name":""}.
• auto-approve-repos.txt has 46 exact entries:
  1. getsentry/arroyo
  2. getsentry/auto-type-annotate
  3. getsentry/devenv
  4. getsentry/infra-event-notifier
  5. getsentry/jest-sentry-environment
  6. getsentry/json-schema-diff
  7. getsentry/js-source-scopes
  8. getsentry/objectstore/clients
  9. getsentry/ophio
  10. getsentry/pdb
  11. getsentry/pyo3-python-tracing-subscriber
  12. getsentry/pytest-sentry
  13. getsentry/relay/py
  14. getsentry/responses
  15. getsentry/rust-proguard
  16. getsentry/rust-sourcemap
  17. getsentry/rust-usage-accountant
  18. getsentry/script-runner
  19. getsentry/sentry-api-schema
  20. getsentry/sentry-forked-djangorestframework-stubs
  21. getsentry/sentry-forked-django-stubs
  22. getsentry/sentry-forked-jsonnet
  23. getsentry/sentry-infra-tools
  24. getsentry/sentry-kafka-management
  25. getsentry/sentry-kafka-schemas
  26. getsentry/sentry-protos
  27. getsentry/sentry-redis-tools
  28. getsentry/service-registry
  29. getsentry/skrooge
  30. getsentry/snuba-sdk
  31. getsentry/statsdproxy
  32. getsentry/status-page-list
  33. getsentry/streams/sentry_streams
  34. getsentry/symbolic
  35. getsentry/taskbroker/clients
  36. getsentry/usage-accountant
  37. getsentry/watto
  38. getsentry/sentry
  39. getsentry/snuba
  40. getsentry/vroom
  41. getsentry/relay
  42. getsentry/symbolicator
  43. getsentry/taskbroker
  44. getsentry/uptime-checker
  45. getsentry/launchpad
  46. getsentry/self-hosted.

Session Timeline

• 2026-08-27 13:46–13:52: User requested thorough research/feasibility before implementing issue #9355. Repository and core parsing/update/result files were mapped. details-from-context.js grammar and update-issue behavior were identified. .github/workflows had not yet been fully enumerated.
• 13:53–13:54: User confirmed local security-as-code checkout and stated two durable constraints: poller always adds ci-ready; workflow_dispatch must always be allowed. Auto-approve and CI poller workflows were deeply mapped, including tokens, label transitions, CI checks, retries, and manual recovery behavior.
• 13:55–14:11: Inspected security-as-code GitHub RBAC and collaborator API documentation. Established that production repo RBAC is Terraform-authoritative and that effective collaborator role can be queried via IAT Metadata: read. Found publish.yml permissions and Release Approvers team. Verified automation actor target role none.
• 14:13–14:15: Research complete. Recommended live GitHub target-repo permission checks, write|maintain|admin, with narrow trusted auto-approve compatibility handling; avoid private configuration exposure.
• 14:27–14:44: User requested implementation. Assistant planned fail-closed gate before CI polling and created first test file. Initial focused tests failed at 14:42 because approval-authorizer.js did not exist. User repeated manual dispatch constraint.
• 14:46–15:07: Created src/modules/approval-authorizer.js, wired .github/workflows/publish.yml, corrected token sequencing, added role/title/error tests. Focused test passed (11 tests). Full lint exposed only preexisting cocoapods-keepalive.yml:1:7.
• 15:11–15:27: Confirmed historical auto-approval label events came from getsantry[bot]; refactored workflow to invoke testable src/publish/authorize-approval.js; made API errors remove accepted; made release-token creation soft-fail; added legacy unqualified-title support after initial parser failure. Full tests passed at 31 tests. Documented workflow logic and API entrypoint.
• 15:35–15:39: First review flagged self-approval, broad bot bypass, and title-form concerns. Assistant retained target-access policy rather than second-person enforcement, narrowed bot exception to exact allowlist release paths, fixed initial allowlist implementation defects, and reached 33 passing tests. Two final independent reviews started.
• 15:55: Correctness review returned DO-NOT-MERGE: title mutation/repo swap critical issue, auto-approve actor provenance mismatch, bot fallback bypass, grammar drift, and early cleanup failures. Assistant committed to reconciling/fixing all.
• 16:19–16:31: Security review independently returned DO-NOT-MERGE, confirming title/repository is not bound across stages and cleanup/provenance weaknesses. User explicitly stated the binding problem. Assistant selected attestation-based design, added src/modules/approval-attestation.js, began modifying authorizer/parser, and planned binding checks before CI and publish plus adversarial tests. Work remains in progress.