mirror of
https://github.com/jmcorgan/fips.git
synced 2026-07-22 07:48:26 +00:00
57a089f6c3
The published v0.3.0 macOS installer is a structurally corrupt xar archive: pkgutil and xar reject it even though its SHA-256 matches the published checksum. build-pkg.sh derived the architecture suffix in the .pkg filename from `uname -m`. On the Apple-silicon macOS runner that always reports arm64, so the cross-compiled x86_64 build also named its output fips-<version>-macos-arm64.pkg. The release job downloads both build artifacts with merge-multiple into one directory, where the two identically named files collide and tear into a malformed result. The x86_64 package never reaches the release at all. Derive the package architecture from the Rust target triple, which is authoritative for cross-compiles, instead of from the build host. Each matrix leg now produces a distinctly named, arch-correct package, so the two artifacts no longer collide. Add a SHA-256 integrity chain so a corrupt or mismatched asset cannot be published again: - Capture the .pkg SHA-256 on the macOS runner, after the on-runner structural verification, into a sidecar file carried in the artifact. - Add a verify-handoff job that runs on every trigger and asserts each downloaded .pkg still matches its macOS-runner SHA-256. - Gate the release job on verify-handoff and repeat the check on the exact bytes about to be published. The build step now asserts it produced the expected arch-named package so a regression in the naming fails loudly rather than as a silent collision. Relates to #102. The published v0.3.0 macOS assets still need to be rebuilt and reuploaded separately.