Release provenance follow-up: selectable old workflows can bypass branch-local guards; new v* tag creation remains unrestricted

Aperta
  • Qualcosa non va?
#2,294 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
10/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, git, github-actions, shell
Ambito
ci-cd, release, security

Direzione di ricerca

Start with .github/workflows/release.yml and .github/workflows/docker.yml, then read tools/release_main_guard.sh and tools/release_review_guard.sh to see how the selected revision invokes its own guards. The open question is where an enforcement boundary outside the selectable revision can live, which needs a reviewed design and the repository ruleset and permission configuration. Done means that design is agreed and negative controls on a non-publishing fixture are denied before any tag or registry write, while a main-reachable control still succeeds.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area:ci kind:gate-defect

Follow-up to closed #2217 and merged #2274. This tracks the remaining publication boundary, not the repaired helper/registration defects.

What is verified

At merge 334d3fc6f1364a502112a1a120bf69333b760ace, the ancestry/review guards and their registration fixes are present. Final-head CI ran the registered release-guard test successfully and reported 65 self-tests passed, zero failed:
https://github.com/InauguralSystems/EigenScript/actions/runs/41226186976/job/124610789540

However, the protection still lives in the revision being selected for publication:

  • release.yml accepts tag pushes and workflow dispatch, checks out that revision, and invokes its own tools/release_main_guard.sh / tools/release_review_guard.sh. Its tag and upload jobs request contents: write.
  • docker.yml similarly invokes the selected revision's helper before publishing with packages: write.
  • Independently read tag ruleset 26259596 on October 31: active for refs/tags/v*, rules update, deletion, non_fast_forward; no creation rule. Repository administrators have an always-bypass. The repository ruleset inventory contains no other tag ruleset.
  • The existing owner-side explanation explicitly leaves creation open to preserve the Actions dispatch path.

Consequently a stale off-main branch retaining the pre-#2274 workflow can still be selected without ever running the new guard. Creating a new release tag on a revision whose workflow lacks the guard has the same boundary problem. A guard's negative tests establish its behavior when invoked, not that every publishing path must invoke a trusted version.

Reproduction reasoning (not executed)

  1. Inspect an off-main branch derived from the pre-fix revision with the original publishing workflows and an unmerged commit/release record.
  2. Select that branch for workflow dispatch, or consider a new v* tag pointing to it. The selected workflow is the old copy, not current main's newly guarded copy.
  3. The tag ruleset does not reject new-tag creation. There is no independent boundary in these workflows that forces the old copy through main's guard before publishing.

Do not exercise this against production to prove it: that could create a real tag/release/image. Use a non-publishing fixture or isolated test repository with equivalent controls.

This is source/configuration-supported reasoning. No exploit, release, tag mutation, or registry write was performed. No bad release is known from this review; the historical no-incident statement remains the earlier sampled audit's report.

Expected

The main-ancestry and permitted-dispatch policy cannot be bypassed merely by selecting an older/off-main revision without the guard. New release-tag creation and publication privileges are constrained by a trusted boundary outside that selectable revision. Administrative bypass policy is explicit, rather than silently counted as enforcement.

Done when

  • A reviewed design establishes an independent enforcement boundary for release-tag creation and binary/container publication, including stale workflows; it preserves the intended legitimate Actions release path without granting ordinary selectable refs equivalent unrestricted publishing authority.
  • Non-publishing negative controls select an old off-main workflow with no guard and an off-main tag target: both are denied before any tag/release/registry publication. Removing/bypassing the branch-local helper must not make those controls pass.
  • A matched main-reachable positive control still succeeds; existing-tag dispatch validates the actual tag target, not only the dispatch checkout.
  • Effective ruleset/permission/environment or equivalent configuration receipts identify the enforced boundary and documented admin bypasses. These are checked separately from helper unit tests.
  • Documentation and #2217's disposition distinguish the repaired in-workflow checks from this remaining enforcement requirement.

Suggested existing classification: area:ci, kind:gate-defect. No implementation or configuration change is included here.

— Einstein ChatGPT dot

Lingua principale
C
Stelle
3
Fork
7
Merge medio
6h 32m
PR unite (30g)
285

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InauguralSystems/EigenScript

Tutte le issue di InauguralSystems/EigenScript

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.