A promotion decision can be signed for a SHA whose platform evidence never ran

[rldyourmnd]

Raised from macos-ubuntu-bootstrap, where the ordering is visible but not fixable. Filing here because release-promotion-gate.yml is the public verification point; the decision itself is made in the private control plane, so part of this is a question rather than a finding.

The ordering as it stands

release-promotion-gate.yml verifies that a numeric tag carries a signed, exact-SHA promotion decision. Publication then happens in release-supply-chain.yml. Both are read-after-the-fact: the tag already exists by the time either runs.

macos-ubuntu-bootstrap documents this in its own release.yml and accepts it deliberately:

A tag push still validates after the tag exists, and this repository cannot change that: root automation is the sole tag creator. What it can do is refuse to publish a release for a candidate whose gates are not green, which turns "immutable tag burned and release published" into "tag burned, release refused" — recoverable by bumping VERSION.

That is a reasonable mitigation for a repository that does not own tag creation. It is not a substitute for gating the decision.

Why it matters for this module specifically

Its strongest evidence — evidence-gate, 21 artifacts across macOS, Ubuntu 24.04 and 26.04, amd64 and arm64 — runs only on pull_request, because giving it a push: main trigger would hand a contributor's unreviewed head code the default-branch Actions cache scope (that was #75, closed by #77). So:

• evidence-gate never reports on main;
• the release lane recovers it indirectly, by proving the candidate's tree is identical to a PR head whose gate was green;
• that indirection depends on strict_required_status_checks_policy, and it is verified rather than assumed — but it is still reconstruction after the fact.

A candidate reachable on main through any path that did not produce evidence gets a burned tag and a refused release. The recovery is real but costs an immutable version number.

The question

Can the promotion record require, as a precondition of being signed, that the exact SHA carries a green evidence check — where "which check" is declared by the module rather than assumed by the control plane?

That would move the failure from after an immutable tag to before the decision, and it generalises: any module could declare the checks its promotion depends on.

What I could not verify

• The control plane is private. I have not read how a promotion record is produced, what it already requires, or whether an evidence precondition exists there under another name. If it does, close this.
• I did not observe a tag being created, so I cannot say what the current sequence is in practice — only what the public workflows can and cannot see.

Related

• Consumer-side context: fix(ci): make the declared controls equal the enforced ones macos-ubuntu-bootstrap#83 and the evidence-gate topology work tracked there.
• The module's .github/rulesets/README.md now records why evidence-gate cannot yet be a required context: it does not report for fork pull requests or for pull requests outside its path filter. Fixing that is a prerequisite on the module side before any of this becomes enforceable.

[rldyourmnd]

Read and understood; leaving this open, and not treating it as actionable here yet.

You have the ordering right: release-promotion-gate.yml and
release-supply-chain.yml are both read-after-the-fact, and the tag exists before
either runs. This repository cannot change that either — the same constraint you
document.

Two things that may change the shape of the question, both landed today:

1. The release path could not previously reach the promotion gate at all — it
   failed in preflight on missing capabilities (fixed in feat(catalog): make tier requirements data, and hold every caller to them #178, described on The release path has never been executable since the promotion gate landed #157). So
   the ordering you describe had never actually been exercised end to end. Any answer
   built on how it behaved before is built on a graph that never ran.
2. catalog/validation-tiers.yml now records what each tier needs and holds every
   caller to it, which makes "what did the gate actually verify, with what available to
   it" answerable from data rather than from reading YAML.

The part that is genuinely a control-plane decision — whether a promotion decision may
be signed for a SHA whose platform evidence has not run — I am not going to answer from
inside the public verification point. It belongs with #134 and #157. Happy to implement
whatever ordering is decided once the producer exists, since that is the first thing a
release meets now.