conductor-oss 0.15.0 → 0.15.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "conductor-oss",
-  "version": "0.15.0",
+  "version": "0.15.2",
   "license": "MIT",
   "type": "module",
   "main": "dist/launcher.js",
@@ -33,7 +33,7 @@
     "directory": "packages/cli"
   },
   "dependencies": {
-    "@conductor-oss/core": "0.15.0",
+    "@conductor-oss/core": "0.15.2",
     "chalk": "^5.6.2",
     "commander": "^14.0.3",
     "ora": "^9.3.0",
@@ -67,9 +67,9 @@
     "tailwind-merge": "^3.5.0"
   },
   "optionalDependencies": {
-    "conductor-oss-native-darwin-universal": "0.15.0",
-    "conductor-oss-native-linux-x64": "0.15.0",
-    "conductor-oss-native-win32-x64": "0.15.0"
+    "conductor-oss-native-darwin-universal": "0.15.2",
+    "conductor-oss-native-linux-x64": "0.15.2",
+    "conductor-oss-native-win32-x64": "0.15.2"
   },
   "files": [
     "dist/",

package/web/.next/standalone/node_modules/yauzl/README.md

@@ -1,8 +1,5 @@
 # yauzl
 
-[![Build Status](https://travis-ci.org/thejoshwolfe/yauzl.svg?branch=master)](https://travis-ci.org/thejoshwolfe/yauzl)
-[![Coverage Status](https://img.shields.io/coveralls/thejoshwolfe/yauzl.svg)](https://coveralls.io/r/thejoshwolfe/yauzl)
-
 yet another unzip library for node. For zipping, see
 [yazl](https://github.com/thejoshwolfe/yazl).
 
@@ -32,7 +29,7 @@ yauzl.open("path/to/file.zip", {lazyEntries: true}, function(err, zipfile) {
   zipfile.on("entry", function(entry) {
     if (/\/$/.test(entry.fileName)) {
       // Directory file names end with '/'.
-      // Note that entires for directories themselves are optional.
+      // Note that entries for directories themselves are optional.
       // An entry's fileName implicitly requires its parent directories to exist.
       zipfile.readEntry();
     } else {
@@ -150,10 +147,36 @@ See `open()` for the meaning of the options and callback.
 
 ### dosDateTimeToDate(date, time)
 
-Converts MS-DOS `date` and `time` data into a JavaScript `Date` object.
-Each parameter is a `Number` treated as an unsigned 16-bit integer.
-Note that this format does not support timezones,
-so the returned object will use the local timezone.
+*Deprecated*. Since yauzl 3.2.0, it is highly recommended to call [`entry.getLastModDate()`](#getlastmoddateoptions)
+instead of this function due to enhanced support for reading third-party extra fields.
+If you ever have a use case for calling this function directly please
+[open an issue against yauzl](https://github.com/thejoshwolfe/yauzl/issues/new)
+requesting that this function be properly supported again.
+
+This function only remains exported in order to maintain compatibility with older versions of yauzl.
+It will be removed in yauzl 4.0.0 unless someone asks for it to remain supported.
+
+### getFileNameLowLevel(generalPurposeBitFlag, fileNameBuffer, extraFields, strictFileNames)
+
+If you are setting `decodeStrings` to `false`, then this function can be used to decode the file name yourself.
+This function is effectively used internally by yauzl to populate the `entry.fileName` field when `decodeStrings` is `true`.
+
+WARNING: This method of getting the file name bypasses the security checks in [`validateFileName()`](#validatefilename-filename).
+You should call that function yourself to be sure to guard against malicious file paths.
+
+`generalPurposeBitFlag` can be found on an [`Entry`](#class-entry) or [`LocalFileHeader`](#class-localfileheader).
+Only General Purpose Bit 11 is used, and only when an Info-ZIP Unicode Path Extra Field cannot be found in `extraFields`.
+
+`fileNameBuffer` is a `Buffer` representing the file name field of the entry.
+This is `entry.fileNameRaw` or `localFileHeader.fileName`.
+
+`extraFields` is the parsed extra fields array from `entry.extraFields` or `parseExtraFields()`.
+
+`strictFileNames` is a boolean, the same as the option of the same name in `open()`.
+When `false`, backslash characters (`\`) will be replaced with forward slash characters (`/`).
+
+This function always returns a string, although it may not be a valid file name.
+See `validateFileName()`.
 
 ### validateFileName(fileName)
 
@@ -169,6 +192,18 @@ if (errorMessage != null) throw new Error(errorMessage);
 This function is automatically run for each entry, as long as `decodeStrings` is `true`.
 See `open()`, `strictFileNames`, and `Event: "entry"` for more information.
 
+### parseExtraFields(extraFieldBuffer)
+
+This function is used internally by yauzl to compute [`entry.extraFields`](#extrafields).
+It is exported in case you want to call it on [`localFileHeader.extraField`](#class-localfileheader).
+
+`extraFieldBuffer` is a `Buffer`, such as `localFileHeader.extraField`.
+Returns an `Array` with each item in the form `{id: id, data: data}`,
+where `id` is a `Number` and `data` is a `Buffer`.
+Throws an `Error` if the data encodes an item with a size that exceeds the bounds of the buffer.
+
+You may want to surround calls to this function with `try { ... } catch (err) { ... }` to handle the error.
+
 ### Class: ZipFile
 
 The constructor for the class is not part of the public API.
@@ -265,7 +300,7 @@ The `start` (inclusive) and `end` (exclusive) options are byte offsets into this
 and can be used to obtain part of an entry's file data rather than the whole thing.
 If either of these options are specified and non-`null`,
 then the above options must be used to obain the file's raw data.
-Speficying `{start: 0, end: entry.compressedSize}` will result in the complete file,
+Specifying `{start: 0, end: entry.compressedSize}` will result in the complete file,
 which is effectively the default values for these options,
 but note that unlike omitting the options, when you specify `start` or `end` as any non-`null` value,
 the above requirement is still enforced that you must also pass the appropriate options to get the file's raw data.
@@ -287,9 +322,59 @@ It is possible to destroy the `readStream` before it has piped all of its data.
 To do this, call `readStream.destroy()`.
 You must `unpipe()` the `readStream` from any destination before calling `readStream.destroy()`.
 If this zipfile was created using `fromRandomAccessReader()`, the `RandomAccessReader` implementation
-must provide readable streams that implement a `.destroy()` method (see `randomAccessReader._readStreamForRange()`)
+must provide readable streams that implement a `._destroy()` method according to
+https://nodejs.org/api/stream.html#writable_destroyerr-callback (see `randomAccessReader._readStreamForRange()`)
 in order for calls to `readStream.destroy()` to work in this context.
 
+#### readLocalFileHeader(entry, [options], callback)
+
+This is a low-level function you probably don't need to call.
+The intended use case is either preparing to call `openReadStreamLowLevel()`
+or simply examining the content of the local file header out of curiosity or for debugging zip file structure issues.
+
+`entry` is an entry obtained from `Event: "entry"`.
+An `entry` in this library is a file's metadata from a Central Directory Header,
+and this function gives the corresponding redundant data in a Local File Header.
+
+`options` may be omitted or `null`, and has the following defaults:
+
+```js
+{
+  minimal: false,
+}
+```
+
+If `minimal` is `false` (or omitted or `null`), the callback receives a full [`LocalFileHeader`](#class-localfileheader).
+If `minimal` is `true`, the callback receives an object with a single property and no prototype `{fileDataStart: fileDataStart}`.
+For typical zipfile reading usecases, this field is the only one you need,
+and yauzl internally effectively uses the `{minimal: true}` option as part of `openReadStream()`.
+
+The `callback` receives `(err, localFileHeaderOrAnObjectWithJustOneFieldDependingOnTheMinimalOption)`,
+where the type of the second parameter is described in the above discussion of the `minimal` option.
+
+#### openReadStreamLowLevel(fileDataStart, compressedSize, relativeStart, relativeEnd, decompress, uncompressedSize, callback)
+
+This is a low-level function available for advanced use cases. You probably want `openReadStream()` instead.
+
+The intended use case for this function is calling `readEntry()` and `readLocalFileHeader()` with `{minimal: true}` first,
+and then opening the read stream at a later time, possibly after closing and reopening the entire zipfile,
+possibly even in a different process.
+The parameters are all integers and booleans, which are friendly to serialization.
+
+* `fileDataStart` - from `localFileHeader.fileDataStart`
+* `compressedSize` - from `entry.compressedSize`
+* `relativeStart` - the resolved value of `options.start` from `openReadStream()`. Must be a non-negative integer, not `null`. Typically `0` to start at the beginning of the data.
+* `relativeEnd` - the resolved value of `options.end` from `openReadStream()`. Must be a non-negative integer, not `null`. Typically `entry.compressedSize` to include all the data.
+* `decompress` - boolean indicating whether the data should be piped through a zlib inflate stream.
+* `uncompressedSize` - from `entry.uncompressedSize`. Only used when `validateEntrySizes` is `true`. If `validateEntrySizes` is `false`, this value is ignored, but must still be present, not omitted, in the arguments; you have to give it some value, even if it's `null`.
+* `callback` - receives `(err, readStream)`, the same as for `openReadStream()`
+
+This low-level function does not read any metadata from the underlying storage before opening the read stream.
+This is both a performance feature and a safety hazard.
+None of the integer parameters are bounds checked.
+None of the validation from `openReadStream()` with respect to compression and encryption is done here either.
+Only the bounds checks from `validateEntrySizes` are done, because that is part of processing the stream data.
+
 #### close()
 
 Causes all future calls to `openReadStream()` to fail,
@@ -340,18 +425,31 @@ These fields are of type `Number`:
  * `versionNeededToExtract`
  * `generalPurposeBitFlag`
  * `compressionMethod`
- * `lastModFileTime` (MS-DOS format, see `getLastModDateTime`)
- * `lastModFileDate` (MS-DOS format, see `getLastModDateTime`)
+ * `lastModFileTime` (MS-DOS format, see [`getLastModDate()`](#getlastmoddateoptions))
+ * `lastModFileDate` (MS-DOS format, see [`getLastModDate()`](#getlastmoddateoptions))
  * `crc32`
  * `compressedSize`
  * `uncompressedSize`
- * `fileNameLength` (bytes)
- * `extraFieldLength` (bytes)
- * `fileCommentLength` (bytes)
+ * `fileNameLength` (in bytes)
+ * `extraFieldLength` (in bytes)
+ * `fileCommentLength` (in bytes)
  * `internalFileAttributes`
  * `externalFileAttributes`
  * `relativeOffsetOfLocalHeader`
 
+These fields are of type `Buffer`, and represent variable-length bytes before being processed:
+ * `fileNameRaw`
+ * `extraFieldRaw`
+ * `fileCommentRaw`
+
+There are additional fields described below: `fileName`, `extraFields`, `fileComment`.
+These are the processed versions of the `*Raw` fields listed above. See their own sections below.
+(Note the inconsistency in pluralization of "field" vs "fields" in `extraField`, `extraFields`, and `extraFieldRaw`.
+Sorry about that.)
+
+The `new Entry()` constructor is available for clients to call, but it's usually not useful.
+The constructor takes no parameters and does nothing; no fields will exist.
+
 #### fileName
 
 `String`.
@@ -369,7 +467,7 @@ Furthermore, no automatic file name validation is performed for this file name.
 
 #### extraFields
 
-`Array` with each entry in the form `{id: id, data: data}`,
+`Array` with each item in the form `{id: id, data: data}`,
 where `id` is a `Number` and `data` is a `Buffer`.
 
 This library looks for and reads the ZIP64 Extended Information Extra Field (0x0001)
@@ -379,12 +477,11 @@ This library also looks for and reads the Info-ZIP Unicode Path Extra Field (0x7
 in order to support some zipfiles that use it instead of General Purpose Bit 11
 to convey `UTF-8` file names.
 When the field is identified and verified to be reliable (see the zipfile spec),
-the the file name in this field is stored in the `fileName` property,
+the file name in this field is stored in the `fileName` property,
 and the file name in the central directory record for this entry is ignored.
 Note that when `decodeStrings` is false, all Info-ZIP Unicode Path Extra Fields are ignored.
 
-None of the other fields are considered significant by this library.
-Fields that this library reads are left unalterned in the `extraFields` array.
+See also [`getLastModDate()`](#getlastmoddateoptions) for additional extra fields that are recognized by this library.
 
 #### fileComment
 
@@ -397,14 +494,46 @@ Prior to yauzl version 2.7.0, this field was erroneously documented as `comment`
 For compatibility with any code that uses the field name `comment`,
 yauzl creates an alias field named `comment` which is identical to `fileComment`.
 
-#### getLastModDate()
+#### getLastModDate([options])
 
-Effectively implemented as:
+Returns the modification time of the file as a JavaScript `Date` object.
+The timezone situation is a mess; read on to learn more.
+
+Due to the zip file specification having lackluster support for specifying timestamps natively,
+there are several third-party extensions that add better support.
+yauzl supports these encodings:
+
+1. Info-ZIP "universal timestamp" extended field (`0x5455` aka `"UT"`): signed 32-bit seconds since `1970-01-01 00:00:00Z`, which supports the years 1901-2038 (partially inclusive) with 1-second precision. The value is timezone agnostic, i.e. always UTC.
+2. NTFS extended field (`0x000a`): 64-bit signed 100-nanoseconds since `1601-01-01 00:00:00Z`, which supports the approximate years 20,000BCE-20,000CE with precision rounded to 1-millisecond (due to the JavaScript `Date` type). The value is timezone agnostic, i.e. always UTC.
+3. DOS `lastModFileDate` and `lastModFileTime`: supports the years 1980-2108 (inclusive) with 2-second precision. Timezone is interpreted either as the local timezone or UTC depending on the `timezone` option documented below.
+
+If both the Info-ZIP "universal timestamp" and NTFS extended fields are found, yauzl uses one of them, but which one is unspecified.
+If neither are found, yauzl falls back to the built-in DOS `lastModFileDate` and `lastModFileTime`.
+Every possible bit pattern of every encoding can be represented by a JavaScript `Date` object,
+meaning this function cannot fail (barring parameter validation), and will never return an `Invalid Date` object.
+
+`options` may be omitted or `null`, and has the following defaults:
 
 ```js
-return dosDateTimeToDate(this.lastModFileDate, this.lastModFileTime);
+{
+  timezone: "local", // or "UTC"
+  forceDosFormat: false,
+}
 ```
 
+Set `forceDosFormat` to `true` (and do not set `timezone`) to enable pre-yauzl 3.2.0 behavior
+where the Info-ZIP "universal timestamp" and NTFS extended fields are ignored.
+
+The `timezone` option is only used in the DOS fallback.
+If `timezone` is omitted, `null` or `"local"`, the `lastModFileDate` and `lastModFileTime` are interpreted in the system's current timezone (using `new Date(year, ...)`).
+If `timezone` is `"UTC"`, the interpretation is in UTC+00:00 (using `new Date(Date.UTC(year, ...))`).
+
+The JavaScript `Date` object, has several inherent limitations surrounding timezones.
+There is an ECMAScript proposal to add better timezone support to JavaScript called the `Temporal` API.
+Last I checked, it was at stage 3. https://github.com/tc39/proposal-temporal
+Once that new API is available and stable, better timezone handling should be possible here somehow.
+If you notice that the new API has become widely available, please open a feature request against this library to add support for it.
+
 #### isEncrypted()
 
 Returns is this entry encrypted with "Traditional Encryption".
@@ -428,6 +557,35 @@ return this.compressionMethod === 8;
 
 See `openReadStream()` for the implications of this value.
 
+### Class: LocalFileHeader
+
+This is a trivial class that has no methods and only the following properties.
+The constructor is available to call, but it doesn't do anything.
+See `readLocalFileHeader()`.
+
+See the zipfile spec for what these fields mean.
+
+ * `fileDataStart` - `Number`: inferred from `fileNameLength`, `extraFieldLength`, and this struct's position in the zipfile.
+ * `versionNeededToExtract` - `Number`
+ * `generalPurposeBitFlag` - `Number`
+ * `compressionMethod` - `Number`
+ * `lastModFileTime` - `Number`
+ * `lastModFileDate` - `Number`
+ * `crc32` - `Number`
+ * `compressedSize` - `Number`
+ * `uncompressedSize` - `Number`
+ * `fileNameLength` - `Number`
+ * `extraFieldLength` - `Number`
+ * `fileName` - `Buffer`
+ * `extraField` - `Buffer`
+
+Note that unlike `Class: Entry`, the `fileName` and `extraField` are completely unprocessed.
+This notably lacks Unicode and ZIP64 handling as well as any kind of safety validation on the file name.
+See also [`parseExtraFields()`](#parseextrafields-extrafieldbuffer).
+
+Also note that if your object is missing some of these fields,
+make sure to read the docs on the `minimal` option in `readLocalFileHeader()`.
+
 ### Class: RandomAccessReader
 
 This class is meant to be subclassed by clients and instantiated for the `fromRandomAccessReader()` function.
@@ -451,11 +609,11 @@ Any errors emitted on the readable stream will be handled and re-emitted on the
 (returned from `zipfile.openReadStream()`) or provided as the `err` argument to the appropriate callback
 (for example, for `fromRandomAccessReader()`).
 
-The returned stream *must* implement a method `.destroy()`
-if you call `readStream.destroy()` on streams you get from `openReadStream()`.
-If you never call `readStream.destroy()`, then streams returned from this method do not need to implement a method `.destroy()`.
-`.destroy()` should abort any streaming that is in progress and clean up any associated resources.
-`.destroy()` will only be called after the stream has been `unpipe()`d from its destination.
+If you call `readStream.destroy()` on streams you get from `openReadStream()`,
+the returned stream *must* implement a method `._destroy()` according to https://nodejs.org/api/stream.html#writable_destroyerr-callback .
+If you never call `readStream.destroy()`, then streams returned from this method do not need to implement a method `._destroy()`.
+`._destroy()` should abort any streaming that is in progress and clean up any associated resources.
+`._destroy()` will only be called after the stream has been `unpipe()`d from its destination.
 
 Note that the stream returned from this method might not be the same object that is provided by `openReadStream()`.
 The stream returned from this method might be `pipe()`d through one or more filter streams (for example, a zlib inflate stream).
@@ -491,6 +649,18 @@ Minor version updates to yauzl will not add any additional requirements to this
 
 ## Limitations
 
+The automated tests for this project run on node versions 12 and up. Older versions of node are not supported.
+
+### Files corrupted by the Mac Archive Utility are not my problem
+
+For a lengthy discussion, see [issue #69](https://github.com/thejoshwolfe/yauzl/issues/69).
+In summary, the Mac Archive Utility is buggy when creating large zip files,
+and this library does not make any effort to work around the bugs.
+This library will attempt to interpret the zip file data at face value,
+which may result in errors, or even silently incomplete data.
+If this bothers you, that's good! Please complain to Apple. :)
+I have accepted that this library will simply not support that nonsense.
+
 ### No Streaming Unzip API
 
 Due to the design of the .zip file format, it's impossible to interpret a .zip file from start to finish
@@ -526,7 +696,7 @@ By using General Purpose Bit 3 (and compression method 0),
 it's possible to create arbitrarily ambiguous .zip files that
 distract parsers with file contents that contain apparently valid .zip file metadata.
 
-### Limitted ZIP64 Support
+### Limited ZIP64 Support
 
 For ZIP64, only zip files smaller than `8PiB` are supported,
 not the full `16EiB` range that a 64-bit integer should be able to index.
@@ -603,8 +773,46 @@ Zip files officially support charset encodings other than CP437 and UTF-8,
 but the zip file spec does not specify how it works.
 This library makes no attempt to interpret the Language Encoding Flag.
 
+### How Ambiguities Are Handled
+
+The zip file specification has several ambiguities inherent in its design. Yikes!
+
+* The `.ZIP file comment` must not contain the `end of central dir signature` bytes `50 4b 05 06`. This corresponds to the text `"PK☺☻"` in CP437. While this is allowed by the specification, yauzl will hopefully reject this situation with an "Invalid comment length" error. However, in some situations unpredictable incorrect behavior will ensue, which will probably manifest in either an invalid signature error or some kind of bounds check error, such as "Unexpected EOF".
+* In non-ZIP64 files, the last central directory header must not have the bytes `50 4b 06 07` (`"PK♠•"` in CP437) exactly 20 bytes from its end, which might be in the `file name`, the `extra field`, or the `file comment`. The presence of these bytes indicates that this is a ZIP64 file.
+
 ## Change History
 
+ * 3.2.1
+   * Fix crash when reading certain corrupted NTFS timestamp extra fields. Thanks to CodeAnt AI Code Reviewer ( https://www.codeant.ai/ai-code-review ) for finding the bug.
+ * 3.2.0
+   * Added support for reading third-party extensions for timestamps: Info-ZIP "universal timestamp" extra field and NTFS extra field. [pull #160](https://github.com/thejoshwolfe/yauzl/pull/160)
+   * `entry.getLastModDate()` takes options `forceDosFormat` to revert the above change, and `timezone` to allow UTC interpretation of DOS timestamps.
+   * Documented `dosDateTimeToDate()` as now deprecated.
+ * 3.1.3
+   * Fixed a crash when using `fromBuffer()` to read corrupt zip files that specify out of bounds file offsets. [issue #156](https://github.com/thejoshwolfe/yauzl/pull/156)
+   * Enahnced the test suite to run the error tests through `fromBuffer()` and `fromRandomAccessReader()` in addition to `open()`, which would have caught the above.
+ * 3.1.2
+   * Fixed handling non-64 bit entries (similar to the version 3.1.1 fix) that actually have exactly 0xffffffff values in the fields. This fixes erroneous "expected zip64 extended information extra field" errors. [issue #109](https://github.com/thejoshwolfe/yauzl/pull/109)
+ * 3.1.1
+   * Fixed handling non-64 bit files that actually have exactly 0xffff or 0xffffffff values in End of Central Directory Record. This fixes erroneous "invalid zip64 end of central directory locator signature" errors. [issue #108](https://github.com/thejoshwolfe/yauzl/pull/108)
+   * Fixed handling of 64-bit zip files that put 0xffff or 0xffffffff in every field overridden in the Zip64 end of central directory record even if the value would have fit without overflow. In particular, this fixes an incorrect "multi-disk zip files are not supported" error. [pull #118](https://github.com/thejoshwolfe/yauzl/pull/118)
+ * 3.1.0
+   * Added `readLocalFileHeader()` and `Class: LocalFileHeader`.
+   * Added `openReadStreamLowLevel()`.
+   * Added `getFileNameLowLevel()` and `parseExtraFields()`.
+     Added fields to `Class: Entry`: `fileNameRaw`, `extraFieldRaw`, `fileCommentRaw`.
+   * Added `examples/compareCentralAndLocalHeaders.js` that demonstrate many of these low level APIs.
+   * Noted dropped support of node versions before 12 in the `"engines"` field of `package.json`.
+   * Fixed a crash when calling `openReadStream()` with an explicitly `null` options parameter (as opposed to omitted).
+ * 3.0.0
+   * BREAKING CHANGE: implementations of [RandomAccessReader](#class-randomaccessreader) that implement a `destroy` method must instead implement `_destroy` in accordance with the node standard https://nodejs.org/api/stream.html#writable_destroyerr-callback (note the error and callback parameters). If you continue to override `destory` instead, some error handling may be subtly broken. Additionally, this is required for async iterators to work correctly in some versions of node. [issue #110](https://github.com/thejoshwolfe/yauzl/issues/110)
+   * BREAKING CHANGE: Drop support for node versions older than 12.
+   * Maintenance: Fix buffer deprecation warning by bundling `fd-slicer` with a 1-line change, rather than depending on it. [issue #114](https://github.com/thejoshwolfe/yauzl/issues/114)
+   * Maintenance: Upgrade `bl` dependency; add `package-lock.json`; drop deprecated istanbul dependency. This resolves all security warnings for this project. [pull #125](https://github.com/thejoshwolfe/yauzl/pull/125)
+   * Maintenance: Replace broken Travis CI with GitHub Actions. [pull #148](https://github.com/thejoshwolfe/yauzl/pull/148)
+   * Maintenance: Fixed a long-standing issue in the test suite where a premature exit would incorrectly signal success.
+   * Officially gave up on supporting Mac Archive Utility corruption in order to rescue my motivation for this project. [issue #69](https://github.com/thejoshwolfe/yauzl/issues/69)
+
  * 2.10.0
    * Added support for non-conformant zipfiles created by Microsoft, and added option `strictFileNames` to disable the workaround. [issue #66](https://github.com/thejoshwolfe/yauzl/issues/66), [issue #88](https://github.com/thejoshwolfe/yauzl/issues/88)
  * 2.9.2
@@ -656,3 +864,11 @@ This library makes no attempt to interpret the Language Encoding Flag.
    * Fix bug with using `iconv`.
  * 2.0.0
    * Initial release.
+
+## Development
+
+One of the trickiest things in development is crafting test cases located in `test/{success,failure}/`.
+These are zip files that have been specifically generated or design to test certain conditions in this library.
+I recommend using [hexdump-zip](https://github.com/thejoshwolfe/hexdump-zip) to examine the structure of a zipfile.
+
+For making new error cases, I typically start by copying `test/success/linux-info-zip.zip`, and then editing a few bytes with a hex editor.

package/web/.next/standalone/node_modules/{fd-slicer/index.js → yauzl/fd-slicer.js}

@@ -1,3 +1,4 @@
+// This was adapted from https://github.com/andrewrk/node-fd-slicer by Andrew Kelley under the MIT License.
 var fs = require('fs');
 var util = require('util');
 var stream = require('stream');
@@ -106,7 +107,7 @@ ReadStream.prototype._read = function(n) {
   }
   self.context.pend.go(function(cb) {
     if (self.destroyed) return cb();
-    var buffer = new Buffer(toRead);
+    var buffer = Buffer.allocUnsafe(toRead);
     fs.read(self.context.fd, buffer, 0, toRead, self.pos, function(err, bytesRead) {
       if (err) {
         self.destroy(err);
@@ -194,12 +195,29 @@ function BufferSlicer(buffer, options) {
 }
 
 BufferSlicer.prototype.read = function(buffer, offset, length, position, callback) {
-  var end = position + length;
-  var delta = end - this.buffer.length;
-  var written = (delta > 0) ? delta : length;
-  this.buffer.copy(buffer, offset, position, end);
+  if (!(0 <= offset && offset <= buffer.length)) throw new RangeError("offset outside buffer: 0 <= " + offset + " <= " + buffer.length);
+  if (position < 0) throw new RangeError("position is negative: " + position);
+  if (offset + length > buffer.length) {
+    // The caller's buffer can't hold all the bytes they're trying to read.
+    // Clamp the length instead of giving an error.
+    // The callback will be informed of fewer than expected bytes written.
+    length = buffer.length - offset;
+  }
+  if (position + length > this.buffer.length) {
+    // Clamp any attempt to read past the end of the source buffer.
+    length = this.buffer.length - position;
+  }
+  if (length <= 0) {
+    // After any clamping, we're fully out of bounds or otherwise have nothing to do.
+    // This isn't an error; it's just zero bytes written.
+    setImmediate(function() {
+      callback(null, 0);
+    });
+    return;
+  }
+  this.buffer.copy(buffer, offset, position, position + length);
   setImmediate(function() {
-    callback(null, written);
+    callback(null, length);
   });
 };