mirror of
https://github.com/headroomlabs-ai/headroom.git
synced 2026-08-27 14:17:10 -04:00
ac8646aa3c
## Description `RELEASE_PLEASE_TOKEN` is currently a maintainer's personal PAT. It bypasses branch and tag protection on `main` (`release-please.yml` says so in its own comment), and forging a tag with it fires `release.yml` and `docker.yml` on `release: published`, which publish to PyPI, npm and GHCR. If it is a classic token with `repo` scope it is also valid against every other repository that account can reach. `release-metadata-sync.yml` made that credential readable on the runner. `actions/checkout` defaults to `persist-credentials: true`, writing the token into `.git/config`, and the very next step runs `scripts/version-sync.py` **from the checked-out branch**. The trigger is a push to the glob `release-please--branches--**`, which is not a protected namespace, so a principal with push access could land a modified `version-sync.py` and read it. Closes #2955. ## Type of Change - [x] Bug fix (non-breaking change that fixes an issue) - [ ] New feature (non-breaking change that adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Changes Made - Both release workflows now prefer a GitHub App installation token — scoped to this repository, expiring in an hour — over the PAT, via `actions/create-github-app-token@v3`. - The minting step is gated on `vars.RELEASE_APP_ID` and marked `continue-on-error`, so an unconfigured app falls through to the existing `PAT -> GITHUB_TOKEN` chain and nothing breaks today. - `release-metadata-sync.yml`'s checkout no longer persists credentials, and no longer receives a token at all. - The final push supplies the credential through the step's own `env` and an explicit remote URL, so it is never on disk while branch-supplied code runs. ## Testing - [x] Unit tests pass - [x] Linting passes (ruff check + format on the test file) - [ ] Type checking passes — N/A (YAML + test only) - [x] New tests added for new functionality ### Test Output ```text $ .venv/bin/python -m pytest tests/test_release_workflows.py -q 1 failed, 44 passed, 1 skipped in 0.23s ``` The single failure is `test_no_native_tls_in_wheel_build_tree`, which shells out to `cargo`. It reproduces identically on unmodified `main` on this machine (no Rust toolchain installed) and is unrelated to this change. New tests only: ```text $ .venv/bin/python -m pytest tests/test_release_workflows.py -q -k "persist_credentials or scoped_app_token" 3 passed, 46 deselected in 0.18s ``` Against the parent commit: ```text FAILED test_metadata_sync_does_not_persist_credentials_for_branch_supplied_code FAILED test_release_workflows_prefer_scoped_app_token[release-please.yml-release-please] FAILED test_release_workflows_prefer_scoped_app_token[release-metadata-sync.yml-sync] 3 failed, 46 deselected ``` ## Real Behavior Proof - Environment: macOS 15 (darwin 25.4.0), Python 3.12.13; workflows parsed with PyYAML, not executed on a runner. - Exact command / steps: parse both workflow files and assert (a) every `actions/checkout` step sets `persist-credentials: false` and receives no `token`, (b) exactly one gated `create-github-app-token` step exists per workflow, and (c) every credential consumer places `steps.app-token.outputs.token` ahead of `secrets.RELEASE_PLEASE_TOKEN` in its fallback chain. - Observed result: all three assertions pass on this branch and fail on the parent commit. Both files remain valid YAML. - **Not tested — important:** none of this has executed on a GitHub runner. I have not minted a real installation token, not confirmed the app-token step's `continue-on-error` fallback behaves as expected when `vars.RELEASE_APP_ID` is unset, and not performed a real push with the explicit-remote-URL form. The first live release run is the real test. ## Runtime Rollout Safety - Rollout-managed feature(s): none. - Minimum rollout channel: N/A. - Stable/default behavior changed: no, unless `vars.RELEASE_APP_ID` is set — without it both workflows resolve to exactly today's credential chain. - Kill switch / disable path: unset `vars.RELEASE_APP_ID` to fall back to the PAT. - Unsafe override required: none. - Qualification impact: none. - Rollback path: revert this commit. ## Review Readiness - [x] I have performed a self-review - [x] This PR is ready for human review ## Checklist - [x] My code follows the project's style guidelines - [x] I have performed a self-review of my code - [x] I have commented my code, particularly in hard-to-understand areas - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective - [x] New and existing unit tests pass locally with my changes ## Additional Notes **This narrows blast radius; it does not make the trigger safe on its own.** For an `on: push` workflow GitHub reads the workflow file from the pushed ref, so a principal with push access can still edit this file on their branch. The durable fix is the scoped app token *plus revoking the personal PAT* — the revocation is a console action and is deliberately not in this commit. **Two repo settings are required to actually complete #2955**, and neither can land in git: ``` vars.RELEASE_APP_ID (repository variable) secrets.RELEASE_APP_PRIVATE_KEY (repository secret) ``` Until those exist this PR is a no-op on behavior and a defense-in-depth improvement on the `persist-credentials` path only. Co-authored-by: Tejas Chopra <tejas@Tejass-MacBook-Pro.local>
72 lines
3.2 KiB
YAML
72 lines
3.2 KiB
YAML
name: Release Please
|
|
|
|
# What this does
|
|
# ----------------
|
|
# release-please watches `main` for conventional-commit traffic and
|
|
# maintains a single "Release vX.Y.Z" PR that aggregates everything
|
|
# released since the last tag. Merging that PR is what triggers an
|
|
# actual PyPI / npm / GitHub-Release publish (via release.yml, which
|
|
# fires on the published-release event the bot emits at merge time).
|
|
#
|
|
# This replaces the prior "every push to main is a release" pattern
|
|
# that burned PyPI's per-project storage quota by uploading a fresh
|
|
# wheel matrix (~200 MB) for each merged `fix:` / `feat:` PR.
|
|
#
|
|
# Day-to-day:
|
|
# - Merge a `fix:` PR into main -> bot updates the release PR
|
|
# - Merge a `feat:` PR into main -> bot bumps minor in release PR
|
|
# - Merge `ci:` / `docs:` / `chore:` -> no PR change (hidden)
|
|
# - Ready to ship -> merge the release PR
|
|
# (bot tags + emits release event;
|
|
# release.yml does the actual builds + publishes)
|
|
#
|
|
# Config lives in `.release-please-config.json`; current versions
|
|
# tracked in `.release-please-manifest.json`.
|
|
|
|
on:
|
|
push:
|
|
branches: [main]
|
|
|
|
permissions:
|
|
contents: write
|
|
pull-requests: write
|
|
|
|
concurrency:
|
|
# Serialize bot runs on main so two pushes don't race the
|
|
# release-PR update. We never cancel mid-flight — losing a manifest
|
|
# write would mean the next push computes the wrong base version.
|
|
group: release-please-${{ github.ref }}
|
|
cancel-in-progress: false
|
|
|
|
jobs:
|
|
release-please:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
# Prefer a short-lived, repo-scoped GitHub App installation token. A
|
|
# personal PAT carries the maintainer's whole account — with a classic
|
|
# `repo` scope that reaches every other repository they can access — and
|
|
# this credential can tag past branch protection and reaches PyPI, npm and
|
|
# GHCR through the `release: published` publishes. An installation token is
|
|
# scoped to this repository and expires in an hour. Gated on the repo
|
|
# variable so an unconfigured app falls through instead of blocking a
|
|
# release. See #2955.
|
|
- name: Mint installation token
|
|
id: app-token
|
|
if: ${{ vars.RELEASE_APP_ID != '' }}
|
|
continue-on-error: true
|
|
uses: actions/create-github-app-token@v3
|
|
with:
|
|
app-id: ${{ vars.RELEASE_APP_ID }}
|
|
private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }}
|
|
|
|
- uses: googleapis/release-please-action@v5
|
|
with:
|
|
# Neither an app token nor a PAT is GITHUB_TOKEN, and that matters: a
|
|
# release/tag created by GITHUB_TOKEN does NOT emit events that trigger
|
|
# other workflows, so release.yml (PyPI/npm) and docker.yml — which fire
|
|
# on `release: published` — never ran, and releases had to be cut by
|
|
# hand. Falls back to GITHUB_TOKEN when nothing else is set (the release
|
|
# PR still opens; it just won't trigger the downstream publishes).
|
|
token: ${{ steps.app-token.outputs.token || secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}
|
|
config-file: .release-please-config.json
|
|
manifest-file: .release-please-manifest.json
|