Release blocker: protect main and v* release tags before v1.3.0-rc.1 #25

Activity

1. fraware

   self-assigned this

   on Aug 26, 2026
2. fraware commented on Oct 15, 2026

   

   fraware

   on Oct 15, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Live 15 October 2026 independent launch-readiness verification — high-priority release blockers. Verified with GitHub REST read endpoints, not inferred from docs:

   • GET /branches/main: head 79370539ca9b26a0a6b01f6ac6ab6923243f40f4, protected=false; GET /rulesets returns []. Branch protection detail is 403 to the connected integration, so administrative details remain uninspected; however the public branch and ruleset responses do not establish a protected ref. NO-GO for final release authority until an administrator creates and independently rechecks effective protections on main and release-tag namespace.
   • GET /git/ref/tags/v1.3.0-rc.1 returns 404. GET /releases shows only v1.2.1 (published 2026-07-23); v1.3.0-rc.1 in README's copyable Action snippet is currently a non-existent pin. Simplify first-run install instructions so no false installable version is advertised before verified publication.
   • Existing v1.2.1 annotated tag object 7799c5caa977fa9754f6bc854e8e46ce010094e9 targets commit a27d5720f4350c00bca34f71d991c31f5a2f38c7. GitHub reports tag verification.verified=false, reason unsigned. The public Release object says immutable=false. That release includes wheel, sdist and Sigstore bundle assets, which were not independently verified cryptographically in this audit. Explicitly distinguish artifact-signing from tag signing and GitHub immutable release status. Any claim of an already signed and immutable Git ref needs correction.
   • action.yml installs a requested PyPI version using pip install "open-verification-kernel==${OVK_PACKAGE_VERSION}" || install_from_checkout. For authoritative pinning, this fallback is ambiguous. Either fail closed on a requested version mismatch, or explicitly report/verify exact checked-out candidate SHA and package identity before admitting evidence; add a regression test for PyPI-install failure.
   • SECURITY.md lists 1.0.x and 1.1.x as supported, omitting current v1.2.1. Update it and provide a verifiable private disclosure path. LICENSE is a short Apache notice (GitHub repo metadata license=NOASSERTION) rather than a recognized full standard license file; confirm intended SPDX/package distribution and have maintainers correct if necessary.
   • docs/EXTERNAL_PILOT_PLAYBOOK.md promotes strict enforcement on under-5%-FP alone without statistically meaningful sample or independent source-profile calibration. This contradicts the current executable_advisory profile status. Replace with a policy based on supported-claim coverage, adversarial tests, human adjudication, conservative uncertainty and independently justified risk tolerance. A tiny pilot is feasibility evidence.
   • The main docs/README and docs/CURRENT_RELEASE_STATUS.md contain valuable nonclaim disclosures but do not all match the product launch state; docs/ROADMAP.md still refers to an earlier working branch, and public copy-paste experience is confusing.

   Decision: treat branch/tag identity and verified installation as P0 release blockers, safety/strictness/SECURITY docs as P1; no unqualified public Marketplace App or strict auto-merge. Pilot only under consent, advisory mode, exact pinned and auditable source/distribution, and explicit no-reliance claims. Preserve existing #25 open until live admin protections and a new independently authorized release are actually verified.
3. fraware commented on Oct 15, 2026

   

   fraware

   on Oct 15, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Live ref-integrity re-audit — 15 October 2026. CONFIRMED RELEASE BLOCKER. The public GitHub REST branch object GET /repos/fraware/open-verification-kernel/branches/main reports sha=79370539ca9b26a0a6b01f6ac6ab6923243f40f4, protected=false, and protection.enabled=false. The repository rulesets endpoint GET /repos/fraware/open-verification-kernel/rulesets?includes_parents=true returns []. The detailed branch protection endpoint responds 403 to this integration, but the branch summary itself conclusively states protection is currently disabled.

   The published v1.2.1 annotated Git tag refs/tags/v1.2.1 has Git-tag object 7799c5caa977fa9754f6bc854e8e46ce010094e9 → commit a27d5720f4350c00bca34f71d991c31f5a2f38c7; the tag object's verification says verified=false, reason=unsigned. GitHub's published release reports immutable=false. The release has separate signing-related artifacts; this is not evidence those asset signatures fail, and asset signatures must be evaluated independently. Only four historic tag refs (v1.0.0, v1.1.0, v1.2.0, v1.2.1) appear; v1.3.0-rc.1 GET returns 404 and there is no published RC.

   Consequently docs describing the historical Git tag/release as signed immutable are factually wrong in that particular sense. Draft docs correction PR #219 changes these descriptions and directs advisory external installs to a reviewed full commit pin. This PR does not configure repo rules. #25 must stay OPEN until maintainers apply/verify protections, sign and publish a qualified future tag, and complete the ledger and release pipeline. No inference of release authorization from green #218 development CI.
