chore(deps-dev): bump @zip.js/zip.js from 2.15.0 to 2.17.0

[dependabot]

Bumps @zip.js/zip.js from 2.15.0 to 2.17.0.

Release notes

Sourced from @​zip.js/zip.js's releases.

v2.17.0

What's Changed in v2.17.0

New features

• ERR_CODEC_OUT_OF_MEMORY is a new exported constant, thrown when the codec of an entry cannot allocate the memory it needs, e.g. when the 16 MB heap of the bundled WebAssembly module is exhausted by too many entries processed concurrently in the same worker, or on the page when workers are off, with the error of the codec as the cause. The failure is recognized by the code property of that error, "Z_MEM_ERROR", which the bundled zlib-streams 1.4.0 sets on its allocation failures and which the native DecompressionStream of Node.js would set. It is raised when reading an entry, both when the codec cannot allocate its state and when it fails while inflating, and when writing an entry whose codec cannot allocate its state; a failure while compressing keeps the error of the codec. Such a failure used to surface as the allocation failed error of the codec, so code matching that message should catch the constant instead

Bug fixes

• A zip file whose compressedSize overshoots the deflate stream of an entry, which the bundled codecs used to read by dropping the extra bytes, now fails on every codec, as it already did with a native DecompressionStream. The error is ERR_INVALID_COMPRESSED_DATA, with the error of the codec as the cause; on Node.js with checkCrc32 set it is ERR_INVALID_CRC32, since its native inflater reports the extra bytes only once the gzip trailer built by zip.js has been written. The bundled codecs are zlib-streams 1.4.0, the WebAssembly one, and zlib-streams-ts 1.2.0, the pure-JS one of the *-native builds
• A corrupted deflated entry rejects with ERR_INVALID_COMPRESSED_DATA whatever inflates it, with the error the codec raised as the cause: the TypeError of a native DecompressionStream, whose message depends on the engine, or the error of the bundled WebAssembly or pure-JS codec. Only the message-less error of Node.js used to be mapped, so the same corrupted zip file raised Invalid compressed data on Node.js, corrupt deflate stream on Deno, process error:-3 wherever the WebAssembly codec inflates, e.g. in a browser with useCompressionStream off, and inflate failed on Bun, and a caller comparing against the constant was right on Node.js only. An error raised while the data is being read, by the reader of the zip file or by the decryption of the entry, is not a codec failure and reaches the caller unchanged, with its own cause. On Safari and Bun, whose structured clone drops the cause of an error posted by a worker, the cause is rebuilt from its name and message
• With checkCrc32 set, a stored uncompressed size larger than the data now fails with ERR_INVALID_CRC32 instead of ERR_INVALID_UNCOMPRESSED_SIZE, on every codec, with the error of the inflater as the cause: the inflater verifies the checksum through a gzip trailer built from the stored CRC-32 and size, and rejects that trailer as a whole. With checkCrc32 off it is still ERR_INVALID_UNCOMPRESSED_SIZE, and a size smaller than the data is ERR_INVALID_UNCOMPRESSED_SIZE either way, as soon as the output exceeds it
• A signal aborted while an entry is being read by getData() or added by add() rejects the operation with the reason of the signal, whether the compressed data is still being consumed or the content still being written. The signal used to guard the pipe feeding the codec alone, so an abort landing once the input had been consumed, e.g. while a large content was still being written to the writer, was ignored and the operation completed. On the oldest supported engines, which ignore the signal option of pipeTo(), the data is written to the end before the operation is rejected
• With the passwords and requestPassword options of the filesystem API, the ERR_INVALID_PASSWORD error raised when every candidate has failed, or when requestPassword gives up, carries the error raised by the last candidate as its cause. A ZipCrypto entry whose read fails for a reason other than a false accept, i.e. a wrong password slipping past the one-byte header check of ZipCrypto, as one in 256 does, reports that failure instead of trying the next candidate: only ERR_INVALID_CRC32, ERR_INVALID_COMPRESSED_DATA and ERR_INVALID_UNCOMPRESSED_SIZE count as a wrong password, since such a password produces content that the CRC-32 check or the inflater rejects, while a failure of the reader, e.g. a network error, or an ERR_CODEC_OUT_OF_MEMORY error reaches the caller as-is. Any failure of the read used to count as a wrong password, so a reader failure surfaced as ERR_INVALID_PASSWORD once the candidates were exhausted. A corrupted entry read with the right password is still reported as a wrong password, since nothing tells it from a wrong password passing the check
• On Chrome before 103 or Node.js before 20.12, whose native inflater lacks "deflate-raw", when the WebAssembly codec cannot take over because its module failed to load, e.g. an *-external build deployed without zip-module.wasm next to it, an entry encrypted with AES that stores no CRC-32 (AE-2, what the writer emits for every encrypted entry) is inflated through a gzip container whose trailer carries the CRC-32 of the output received so far. A valid entry failed with ERR_INVALID_CRC32 now and then, more often on a loaded machine and on Node.js, because the trailer was written on a timing guess. It is now written once the inflater has returned everything, and the entry fails with ERR_INVALID_UNCOMPRESSED_SIZE when it inflates to fewer bytes as well as to more
• The same wrapper serves the checkCrc32 route on every host, where the rewrite costs about 3 µs per entry with the native codec, measured with the benchmark harness; the tables of BENCHMARKS.md are unchanged
• The WebAssembly codec (zlib-streams 1.4.0) and the pure-JS codec of the *-native builds (zlib-streams-ts 1.2.0) reject an unknown format with a TypeError when the stream is constructed, as the platform CompressionStream and DecompressionStream do; they used to treat it as "deflate". Nothing changes for a zip file; code that tests a format by constructing the stream now gets the right answer

