release: no tag has ever run through release.yml — the attestation path is untested

[cdeust]

Blocks the OpenSSF Best Practices silver criterion signed_releases ("MUST cryptographically sign releases intended for widespread use, and there MUST be a documented process explaining how users obtain the public signing keys and verify the signatures"). Answered Unmet in .bestpractices.json.

The gap

.github/workflows/release.yml was added by #37 and merged 2026-07-25 (d38171f). The latest release, v2.7.1, was cut by hand on 2026-07-24 (0d136b0), one day earlier.

So every published release artifact predates the signing pipeline. The workflow is correct as far as review can tell (it tests, builds, fingerprints ui/, emits a CycloneDX SBOM, checksums every asset, and calls actions/attest-build-provenance before upload), but it has never executed. An untested release path is not a control, and SECURITY.md currently describes the verification step as though a user could perform it today. They cannot: there is no attested asset to verify.

The Scorecard Signed-Releases check reports -1 (inconclusive) for the same reason.

What closes it

Cut v2.7.2 through the workflow and verify the output end to end:

• Tag v2.7.2 pushed, Release workflow completes green
• Release carries: wheel, sdist, cortex-viz.cdx.json, cortex-viz-ui-manifest.sha256, and a .sha256 companion for each
• gh attestation verify cortex-viz-ui-manifest.sha256 --repo cdeust/cortex-viz succeeds from a clean checkout, run by someone following SECURITY.md verbatim
• The UI manifest line count matches the file count under ui/ (98 JS files plus HTML/CSS)
• The marketplace pin in Cortex's manifest is bumped, because tagging alone reaches zero installs
• SECURITY.md names the first release for which verification actually works
• .bestpractices.json signed_releases_status flips to Met

Related

Consider signing the version tag itself as well (git tag -s): the silver version_tags_signed criterion is SUGGESTED, and no current tag is signed (git tag -v v2.7.1 reports a non-tag commit object).

[cdeust]

Partial evidence recorded while merging the action bumps that landed in this workflow (#54 setup-python 5→7, #55 attest-build-provenance 2→4, #80 action-gh-release 2→3).

release.yml still has zero runs — gh run list --workflow Release returns empty, which is what this issue is about. Since CI cannot exercise it, the three bumps were checked statically instead: every input the workflow passes was resolved against the action.yml declared at the newly pinned SHA.

OK  actions/checkout@3d3c42e                passes=(none)
OK  actions/setup-python@5fda3b9            passes=['python-version']
OK  astral-sh/setup-uv@d4b2f3b              passes=(none)
OK  actions/attest-build-provenance@0f67c3f passes=['subject-path']
OK  softprops/action-gh-release@3d0d988     passes=['tag_name', 'generate_release_notes', 'files', 'fail_on_unmatched_files']
==> ALL release.yml INPUTS ARE DECLARED BY THE PINNED ACTIONS

Upstream breaking changes reviewed against what this workflow actually uses:

• setup-python v6 = node24 runtime (runner ≥2.327.1, satisfied by ubuntu-latest); v7 = ESM + removal of the pip-install input, which this workflow does not pass.
• attest-build-provenance v3 = node24 runtime; v4 = now a thin wrapper over actions/attest, with subject-path retained and existing users explicitly supported.
• action-gh-release v3 = Node 20 → 24 runtime only; no input changes.

So the configuration is compatible. What remains unproven is exactly what this issue names: no tag has ever driven the build → fingerprint → SBOM → attest → release path end to end, so the shell steps (find|sort|sha256sum, uv export, cyclonedx-py, fail_on_unmatched_files) and the OIDC/attestation permissions have never executed. Static input checking cannot substitute for that. Issue stays open.