fix(release): strip Mach-O signature before patchver on apple targets#35897
Merged
Conversation
Deno applies a default minimum-dependency-age when resolving jsr
dependencies, refusing versions published more recently than ~1 day
ago. The promotion scripts import @deno/patchver, which is typically
bumped and republished right before a promotion, so the freshly
published version is always "too new" and the run aborts:
error: Could not find version of '@deno/patchver' that matches '0.5.1'
A newer matching version was found, but it was not used because it
was newer than the specified minimum dependency date
These scripts only pull first-party and @std dependencies (@deno/
patchver, @david/dax, @std/fmt), so the supply-chain age gate that
protects user projects from freshly compromised third-party packages
does not apply. Pass --minimum-dependency-age=0 to both promote
`deno run` invocations so a just-published patchver can be used.
rcodesign fails signing the x86_64-apple-darwin deno binary during promotion with "__LINKEDIT segment contains data after signature". patchver runs as a Wasm module. libsui used to strip an Intel Mach-O's existing code signature before injecting a section by shelling out to `codesign`, but that path is gated to Apple hosts and is absent from the wasm32 build. So patchver appends the channel section after the stale signature, leaving data in __LINKEDIT past the signature that rcodesign refuses to parse. arm64 is unaffected because that path rebuilds the binary through the in-memory signer. The promotion job runs on a macOS runner, so strip the signature with native `codesign --remove-signature` before patchver for apple targets. patchver then writes into an unsigned binary and rcodesign re-signs it cleanly.
bartlomieju
added a commit
that referenced
this pull request
Jul 15, 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.
rcodesign fails signing the x86_64-apple-darwin deno binary during LTS/RC
promotion with "__LINKEDIT segment contains data after signature".
patchver runs as a Wasm module. libsui used to strip an Intel Mach-O's
existing code signature before injecting a section by shelling out to
codesign, but that path is gated to Apple hosts and is absent from the
wasm32 build, so patchver appends the channel section after the stale
signature and leaves data in __LINKEDIT past the signature that rcodesign
refuses to parse. arm64 is unaffected because that path rebuilds the
binary through the in-memory signer.
The promotion job runs on a macOS runner, so strip the signature with
native codesign --remove-signature before patchver for apple targets.
patchver then writes into an unsigned binary and rcodesign re-signs it
cleanly.
Stacked on #35893 (min-dep-age) so both promote fixes are testable
together; retarget to main once that merges.