Documentation

• ERR_INVALID_COMPRESSED_DATA, ERR_INVALID_CRC32 and ERR_INVALID_UNCOMPRESSED_SIZE document when they are raised, the cause they carry and the routes on which one is raised in place of another, the signal option of the reader and of the writer documents the abort landing during the output, and PasswordCandidatesOptions documents the errors counted as a wrong password and the cause of the final ERR_INVALID_PASSWORD

Tests and continuous integration

• New tests cover the corrupted deflated entry on every inflate route, with the native and the WebAssembly codecs, with and without workers and with and without checkCrc32, the bytes trailing a deflate stream, the memory failure of the codec on both sides with the heap of the WebAssembly module actually exhausted, the gzip route with a large AE-2 entry read several times, which is what caught the race, the abort landing during the output of a read and of a write, and the reader failure and the cause under the password candidates
• The password candidates fixture is generated until none of the wrong candidates passes the one-byte check of ZipCrypto by chance, which one in 256 did and failed a job on Chrome 87 once
• The README of the tests names both compression globals that the polyfill runner removes

Full Changelog: gildas-lormeau/zip.js@v2.16.1...v2.17.0

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

v2.16.1

What's Changed in v2.16.1

New features

• The filesystem API tries several passwords on an entry imported from a zip file when its data is read. The core ZipReader API keeps one password per reader or per call. The new passwords option lists the candidates, and the new requestPassword option is a function asked for a password when every candidate has failed, or when there is none: it is called with the entry being read and the error raised by the last candidate, it can return a promise, e.g. to prompt the user, and it gives up by returning undefined or null, in which case the entry fails with ERR_INVALID_PASSWORD, or with ERR_ENCRYPTED when nothing was tried. Both options are accepted by the import*() methods, by the readerOptions of the export*() methods and by the get*() methods of a file entry. The candidates are tried in order: the password or rawPassword option, then the passwords that already decrypted another entry of the same zip file, most recent first, then the passwords list, so the wrong candidates ahead of the right one are tried once for the archive, not once per entry. When several entries are read concurrently, e.g. by export*() with bufferedWrite, one requestPassword call is pending at a time, and the other entries try its answer before asking. With candidates in play, a ZipCrypto entry, whose one-byte check accepts one wrong password in 256, is checked on its header first without reading the content, the CRC-32 of the content is then verified whatever checkCrc32 says, and any failure of that read counts as a wrong password. An AES entry reports a failure of the read as-is. ERR_INVALID_PASSWORDS and ERR_INVALID_REQUEST_PASSWORD are thrown when the options have the wrong type, and the latter also when the function returns a value of another type
• An error raised while exporting because the data of an entry cannot be read now carries the entry as entry and its name relative to the exported directory as entryName, next to the entryId it already had, and keeps its own cause, e.g. the codec error behind ERR_INVALID_COMPRESSED_DATA for an entry imported from a corrupted zip file. The export used to replace the cause with an object holding the entry, a property that was not documented

Bug fixes

• A read or write of the WebAssembly codec torn down before the end of the entry, by a cancelled readable, an aborted signal, a failing source, a corrupted body or a wrong password, kept its two 64 KB buffers and its zlib state in the 16 MB heap of the module in every browser, because the codec freed them in the cancel() hook of a TransformStream transformer, which Node.js and Deno call and no browser does. That codec runs for deflate when useCompressionStream is false or the host has no native "deflate-raw", and its AES engine runs for the encrypted entries, whose contexts live in the same heap. About 120 aborted inflates or 40 aborted deflates exhausted the heap of the worker, or of the page without workers, and every later entry failed with allocation failed. The bundled zlib-streams 1.2.3 frees them on any teardown, the AES streams release their engine context the same way, and the wrappers of the entry stream cancel the codec when their own read fails. On a page that loads web-streams-polyfill, which Firefox below 102 needs, such a read used to error without cancelling the codec, so the pair stayed allocated for the life of the page
• An empty rawPassword, i.e. an empty Uint8Array, means no raw password, like an empty password string. Reading an encrypted entry with one used to wait forever for a key that was never derived, and writing an entry with one used to encrypt it with an empty key, so it could not be read back with the password string passed next to it

Documentation

• EntryError documents its entry property, and ERR_DUPLICATE_IMPORTED_ENTRY documents that its cause.entry holds the EntryMetaData of the entry that could not be imported

Tests and continuous integration

... (truncated)

Commits

• 1eb4b7e bump up version
• a755b73 vendor the codecs rejecting an unknown format
• 8d0d7f6 keep the password fixture free of chance false accepts
• 1f5c03f fix the gzip trailer race and abort during the output
• 3fde127 keep a zipcrypto read failure unless a false accept explains it
• b69583c report a codec memory failure as codec out of memory
• 178c453 report an inflater trailer rejection as a crc32 error
• 949010a reject bytes trailing a deflate stream in the bundled codecs
• abfc267 rebuild the cause of a worker error when the clone drops it
• f38fc79 report every inflate codec failure as invalid compressed data
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)