@zip.js/zip.js 2.18.0

on Node.js NPM

What's Changed in v2.18.0

Bug fixes

• A Zip64 extra field of a local file header that is too short for the 0xFFFFFFFF sentinels of the header or holds a value above Number.MAX_SAFE_INTEGER no longer fails getData() with ERR_EXTRAFIELD_ZIP64_NOT_FOUND or ERR_UNSUPPORTED_UINT64: the sizes of an entry come from the central directory, so the field is reported as WARNING_MALFORMED_EXTRA_FIELD on entry.warnings and the entry is read. A local file header whose sizes hold the sentinels with no Zip64 extra field behind them, which used to pass silently, is reported the same way. In the three cases an entry without a data descriptor keeps the sentinels as its local sizes, which the local file header check reports as WARNING_MISMATCHED_LOCAL_FILE_HEADER_CRC32_OR_SIZES, i.e. ERR_AMBIGUOUS_ARCHIVE under the default strictness and a warning with strictness: "tolerant". Both errors are still raised by getEntries() for a central directory record whose field is too short or holds such a value, where the sizes and the offset have no other source, and a record whose sizes, offset or disk number hold the sentinel with no Zip64 extra field behind it now fails getEntries() with ERR_EXTRAFIELD_ZIP64_NOT_FOUND too, at every strictness, so none of the entries is listed: it used to be listed with sizes of 4 GB and fail later, with a local file header mismatch or ERR_ENTRY_DATA_OUT_OF_BOUNDS, or with ERR_LOCAL_FILE_HEADER_NOT_FOUND for an offset
• An AES extra field on a record that is not encrypted and whose compression method is not 99 is ignored and reported as WARNING_MALFORMED_EXTRA_FIELD, on ZipReader#warnings with the filename for the central directory record and on entry.warnings for the local file header, and the entry is read with the method its record declares; the field used to override the method and getData() failed with ERR_UNSUPPORTED_COMPRESSION. An AES extra field shorter than 7 bytes, which was ignored silently, is reported the same way. On an encrypted record the field still overrides the method and the conflict is still rejected with ERR_UNSUPPORTED_COMPRESSION, since the data may be AES behind a wrong method
• The encrypted flag of an entry follows its central directory record. A local file header whose bit 0 is cleared is still ERR_AMBIGUOUS_ARCHIVE under the default strictness, and a reader with strictness: "tolerant" now decrypts the entry and deposits WARNING_MISMATCHED_LOCAL_FILE_HEADER_BIT_FLAG, where it used to follow the local file header, read the ciphertext as plaintext and fail
• An entry whose strong encryption bit (bit 6 of the general purpose bit flag) differs between the two records is ERR_AMBIGUOUS_ARCHIVE under the default strictness, like the encrypted bit, and the ERR_UNSUPPORTED_ENCRYPTION check reads the central directory record. A bit set in the local file header only used to reject an encrypted entry, AES or ZipCrypto, as unsupported, and a bit set in the central directory only was ignored; a reader with strictness: "tolerant" now decrypts the first with WARNING_MISMATCHED_LOCAL_FILE_HEADER_BIT_FLAG and reports the second as ERR_UNSUPPORTED_ENCRYPTION
• The cause of an error raised in a worker keeps its code property, e.g. "Z_MEM_ERROR" on the cause of ERR_CODEC_OUT_OF_MEMORY. A structured clone never copies that property, so it was undefined with workers on every host, while the code of the error itself was already carried by the message posted by the worker

Documentation

• ERR_EXTRAFIELD_ZIP64_NOT_FOUND, ERR_UNSUPPORTED_UINT64, WARNING_MALFORMED_EXTRA_FIELD and WARNING_MISMATCHED_LOCAL_FILE_HEADER_BIT_FLAG document the cases above, and ERR_INVALID_COMPRESSED_DATA, ERR_INVALID_CRC32, ERR_INVALID_UNCOMPRESSED_SIZE and ERR_CODEC_OUT_OF_MEMORY state more precisely the routes on which they are raised: the ERR_INVALID_CRC32 case of Node.js for bytes trailing the deflate stream with checkCrc32, the gzip route of an AE-2 entry running only on a host without "deflate-raw" whose bundled codec cannot take over either, e.g. because the WebAssembly module failed to load, and, on a host without "deflate-raw", a bundled codec that cannot allocate its state when the entry starts not being reported as ERR_CODEC_OUT_OF_MEMORY, since the native codec takes over through a gzip container unless useCompressionStream is false

Tests and continuous integration

• New tests cover the three ways a Zip64 extra field of a local file header is unreadable, and their central directory counterparts, the stray AES extra field on a deflated and on an encrypted entry, the encrypted bit and the strong encryption bit disagreeing between the two records, and a worker whose codec cannot allocate its state, a test that runs on the browsers with module workers, Deno and Bun

Full Changelog: v2.17.0...v2.18.0

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com