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

Open
  • Is something wrong?
#2,294 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
10/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, git, github-actions, shell
Domain
ci-cd, release, security

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
C
Stars
3
Forks
7
Avg merge
6h 32m
Merged PRs (30d)
285

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InauguralSystems/EigenScript

All issues in InauguralSystems/EigenScript

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.