v2.8.56

What's Changed in v2.8.56

Bug fixes

• The compression method stored in the WinZip AES extra field is no longer truncated to its low byte. The field declares the actual compression method of an encrypted entry in a 16-bit slot, and it was written with a single byte store. An encrypted entry using a method above 255, which a codec registered with registerCodec can use, announced a different method, so readers selected the wrong codec after decrypting. Registered codecs exist since v2.8.37
• Writing an entry with the usdz option now throws ERR_INVALID_EXTRAFIELD_DATA when the extra field could exceed 64KB once the alignment padding is added. The padding is computed after the length check and adds up to 67 bytes, so an extra field close to the limit wrapped the 16-bit length field and produced a corrupt entry
• The central directory written by ZipWriter#prependZip now points at the prepended entries when the writer has an initial offset. The offsets were computed from the source archive alone, so an archive written with the offset option, or into a writer already holding data, declared offsets short by that initial offset and the prepended entries could not be read back. The two features could be combined since v2.7.71
• The digital signature record is now written within a single segment of a split archive. It could start at the end of one segment and continue in the next, unlike every other record, because only the end of central directory record checked the remaining space before being written. The writer now closes the disk first for the signature record as well. Signing is available since v2.8.47
• ZipReader#digitalSignature is now defined on a split archive whose central directory starts on an earlier disk than the end of central directory record. The reader looked for the record in the bytes read for the central directory, which stop at the declared directory length in that case, so the signature was never found. The record is now read from the file when it does not follow the directory in those bytes
• ZipDirectoryEntry#getExportedSize now throws ERR_UNDETERMINED_SIZE when the predicted size depends on the order the entries are written. The zip64 fields of an entry depend on its offset, so when the entries total more than 4GB and the write order is not guaranteed, e.g. keepOrder set to false, two orders can produce two sizes. The detection walked the entries in enumeration order, so it missed layouts where only another order crosses the threshold, and the exported archive could differ from the prediction. The prediction is available since v2.8.52
• ZipDirectoryEntry#getExportedSize now honors the offset option. The option shifts the offsets stored in the central directory, which select the zip64 fields, and the prediction computed them from zero. Predicting an export with offset at 4GB or above returned a size short by the zip64 records the export actually writes

Documentation

• CodecDefinition#codecURI now states that bundlers and single-file builds, e.g. deno compile, cannot follow the dynamic import of the codec module, so the module must be included explicitly, with deno compile --include or the equivalent option of the bundler

Tests and continuous integration

• Every fix above is locked by a regression test: an encrypted round trip with a registered method above 255, a usdz entry with an extra field near the 64KB limit, prependZip into a writer with an initial offset, a sweep of segment sizes checking the placement and the read back of the digital signature record on split archives, and size predictions with order-dependent zip64 layouts and with the offset option