chore(release): verify SHA512 against actual archive (Part of #674)#676
Merged
chore(release): verify SHA512 against actual archive (Part of #674)#676
Conversation
Add an independent SHA512 verification step in sync-vcpkg-registry.yml that re-downloads the release archive from GitHub and compares the recomputed SHA against the value the workflow is about to write to portfile.cmake. On mismatch the step prints both SHAs and exits 1 before any registry commit happens. Mitigates the failure mode found in microsoft/vcpkg#51511 and kcenon/vcpkg-registry#87, where every kcenon port shipped a SHA that did not match the actual archive and cold-cache vcpkg installs failed. The audit confirmed sync-vcpkg-registry.yml is the only workflow in this repo that computes SHA512; release.yml and release-template.yml build/test/publish but do not write portfile SHAs, so no changes were needed there. on-release-sync-registry.yml is a thin caller that inherits the new step automatically. Implementation notes: - New step runs between 'Download release archive and compute SHA512' (id: sha) and 'Update portfile.cmake with new SHA512 and REF', so a mismatch fails the run before any portfile mutation - Downloads to a file (not pipe) so curl's --fail exit code is not masked by sha512sum producing the empty-input hash on fetch error - curl uses --retry 3 --retry-delay 2 for transient network blips - Runtime cost ~1-2s for a kcenon archive Part of #674.
This was referenced May 3, 2026
kcenon
added a commit
to kcenon/logger_system
that referenced
this pull request
May 3, 2026
Add an independent SHA512 verification job to on-release-sync-registry.yml that re-downloads the release archive from GitHub and recomputes its digest after the reusable sync workflow completes. Provides repo-local defense-in-depth on top of the verify step inside kcenon/common_system/.github/workflows/sync-vcpkg-registry.yml that was added in kcenon/common_system#676. The job uses file-based hashing (curl -fsSL --retry 3 -o file, then sha512sum file) rather than a pipe so a fetch failure cannot silently produce the empty-input hash cf83e1357eefb8bdf... A minimum-size sanity check rejects suspiciously small archives. Closes #634 Part of kcenon/common_system#674.
4 tasks
kcenon
added a commit
to kcenon/database_system
that referenced
this pull request
May 3, 2026
Add a defense-in-depth pre-verification job to on-release-sync-registry.yml that downloads the published GitHub release archive and computes its SHA512 before delegating to the shared sync workflow that writes the SHA into portfile.cmake. The downstream reusable workflow (kcenon/common_system/.github/workflows/sync-vcpkg-registry.yml) was hardened in kcenon/common_system#676 to compare its computed SHA against the actual archive. This change adds an independent check in this repo so a release that produces an unfetchable or empty archive fails fast in this repo's release run, with a clear log line, before the sync workflow ever runs. The check uses file-based hashing (curl -fsSL --retry 3 ... -o tmpfile) rather than piping curl into sha512sum, so a fetch failure cannot silently produce the empty-input SHA512 (cf83e1357eefb8bdf...). The empty-input hash is also explicitly rejected as a final safety net. Audit: - on-release-sync-registry.yml: thin caller of common_system reusable workflow; this PR adds an independent pre-verification job here. - release.yml: builds and publishes platform artifacts, no SHA write. - vcpkg-overlay.yml: local overlay-port build/test, no SHA write. - All other workflows (ci, sanitizers, coverage, integration, etc.): no portfile SHA computation. Closes #588 Part of kcenon/common_system#674
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 #675
Part of #674.
What
Adds an independent SHA512 verification step to
.github/workflows/sync-vcpkg-registry.ymlthat re-downloads the release archive from GitHub and compares the recomputed digest against the value the workflow is about to write toportfile.cmake. On mismatch, the step prints both SHAs and exits 1 before any registry commit happens.Why
Detected via microsoft/vcpkg#51511 and kcenon/vcpkg-registry#87 - every kcenon port shipped a mismatched SHA512 because the release workflow never compared its computed value against the actual archive. Cold-cache vcpkg consumers (new CI runners, fresh users) hit 100% install failure when the SHA in
vcpkg-registry/ports/kcenon-common-system/portfile.cmakedoes not match the bytes athttps://github.com/kcenon/common_system/archive/refs/tags/v<version>.tar.gz. This PR closes the detection gap forcommon_system.Where
.github/workflows/sync-vcpkg-registry.ymlVerify SHA512 against actual GitHub archiveinserted between the existingshastep (id:sha) andUpdate portfile.cmake with new SHA512 and REFAudit summary (other workflows considered)
sync-vcpkg-registry.ymlsteps.sha.outputs.sha512, writes to portfile)release.ymlrelease-template.ymlon-release-sync-registry.ymlsync-vcpkg-registry.yml)port-sync-check.ymlOnly
sync-vcpkg-registry.ymlactually computes a SHA512, so an inline step in that single workflow is more appropriate than extracting a composite action.How
The new step runs immediately after the existing
Download release archive and compute SHA512step and beforeUpdate portfile.cmake with new SHA512 and REF. It re-fetches the archive withcurl -fsSL --retry 3to a file (not piped) so a 404 cannot silently produce the empty-input hashcf83e1357eefb8bdf.... The exit-1 error message includes both the workflow-computed SHA and the archive's actual SHA so debug logs are immediately useful.Runtime: ~1-2s on a typical
common_systemarchive (~200 KB).Test Plan
How a reviewer can validate the new step fires
v0.x.y) - the existingSync Registry on Releaseworkflow triggerssync-vcpkg-registry.ymlVerify SHA512 against actual GitHub archive. On a healthy release, the step prints:How to simulate a mismatch
Locally executed and confirmed before push:
v0.2.0archive, real workflow-computed SHA): step exits 0, prints verification line.SHA512 mismatch detected for v0.2.0/Workflow computed: 000.../GitHub archive: ac4588.../Refusing to commit a portfile that would not install.v999.999.999):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; step ordering confirmed (Verify is step 5 of 12, aftershaand before portfile update).Breaking Changes
None. The new step is additive; on a successful release it adds ~1-2s and one log line. On a SHA mismatch (the failure mode this PR is designed to detect) it short-circuits the existing run before any vcpkg-registry commit, which is the desired behavior.