1.1.2: sign IPAs >2 GB, recover a broken anisette cache - #2
Merged
Conversation
zsign reads and writes IPAs through its vendored minizip, which defines USE_FILE32API on Windows and so falls back to 32-bit fseek/ftell. It could not seek past the 2 GB mark to reach the central directory of a larger archive, so signing a big app - a 4 GB game, say - failed at once with "Unzip failed!". Route both the read (unzOpen2_64) and the write (zipOpen2_64) through iowin32's 64-bit Win32 file API. The change is applied to the upstream clone during the build (tools/zsign/win-largefile.patch, git apply in build-zsign.sh), which fails loudly if upstream drifts rather than silently reverting to the 32-bit path. Also restores -DZSIGN_VERSION=iPASide, which the build had dropped. The script and patch are pinned to LF in .gitattributes so a clone with autocrlf=true cannot break the MSYS2 build or the patch apply. Proven by signing a real 4.19 GB IPA end to end - unzip, sign every framework, repack to a valid 4.19 GB output. Co-authored-by: Cursor <cursoragent@cursor.com>
iPASide sets up Apple sign-in with a small set of device libraries it downloads once and caches together with the provisioning state. If that download was intercepted (a proxy or captive-portal page in place of the archive) or the cache was left half-written by an interrupted first run, every later launch re-threw a raw "not a gzip/bzip2/xz/tar file" error from deep in the archive parser, and the only way out was to find and delete the cache by hand. Discard a cache that will not load and re-provision. Fetch the libraries with a retry and a check that the response really is an archive, and raise a clear "provisioning server may be down or the network is blocking it" instead of a parser stack trace. The libraries are still downloaded, not bundled, so nothing of Apple's is redistributed. Co-authored-by: Cursor <cursoragent@cursor.com>
Signing IPAs larger than ~2 GB, and recovery from a broken anisette provisioning cache. See CHANGELOG.md. Co-authored-by: Cursor <cursoragent@cursor.com>
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.
What
Two hardware-reported bugs, shipped as 1.1.2.
fix(zsign)— signing IPAs larger than ~2 GBzsign's vendored minizip uses 32-bit file offsets on Windows (
USE_FILE32API), so itcould not seek to the central directory of an archive over 2 GB — a 4 GB game's IPA
failed instantly with "Unzip failed!". Both the read (
unzOpen2_64) and write(
zipOpen2_64) now go through iowin32's 64-bit Win32 file API, patched into the upstreamclone during the build (
tools/zsign/win-largefile.patch, applied bygit apply, failsloudly if upstream drifts).
-DZSIGN_VERSION=iPASiderestored. The script and patch arepinned to LF so a fresh clone with
autocrlf=truecan't break the build.fix(anisette)— recovering a broken provisioning cacheA blocked download (a proxy/error page instead of the archive) or a half-written cache
from an interrupted first run made every later launch re-throw a raw
tarfileparsererror, unrecoverable without deleting a file by hand. iPASide now discards an unloadable
cache and re-provisions, verifies the download really is an archive (retrying if not), and
reports a clear "provisioning server may be down or the network is blocking it". The
libraries are still downloaded, not bundled — nothing of Apple's is redistributed.
Verified
installed engine through a full sideload of a real 4.19 GB IPA onto a physical
iPhone: provision → sign → install, 0→100%, app on device. The step that used to die at
"Unzip failed!" now completes.