[GH-ISSUE #1725] fix(artifacts): duplicate ZIP members overwrite emitted entry identity #579

New issue

Closed

opened 2026-10-15 18:26:22 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:22 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1725

A ZIP reader can return the bytes of a different central-directory member for a previously emitted ArtifactEntry. This is a producer identity defect; the current public inventory/extraction flows reject duplicate logical paths before accepting a complete result.

Reproduced against a fresh single-threaded build of main at 092de8f4b336b537579bd48d7d30135b7114371d on Linux, Node.js 24.18.0. The real input is a 218-byte ZIP with two stored x.txt entries, each 12 bytes, containing first bytes\n and later bytes\n respectively. The two entries have identical projected REA metadata.

Construct ZipArtifactReader(path, "zip").
Retain the first entry while exhausting reader.entries().
Call reader.open({...firstEntry}) and consume the stream.

Observed: enumeration succeeds, and the retained first entry reads later bytes\n. Expected: exact duplicate names should be rejected before they can replace an emitted entry’s lookup, preserving the original entry’s content identity. A case-distinct x.txt / X.txt control preserves both contents and supports a second enumeration.

The owning cause is #entries.set(entry.filename, ...) in ZipArtifactReader.entries(): the second central-directory record overwrites the first mapping. sameArtifactEntry cannot distinguish these otherwise identical metadata values. The inventory registry already reports a typed path failure for this input; fixing the reader must retain that behavior, ordinary replay, case-distinct names, and nested directory/ASAR source addressing.

Related issue #1480 covers case-distinct paths rather than exact duplicate identities. No matching open PR was found with gh. This report does not claim that the public inventory currently accepts duplicate paths, nor that a real external native provider was tested.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1725 A ZIP reader can return the bytes of a different central-directory member for a previously emitted `ArtifactEntry`. This is a producer identity defect; the current public inventory/extraction flows reject duplicate logical paths before accepting a complete result. Reproduced against a fresh single-threaded build of `main` at `092de8f4b336b537579bd48d7d30135b7114371d` on Linux, Node.js 24.18.0. The real input is a 218-byte ZIP with two stored `x.txt` entries, each 12 bytes, containing `first bytes\n` and `later bytes\n` respectively. The two entries have identical projected REA metadata. 1. Construct `ZipArtifactReader(path, "zip")`. 2. Retain the first entry while exhausting `reader.entries()`. 3. Call `reader.open({...firstEntry})` and consume the stream. Observed: enumeration succeeds, and the retained first entry reads `later bytes\n`. Expected: exact duplicate names should be rejected before they can replace an emitted entry’s lookup, preserving the original entry’s content identity. A case-distinct `x.txt` / `X.txt` control preserves both contents and supports a second enumeration. The owning cause is `#entries.set(entry.filename, ...)` in `ZipArtifactReader.entries()`: the second central-directory record overwrites the first mapping. `sameArtifactEntry` cannot distinguish these otherwise identical metadata values. The inventory registry already reports a typed path failure for this input; fixing the reader must retain that behavior, ordinary replay, case-distinct names, and nested directory/ASAR source addressing. Related issue #1480 covers case-distinct paths rather than exact duplicate identities. No matching open PR was found with `gh`. This report does not claim that the public inventory currently accepts duplicate paths, nor that a real external native provider was tested.

bsakaguchi

2026-10-15 18:26:22 +00:00