4. fraware commented on Oct 15, 2026

   

   fraware

   on Oct 15, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Execution underway — 2026-10-15: Draft PR #220 now addresses the code/documentation portion of the launch hardening. Its Action install step no longer silently falls back from a user-requested OVK_PACKAGE_VERSION to checkout code. Offline executable shell tests cover failed/successful requested version and intentional source installs. README now uses the published v1.2.1 direct source commit a27d5720f4350c00bca34f71d991c31f5a2f38c7 with matching package version; docs distinguish unsigned existing historical tag, non-immutable Release, nonexistent RC, and unqualified strict profiles. CI/Repro baseline for exact head abccfb5acff097e8cd173afa76a6941183742211 launched; no pass asserted yet.

   Still the blocking GitHub-administrator task (not accessible through this integration):

   1. In Repository Settings, create an active branch ruleset targeting main that restricts force pushes and deletion, and requires PR review and appropriate exact-head checks before changes. Narrowly enumerate any automation bypass principals. Ensure enforcement = active, not evaluate/disabled.
   2. Create an active tag ruleset targeting v* that prevents alteration and deletion of release refs (and permits controlled initial creation as needed). Check ruleset target semantics for the chosen pattern.
   3. Independently re-fetch live /branches/main and /rulesets and confirm protections effective, including relevant bypass actors. The current branch reports unprotected and current rulesets list is empty; the detailed protection endpoint returns 403 for the connector. Do not close Release blocker: protect main and v* release tags before v1.3.0-rc.1 #25 based on a screenshot or a draft configuration.
   4. Only after protected refs and exact-head full engineering preflight: freeze one RC SHA, sign annotated v1.3.0-rc.1 tag with GitHub-verified signature, trigger seven new tag-bound release workflows, verify holdout/consumer artifacts via live ledger authorizer, and let Publish perform byte-bound Sigstore + PyPI + GitHub Release publication. Existing old version metadata and unsigned tag do not satisfy this.

   Safety: Do not merge/publish until the reviewed changes qualify. PR #220 remains draft and will require manual review of metadata/documentation and separate admin completion.
5. fraware commented on Oct 15, 2026

   

   fraware

   on Oct 15, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Engineering qualification checkpoint — 15 October 2026. Draft #220 completed exact-head checks at 525a854df31c604215c8ea2c5f96654f609c8ef3: all six CI jobs success, including 2,610 passing tests, 36 skipped, 13 warnings, and all six Linux/macOS/Windows × Python 3.10/3.12 reproducibility cells success. Installer behavior, public guidance, license packaging and advisory onboarding are engineered and tested on that exact draft SHA.

   #25 remains OPEN / release NO-GO. Code-level green CI cannot grant GitHub administrative authority. The latest independent public API read reported main protected=false, no active rulesets; branch-protection-detail endpoint was inaccessible (403). An authorized administrator must create effective active rules for main and release v* tags with appropriate reviewer/check/force-push/delete restrictions, then independently read back status and permitted bypass principals. Only after controls are effective may #220 proceed through protected review/merge, followed by rebase/qualification of P0 source binding PR #223, then frozen SHA / authenticated release ledger and tag-bound publication. No release has occurred. Do not close #25 solely because #220 has green CI.
6. fraware commented on Oct 16, 2026

   

   fraware

   on Oct 16, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Administration handoff — 2026-10-15 (verified live state)

   GitHub API read-back: GET /repos/fraware/open-verification-kernel/branches/main returned protected=false at 79370539ca9b26a0a6b01f6ac6ab6923243f40f4; GET /repos/fraware/open-verification-kernel/rulesets returned empty []. The connected GitHub integration exposes no repository-administration/ruleset creation capability. No protection settings have been altered.

   Action for an authorized repository administrator — Settings → Rules → Rulesets:

   1. Create an Active branch ruleset targeting the default branch main. Set block force pushes, restrict deletions, require a pull request before merging, and require independent human approval for sensitive verification/source-binding changes. Select required CI checks using GitHub's actual reported check context names; confirm their future merge-preview/event semantics before making them mandatory. Do not grant a blanket push/merge bypass to agents or automation.
   2. Create an Active tag ruleset targeting release tags v*. Restrict updates and deletions; do not unintentionally forbid normal creation of the authorized, signed annotated first tag. Limit bypasses narrowly, and independently review any account that can rewrite existing release tags.
   3. Read back both effective rulesets and test the restrictions. Capture rule IDs, targeting patterns, enforcement status, and bypass actors. Confirm main is protected in the live API. Verify the release-tag restriction actually prohibits updates/deletions, not only literal matching of a non-matching pattern.
   4. Only after independent review plus exact-candidate CI/native/Repro gates, authorize a new signed annotated tag directly at the intended final source SHA. Existing v1.2.1 is unsigned and must not be retroactively described as signed; v1.3.0-rc.1 remains absent. Follow docs/RELEASE.md through new tag-bound evidence and release-ledger authorization; do not manually publish a GitHub release or infer tag signing from Sigstore files.

   Do not close this issue from this checklist or the current draft green CI. Closure needs observed effective GitHub protection and authorized release evidence. The technical development drafts #225/#226/#227 are all green but remain unmerged; draft #228 adds a portable report and its exact-head checks are pending.