Skip to content

release: fail closed unless protected-main required workflow evidence is proven #191

Description

@seonghobae

Buyer-visible release-assurance gap

The release-admission source repair is IMPLEMENTED ON PROTECTED MAIN, but this issue remains open for operational evidence.

Current protected identity and release state

Fresh exact state:

Before #192, .github/workflows/release.yml verified exact protected-main dispatch and reran repository-local quality/package checks but did not independently require the security/review evidence that made the integrated source eligible for release. That was unsafe because required workflow wrappers can look green while their semantic evidence is unavailable: Dependency Review can be skipped (#76 / read-only central .github#897), and Strix can report backend unavailable/no semantic report while its wrapper transport concludes successfully (#197 / read-only central .github#891).

#192 added a repository-owned read-only release-readiness verifier. It binds the release commit to exactly one integrating PR and exact source head, reads live protected-main rules, resolves required workflow source identities, requires exact-head workflow runs, independently checks review/thread requirements, inspects the actual Dependency Review step rather than trusting wrapper green, rejects unavailable/no-report Strix evidence, and gates tag/publication jobs behind that verification.

Later protected release-evidence hardening, including protected-main #199's required-workflow run-identity binding, strengthens this admission chain without converting missing semantic evidence into passing proof. Current Draft release-evidence work likewise remains unshipped until protected integration.

First failing boundary / RCA

  • Boundary: stable-release admission before tag creation and package publication.
  • Immediate historical cause: protected-main membership plus local quality/package reruns could authorize publication without independently proving merge-time security/review evidence.
  • Root cause: merge-time organization workflow evidence and release-time publication authority are separate channels; wrapper conclusions can conceal absent semantic evidence.
  • Systemic risk: a required-workflow false green, administrative integration, or provider-unavailable review could otherwise become a public artifact.
  • Current mitigation: protected-main release admission fails closed on absent/mismatched/non-semantic evidence. Merge-time central evidence defects remain separately owned by security: fail closed when dependency review is unavailable #76/security: fail closed when required Strix review is unavailable #197 and their read-only central repair lanes.

Distinct remedies

  1. Selected and protected-main implemented: repository-owned read-only exact-evidence verifier before any tag/package/publication authority.
  2. Re-run/copy organization security/reviewer workflows inside release: rejected because that creates competing evidence authorities.
  3. Infer readiness from aggregate check conclusions: rejected because security: fail closed when dependency review is unavailable #76/security: fail closed when required Strix review is unavailable #197 demonstrate wrapper-green/non-semantic evidence.
  4. Trust protected-main membership alone: rejected because it cannot detect bypass or evidence-channel false green.

Source implementation acceptance

  • Preserve test-first evidence for the missing explicit release-evidence admission boundary.
  • Make verification read-only, finite, exact-SHA-bound and pagination-aware.
  • Bind the protected-main commit to exactly one integrating PR and exact source head without transferring predecessor-head evidence.
  • Read the live organization-required workflow set applicable to protected main and keep semantic evidence separate from wrapper/status/model evidence.
  • Reject a Security Scan whose dependency-review wrapper succeeded while the immutable-pinned Dependency review action did not actually execute successfully.
  • Reject required Strix evidence whose backend is unavailable or produced no semantic report.
  • Prevent release/tag/package jobs from running unless the verifier succeeds.
  • Preserve least privilege, OIDC publication boundaries, immutable action pins, reproducible package evidence, rollback/recovery behavior and no secret-value logging.
  • Add deterministic positive/negative evidence-contract tests while preserving exact owned-production coverage and Python 3.10–3.14/package CI on the accepted source lineage.
  • Preserve the release-admission chain through current protected main and keep GitHub Releases empty while its semantic prerequisites are not satisfied.

Remaining operational acceptance

  • Integrate the separately governed fail-closed Dependency Review repair (ContextualWisdomLab/.github#897 or a freshly verified protected-central successor).
  • Correct the organization-required merge-time Strix unavailable/no-report false-green boundary tracked centrally by .github#891 and locally by security: fail closed when required Strix review is unavailable #197.
  • Obtain one exact protected EgressWeave candidate whose actual immutable-pinned Dependency Review action executes and succeeds.
  • Obtain an actual exact-head Strix semantic review rather than backend-unavailable/neutral/wrapper-only evidence.
  • Revalidate live rulesets, all required workflows, reviews/threads, security findings, exact coverage/docstrings, package/SBOM/provenance/reproducibility, compatibility and rollback/recovery on one unchanged integrated protected head.
  • Exercise the protected release-admission path with the accepted evidence set and independently verify that known negative-control evidence states remain blocked before any tag/publication authority.
  • Only after every release gate passes, version/update CHANGELOG/publish through the reviewed release workflow and independently verify resulting artifacts.
  • Close only after protected-main operational proof demonstrates the release-admission contract end to end.

Non-goals

  • No EgressWeave-local replacement for organization-owned Dependency Review or Strix workflows.
  • No weakening or bypass of organization rulesets.
  • No extra release credential, long-lived publishing token, autonomous release, or model-mediated publication decision.
  • No release merely to manufacture operational evidence while required semantic gates remain non-passing.
  • No claim that a current dependency or source vulnerability exists; this is evidence-integrity/release-authority assurance.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions