This was generated by AI during triage.
Why
macOS release acceptance currently risks comparing two different integrity boundaries:
.github/workflows/release-fork.yml publishes SHA256SUMS for the downloaded archive.
oc verifies that archive before extraction, then runs xattr -cr and codesign -fs - on the installed binary.
A v1.0.39 reproduction confirmed the archive checksum matched its release entry, while installer-style re-signing changed the extracted binary hash. Repeating the re-sign on the same host was stable, but cross-macOS/codesign-version reproducibility has not been established. Therefore a pre-install archive digest must not be compared with the post-install executable, and a universal post-sign digest must not be promised without cross-host evidence.
Scope
- Define the macOS acceptance boundary: verify
SHA256SUMS against the archive before extraction.
- After installation, verify code-signature validity and executable behavior rather than comparing the executable with the archive payload hash.
- Document the mandatory installer re-sign step and the two distinct checks.
- Add a post-sign digest only if a matrix test proves deterministic output across every supported macOS/codesign version.
Out of scope: changing the build-time signing delivered by #455 or removing the installer re-sign step without separate Gatekeeper evidence.
Acceptance
- An automated test fails when the downloaded archive differs from
SHA256SUMS and passes before extraction when it matches.
- A macOS acceptance test performs the installer re-sign step, verifies the resulting signature, and runs the installed binary without comparing it to the archive payload hash.
- Release/acceptance documentation explicitly distinguishes archive integrity from post-install signature validity.
- Any proposed post-sign hash asset includes evidence that the hash is reproducible across the supported macOS runner/version matrix.
Evidence
oc:215-230, oc:271-287, oc:319-328
.github/workflows/release-fork.yml:145-153, :218-252, :268-273
packages/opencode/script/build.ts:212-215
- v1.0.39 reproduction: archive SHA matched; extracted binary
841648e2...; installer-style re-sign and installed binary both 317ea6a9... on this host.
Why
macOS release acceptance currently risks comparing two different integrity boundaries:
.github/workflows/release-fork.ymlpublishesSHA256SUMSfor the downloaded archive.ocverifies that archive before extraction, then runsxattr -crandcodesign -fs -on the installed binary.A v1.0.39 reproduction confirmed the archive checksum matched its release entry, while installer-style re-signing changed the extracted binary hash. Repeating the re-sign on the same host was stable, but cross-macOS/codesign-version reproducibility has not been established. Therefore a pre-install archive digest must not be compared with the post-install executable, and a universal post-sign digest must not be promised without cross-host evidence.
Scope
SHA256SUMSagainst the archive before extraction.Out of scope: changing the build-time signing delivered by #455 or removing the installer re-sign step without separate Gatekeeper evidence.
Acceptance
SHA256SUMSand passes before extraction when it matches.Evidence
oc:215-230,oc:271-287,oc:319-328.github/workflows/release-fork.yml:145-153,:218-252,:268-273packages/opencode/script/build.ts:212-215841648e2...; installer-style re-sign and installed binary both317ea6a9...on this host.