[stable33] chore(deps-dev): bump @zip.js/zip.js from 2.11.2 to 2.15.0

[dependabot]

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

Release notes

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

v2.15.0

What's Changed in v2.15.0

New features

• A filename or comment stored without the UTF-8 flag is decoded as UTF-8 when its bytes are valid UTF-8 and no filenameEncoding or commentEncoding option is set, instead of IBM Code Page 437. macOS Archive Utility, ditto, the macOS build of Info-ZIP zip and Java 6 write such names, which read back as mojibake until now while 7-Zip, libarchive and jar show them right. Pure ASCII names are unchanged, an explicit encoding option disables the detection, and a valid Info-ZIP Unicode Path extra field still wins
• The WebAssembly deflate runs in gzip mode and reads the CRC-32 of the entry from the trailer, as the native CompressionStream route already did, so the separate CRC-32 pass over the input on the JavaScript thread is gone for that codec: about 1 % of the time of a 20 MB text entry on Node.js. On the native-only build, the route wrapping gzip where deflate-raw is missing reuses the CRC-32 it computes for the trailer instead of running a second pass

Bug fixes

• filenameValidation rejects, under "balanced", a ".." path component delimited by backslashes ("..\\file.txt", which a Windows host resolves as a parent directory) and a name starting with a single backslash (a root-relative or UNC path on Windows), and under "strict" a name holding a NUL character. A backslash is otherwise still a valid filename character
• A custom Reader whose readUint8Array returns a Node.js Buffer reads archives again. The end of central directory record was kept as Buffer#slice(...).buffer, a view on the whole scan window or on the Buffer pool, so its fields were read from the wrong bytes and every archive failed with ERR_SPLIT_ZIP_FILE or "File format is not recognized", since 2.8.30
• Retaining an Entry no longer retains the whole central directory (#682). rawFilename, rawExtraField and rawComment were views on the buffer holding the directory, as was the digital signature, so one entry kept alive pinned the metadata of every other one, 3.9 MB in the reporter's archive, and the .buffer of those fields exposed the reader's buffer, e.g. a Node.js Buffer pool. Each entry now owns one copy of its three fields
• terminateWorkers() runs in-process the requests queued while every worker slot was busy and resolves once they have finished. A request queued behind the call used to get a fresh worker after the call had resolved, so a ZipReader reading two entries at once with maxWorkers: 1 kept a worker alive past the call, and the WebAssembly builds reset the module under it. Writers were not affected: every add() waits for a slot before asking the pool

Documentation

• checkAmbiguity documents that duplicate filenames are compared exactly, after normalizeFilename: two names differing by letter case or by Unicode normalization form are distinct entries, even though they collide on a case-insensitive or normalizing filesystem
• BENCHMARKS.md states what the rows of a fresh process include, the JIT warm-up of each library and, for the WebAssembly rows, the module instantiation of about 20 ms, and that no decompression row verifies the CRC-32: zip.js and jszip leave the check off by default and fflate has none on read. Turning it on in zip.js adds one pass over the output, about 15 ms per 20 MB

Build

• The worker and WebAssembly modules embedded in the bundles are minified without property mangling before the main bundles mangle them, so the mangled-name guard no longer reports a spurious single-letter name on every regeneration. The bundles are unchanged within a few bytes

Tests and continuous integration

• New tests pin the unflagged UTF-8 names (zip.js's own useUnicodeFileNames: false output, a CP437 name, an explicit filenameEncoding winning and a real ditto archive), the ownership of the raw metadata against a pooled reader, the gzip trailer on the WebAssembly codec with the routes asserted through spies, the termination with a queued request, the clamped date warning under every timestamp option combination, the exact exported size when no deflate implementation is reachable, and the three worker options read as truthy values

Full Changelog: gildas-lormeau/zip.js@v2.14.1...v2.15.0

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

v2.14.1

What's Changed in v2.14.1

New features

• AES encryption and decryption run faster on every build. The JavaScript engine unrolls the AES rounds and the SHA-1 steps: a stored AES-256 entry goes from 91 to 114 MB/s on Node.js, from 55 to 68 MB/s in Firefox and from 77 to 100 MB/s in Chrome. The WebAssembly builds ship zlib-streams 1.2.1, whose AES-CTR/HMAC-SHA1 kernel got the same treatment from @​xqdoo00o: 111 to 131 MB/s on Node.js, 87 to 96 MB/s in Firefox and 99 to 118 MB/s in Chrome. The default bundle grows by 3.5 KB gzipped, the native build by 1.5 KB and the core build by 1 KB

Bug fixes

• checkOverlappingEntry compares the range of an entry with its two neighbours by offset instead of with every entry read before it, so reading an archive with the check on is no longer quadratic in its entry count: 16,000 entries take 75 ms instead of 551 ms. The check is meant for untrusted archives, where the entry count is the attacker's choice
• checkOverlappingEntryOnly no longer opens the entry data. On HttpRangeReader it issued a range request for the whole compressed payload of every entry it checked, and never read the response
• Every terminateWorkers() call made while a codec runs is resolved when the codec ends. A second call on the same busy codec used to replace the resolver of the first one, so the first promise never settled, and the WebAssembly builds have awaited it since 2.14.0
• The WebAssembly codec wrapper copies each produced chunk straight out of the module memory instead of through a 64 KB staging buffer allocated per stream

Documentation

• BENCHMARKS.md is rewritten from measurements on 2.14.0: every table names the codec each library runs, the zip.js rows cover CompressionStream, the WebAssembly zlib and the pure-JavaScript port, a runtime harness compares Node.js, Bun and Deno, jszip streams in the disk-to-disk comparison, and the 7-Zip and library-picking sections are gone
• The encryption tables are re-measured with the new engines, and the decompression section explains the memory gap between the backends on 5,000 small entries: the three zip.js rows allocate the same 800 MB of stream objects, and the higher peaks of the WebAssembly and pure-JavaScript rows come from V8's incremental marking on a codec running on the JavaScript thread

... (truncated)

Commits

• 307b756 bump up version
• 68ced40 skip the fallback spy check where the native codec lacks deflate-raw
• c0e9e7a cover the clamped date, no-deflate size and truthy worker options
• a62b3cb run requests queued before terminateWorkers in-process
• 61f0964 minify the inline modules without mangling their properties
• 4a4a0e9 note the cold start and the crc check in benchmarks
• dbe5823 reuse the gzip crc-32 on the wasm deflate and inflate fallback
• 0d72aeb copy the digital signature out of the directory buffer
• 5b2558b copy central directory metadata per entry
• 81420e5 copy the end of central directory record before reading it
• 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)