Conversation
Pin reusable sync workflow to the hardened merge commit from kcenon/common_system PR #676 so the SHA512 verify-against-archive hardening cannot silently regress, and add a defense-in-depth verification job that re-fetches the published archive after sync and compares its SHA512 against the SHA written to vcpkg-registry/ports/kcenon-container-system/portfile.cmake. Audit summary (per #542 acceptance criteria): - on-release-sync-registry.yml: Yes (calls reusable workflow that computes/writes SHA512 via portfile commit). Hardened by this change: pinned ref + parallel verification job. - release.yml: No (multi-platform build/test/GitHub release only; does not touch portfile SHA). No change needed. - validate-vcpkg-port.yml: No (consumer-side find_package + build/install verification; does not write portfile). No change needed. - All other workflows (ci, coverage, sanitizers, fuzzing, sbom, benchmarks, docs, etc.): No SHA computation or portfile writes. Out of scope. The new verification job uses file-based hashing (curl -fsSL --retry 3 -o <tmp>) rather than piping into sha512sum, which prevents a 404 from silently producing the empty-input SHA-512 constant cf83e1357eefb8bdf... (see kcenon auto-memory: curl_sha512_empty_input). On a healthy release the job adds ~2-3s and one log line. On a SHA mismatch the job fails the workflow run with annotations naming both the registry SHA and the archive SHA before consumers can hit a cold-cache install failure. Closes #542 Part of kcenon/common_system#674 References kcenon/common_system PR #676 (validated reference pattern)
This was referenced May 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #542
Part of kcenon/common_system#674.
References validated pattern in kcenon/common_system PR #676 (merged with 7/7 CI green).
What
Pins
on-release-sync-registry.ymlto the hardened merge commit ofkcenon/common_systemPR #676 (c90d4b828d3063989a850a785c7a60753c2b35ea) and adds an independent defense-in-depth verification job that runs after the reusable sync workflow.The new job
verify-sha512-against-archivere-fetches the published GitHub archive and compares its SHA512 against the SHA the registry portfile now declares forkcenon-container-system. On mismatch the workflow run fails with annotations naming both SHAs, before any cold-cache vcpkg consumer can hit an install failure.Why
Detected via microsoft/vcpkg#51511 and kcenon/vcpkg-registry#87 - every kcenon port shipped a mismatched SHA512 because release automation never compared its computed value against the actual archive bytes. Cold-cache consumers (new CI runners, fresh users) hit 100% install failure when
vcpkg-registry/ports/kcenon-container-system/portfile.cmakedoes not matchhttps://github.com/kcenon/container_system/archive/refs/tags/v<version>.tar.gz.This PR closes the detection gap for
container_system.Where
.github/workflows/on-release-sync-registry.ymlverify-sha512-against-archivejob that runsneeds: syncAudit summary (other workflows considered)
on-release-sync-registry.ymlrelease.ymlvalidate-vcpkg-port.ymlci,coverage,sanitizers,fuzzing,sbom,benchmarks,docs, etc.)Only
on-release-sync-registry.ymlparticipates in writing the portfile SHA, so a single-workflow hardening + parallel verification job satisfies the issue acceptance criteria.How
The pinned reusable workflow (PR #676) inserts the SHA512 verify-against-archive step BETWEEN SHA computation and portfile commit, using file-based hashing (
curl -fsSL --retry 3 -o <tmp>) rather than piping intosha512sumso a 404 cannot silently produce the empty-input SHA-512 constantcf83e1357eefb8bdf...(see kcenon auto-memory:curl_sha512_empty_input).This PR's new
verify-sha512-against-archivejob adds a second, independent check that runs after the sync workflow has committed the new SHA: it re-downloads the published archive and the registry portfile, extracts the SHA from the portfile via regex, and compares. If the reusable workflow's internal verification is ever bypassed or regresses, this defensive job still catches the mismatch.Runtime: ~2-3s on a typical
container_systemarchive.Test Plan
Reviewer validation
v0.x.y). The existingSync Registry on Releaseworkflow triggers both jobs:sync(reusable workflow with internal SHA verification from PR #676)verify-sha512-against-archive(this PR's defensive job)verify-sha512-against-archivelog for:Mismatch simulation (validated locally)
SHA512 mismatch detected for v0.x.y/Registry portfile: 000.../GitHub archive: <real>/Cold-cache vcpkg consumers would hit install failure.curl -fsSLreturns RC=22, theif !branch firesexit 1withFailed to download release archive for verification: <URL>. The download-to-file pattern (rather than a pipe) is required to make this work; piping intosha512sumwould otherwise mask the curl failure with the empty-input hash.YAML structure validated with
js-yaml; job ordering confirmed (verify-sha512-against-archivehasneeds: sync).Breaking Changes
None. Both changes are additive on a successful release: the pinned ref behaves identically to
@mainbecause the hardening is already in main; the new verification job adds ~2-3s and one log line per release. On a SHA mismatch (the failure mode this PR is designed to detect) it short-circuits the release before any consumer sees a stale SHA, which is the desired behavior.