This repository was archived by the owner on Oct 30, 2026. It is now read-only.
Repository navigation
Sign with a single SHA-256 CodeDirectory - #4
Open
TartanLeGrand wants to merge 1 commit into
Open
TartanLeGrand wants to merge 1 commit into
TartanLeGrand wants to merge 1 commit into
Conversation
4 tasks done
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
3 tasks done
Zupersign always asked for a SHA-1 primary CodeDirectory with a SHA-256 alternate. codesign emits only SHA-256 for deployment targets of iOS 11 / macOS 10.13 and later, and App Store Connect rejected the pair with ITMS 90034 ('is not signed using an Apple submission certificate') even though the certificate chain, CMS signature and slots were valid. Ad-hoc signatures are unchanged.
TartanLeGrand
force-pushed
the
fix/sha256-only-codedirectory
branch
from
October 26, 2026 23:27
7feefe6 to
f0d12d9
Compare
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
What does this PR do?
Makes Zupersign sign real (non ad hoc) identities with a single SHA-256 CodeDirectory, as codesign does for deployment targets of iOS 11 / macOS 10.13 and later. Ad hoc signatures are unchanged.
zsign_signcalledZSignAsset::Init(..., is_adhoc, false /* bSHA256Only */, false), so every signature had a SHA-1 primary CodeDirectory plus a SHA-256 alternate one. App Store Connect rejects that pair:even though the certificate, the profiles, the entitlements and the signature itself were valid (page hashes, special slots, CMS verified with OpenSSL,
100.9.1/100.9.2cdhash attributes consistent, requirements byte-identical to codesign's). The only remaining structural difference with an Xcode export was the CodeDirectory set. The SHA-256 only mode already exists inZSignAsset; this passes!is_adhocfor it.How was it tested?
Real uploads of a production Tauri app (app plus a WidgetKit extension), signed for distribution through xtool (xtool-org/xtool#326) with an Apple Distribution certificate:
VALIDin about 2 minutes and installed through TestFlight on an iPhone with iOS 27.swift buildof theZupersigntarget; xtool's signing tests updated to expect a single SHA-256 CodeDirectory.Not tested: development signatures installed on a device with this change (development and ad hoc installs used SHA-1 + SHA-256 before; codesign itself emits SHA-256 only for these deployment targets, so no difference is expected), and deployment targets older than iOS 11, which would need the SHA-1 CodeDirectory.
Two smaller differences from codesign remain and did not block processing: the SignerInfo
signatureAlgorithmisrsaEncryption(codesign:sha256WithRSAEncryption), and the CMS is DER encoded without theNULLalgorithm parameters.Merge note: #3 edits the same call; whichever lands second needs a one-line rebase.
Developed with AI assistance; validated on device and against App Store Connect as described above.