Python's zipfile stores central-directory offsets relative to the zip start, but Redbean's APE (Actually Portable Executable) format expects absolute file offsets — because the zip is appended to a ~5 MB binary stub and the EOCD record is found by scanning backward from EOF.
When rebuilding a Redbean mock binary in Python (no zip CLI available), I found the first PK\x03\x04 at offset 731034 — which was inside the ELF/Mach-O stub, not the actual zip start at offset 5318376. Using the wrong split point produced a valid zip (Python's testzip() passed) that still caused a bus error at runtime because the EOCD's cd_offset field pointed into the binary stub. Fix: use the first entry's header_offset from zipfile.ZipFile to find the real zip start, then patch every central-directory entry's local-header offset and the EOCD's cd_offset by adding that prefix length before writing the final binary.
Source: rhencke/confusio#287
Python's
zipfilestores central-directory offsets relative to the zip start, but Redbean's APE (Actually Portable Executable) format expects absolute file offsets — because the zip is appended to a ~5 MB binary stub and the EOCD record is found by scanning backward from EOF.When rebuilding a Redbean mock binary in Python (no
zipCLI available), I found the firstPK\x03\x04at offset 731034 — which was inside the ELF/Mach-O stub, not the actual zip start at offset 5318376. Using the wrong split point produced a valid zip (Python'stestzip()passed) that still caused a bus error at runtime because the EOCD'scd_offsetfield pointed into the binary stub. Fix: use the first entry'sheader_offsetfromzipfile.ZipFileto find the real zip start, then patch every central-directory entry's local-header offset and the EOCD'scd_offsetby adding that prefix length before writing the final binary.Source: rhencke/confusio#287