chore(deps): Bump the minor-deps-updates-main group with 2 updates

[dependabot]

Bumps the minor-deps-updates-main group with 2 updates: oxlint and @zip.js/zip.js.

Updates oxlint from 1.83.0 to 1.85.0

Release notes

Sourced from oxlint's releases.

oxlint v1.85.0

🚀 Features

• 415b742 oxlint,oxfmt: Do not discover nested config in Vite+ mode (#26763) (leaysgur)

Commits

• 288d8cc release(apps): oxlint v1.85.0 && oxfmt v0.70.0 (#26903)
• f02a64a release(apps): oxlint v1.84.0 && oxfmt v0.69.0 (#26874)
• See full diff in compare view

Updates @zip.js/zip.js from 2.16.0 to 2.18.2

Release notes

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

v2.18.2

What's Changed in v2.18.2

Bug fixes

• With checkOverlappingEntry set, a data descriptor whose CRC-32 disagrees with the central directory, a corrupt CRC-32 for instance, is now reported in localDirectory.dataDescriptor with its own fields, its CRC-32 differing from entry.crc32 as LocalDataDescriptor#crc32 documents. Until now the signed layout was kept only when its CRC-32 and sizes agreed with the central directory, since 2.18.1 among 4- or 8-byte sizes, and otherwise the record was read at the width the Zip64 extra field of either record announces without the signature, i.e. at a layout known not to match, so a signed descriptor with a corrupt CRC-32 came back with signature false, the signature bytes as crc32 and its sizes shifted by four bytes. The layout is now the one whose sizes agree with the central directory, its CRC-32 breaking ties when the central directory stores one; when no layout agrees, the record is read at the announced width as before, with the signature when it starts with one. The tie-break applies to AES entries that store a CRC-32 (AE-1, what WinZip writes for most files) like to any other entry; the CRC-32 of an AES entry used to be ignored. Reading the data of the entry is unchanged, and reading without checkOverlappingEntry never consulted the descriptor

Documentation

• The remarks of LocalDataDescriptor#signature and LocalDataDescriptor#zip64 describe how the layout is chosen

Tests and continuous integration

• The data descriptor width test now reads a signed descriptor whose CRC-32 alone is corrupt and one whose compressed size is corrupt, and a new test writes an AE-2 entry with a signed data descriptor, patches it into an AE-1 entry with a disagreeing and then an agreeing descriptor CRC-32, and checks the layout reported for each and for the AE-2 entry

Full Changelog: gildas-lormeau/zip.js@v2.18.1...v2.18.2

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

v2.18.1

What's Changed in v2.18.1

New features

• LocalDataDescriptor has a zip64 property, true when the sizes of the data descriptor read with checkOverlappingEntry are stored as 8-byte values

Bug fixes

• With checkOverlappingEntry set, an entry placed past 4 GB whose data descriptor stores 4-byte sizes now reads; getData() used to fail with ERR_UNSUPPORTED_UINT64. The width of the sizes was taken from the presence of a Zip64 extra field in either record, but neither record tells it reliably: the local file header is written before a streaming writer knows the sizes, and the Zip64 extra field of the central directory record, written last, describes that record, not the descriptor. Go's archive/zip, for instance, gives a small entry placed past 4 GB a Zip64 extra field in its central directory record for the offset alone and a 4-byte descriptor, while its large streamed entries get an 8-byte descriptor with no local Zip64 extra field, which is why the central directory record was consulted; the descriptor of the small entry was therefore read as 8 bytes wide, across the next record. The descriptor is now read with the layout, among the two widths with and without the signature, whose CRC-32, when the entry stores one, and sizes agree with the central directory; when none does, it is read at the width the Zip64 extra field of either record announces, without the signature, as before. Reading without checkOverlappingEntry never depended on the descriptor and is unchanged

Tests and continuous integration

• A new test builds the archives by hand, behind a reader that fakes a 4 GB prefix so the offsets are real, and reads a 4-byte descriptor below and past 4 GB, signed and unsigned, and an 8-byte descriptor whose Zip64 extra field is in the central directory only or in neither record, each in both read orders, and a descriptor agreeing with no layout

Full Changelog: gildas-lormeau/zip.js@v2.18.0...v2.18.1

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

v2.18.0

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

... (truncated)

Commits

• dd9e5b4 choose the descriptor layout by its sizes, crc32 breaking ties
• 24f1a40 bump up version
• caf7dbe compare the descriptor crc32 whenever the central directory stores one
• 07cb717 fix the wording of the data descriptor width remark
• b8508b0 bump up version
• 737aa2b read the data descriptor with the layout matching the central directory
• 3b17c72 bump up version
• 3fe78a8 gate the worker cause test on module workers
• e2aa07a keep the cause code across workers and report missing zip64 fields
• a0f59dd compare the strong encryption bit between both records
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually 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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions