What

Audit and harden the SHA512 update step in the release automation of all 8 kcenon systems so that an archive's actual SHA is verified against sha512sum of the GitHub release archive before the new value is committed to the vcpkg overlay registry.

• Current: Release workflows (presumably chore: automate portfile SHA512 on release #643-derived) write SHA512 to kcenon/vcpkg-registry/ports/<port>/portfile.cmake without verifying against the actual archive at https://github.com/<repo>/archive/refs/tags/v<version>.tar.gz. All 8 ports were silent-broken as of 2026-05-03. Weekly vcpkg-consume-test.yml PASSED throughout because vcpkg's archive cache hits sidestep SHA verification.
• Expected: Every release writes a SHA512 only after curl + sha512sum confirms the value. Mismatch fails the release. Consumers never see a stale SHA.
• Scope: Cross-repo. 8 system release workflows + the vcpkg-registry consume-test workflow.

Why

• Discovered while preparing chore(vcpkg): submit kcenon-common-system to microsoft/vcpkg official registry #653 ([kcenon-common-system] new port microsoft/vcpkg#51511 upstream submission). microsoft/vcpkg PR CI failed at download phase with hash mismatch on the kcenon-common-system port — the SHA in kcenon/vcpkg-registry/ports/kcenon-common-system/portfile.cmake was 7385ba3a073fea06... but the actual v0.2.0 archive's SHA512 is ac458878395dbac6....
• Audit (kcenon/vcpkg-registry#87 and PR #88) confirmed all 8 ports had the same class of mismatch — not a per-system oversight, a systemic flaw in the release automation.
• vcpkg's archive cache silently masks SHA mismatch in subsequent installs (cache hit skips re-verification). New cold-cache consumers (new CI runners, new users) hit 100% install failure on every kcenon port.
• This is exactly the failure class that prevents adoption — it works for maintainers, fails for new users, and the existing test infrastructure doesn't surface it.

Where

How

Recommended verification snippet (bash)

# Verify computed SHA against the actual GitHub archive before committing
TAG="$1"   # e.g., v0.2.0
REPO="$2"  # e.g., kcenon/common_system
NEW_SHA="$3"  # value the workflow is about to write to portfile.cmake

ARCHIVE_URL="https://github.com/${REPO}/archive/refs/tags/${TAG}.tar.gz"
ACTUAL_SHA=$(curl -fsSL "$ARCHIVE_URL" | sha512sum | awk '{print $1}')

if [ "$NEW_SHA" != "$ACTUAL_SHA" ]; then
    echo "ERROR: SHA mismatch — workflow computed $NEW_SHA, archive has $ACTUAL_SHA" >&2
    exit 1
fi

This step should run AFTER the workflow computes the new SHA and BEFORE committing the portfile change. It catches both (a) wrong archive form (zipball vs tar.gz), (b) GitHub archive endpoint drift, and (c) hand-edits without verification.

Acceptance criteria

• All 8 system release workflows include a "verify SHA against actual archive" step
• kcenon/vcpkg-registry#87 closed (immediate ports fix landed)
• kcenon/vcpkg-registry/pull/88 merged (immediate ports fix)
• vcpkg-consume-test.yml forces fresh download per cycle (--no-binary-caching or runner-cleanup)
• [kcenon-common-system] new port microsoft/vcpkg#51511 reaches a conclusion (merged or accepted maintenance)

Sub-issues to create

• 8 per-system: "chore(release): verify SHA512 against actual archive"
• 1 registry: "ci(consume-test): force fresh download to surface SHA mismatch"

Risk

• Existing consumers with cached archives are unaffected today
• Cold-cache consumers (new CI runners, new users) hit failure now → fixed by #88
• After hardening, every release adds 1-2s of curl + sha512sum verification — negligible

Related

• #653 — first finding ([kcenon-common-system] new port microsoft/vcpkg#51511 upstream submission)
• #643 — original SHA automation that needs hardening
• #646 — parent EPIC: vcpkg distribution readiness
• kcenon/vcpkg-registry#87 — immediate fix issue
• kcenon/vcpkg-registry/pull/88 — immediate fix PR