Repository navigation
fix(zip): never write through a symlink when extracting - #43910
Conversation
A zip archive could contain a symlink entry followed by a regular file with the same name. The parent directory check passed for both, and the file write followed the symlink out of the extraction directory. Symlink entries are now rejected unless the caller passes allowSymlinks. Only browser archives need them (macOS framework bundles); report zips opened with show-report never do. With allowSymlinks, the extractor still refuses to write through an existing symlink.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…or symlinks O_EXCL fails when the destination exists, including a symlink, so the kernel enforces the check. Symlink entries are allowed again; the browser archives on macOS need them.
This comment has been minimized.
This comment has been minimized.
🔴 The four test-runner failures are caused by this PRHi, I'm the Playwright bot. I checked the latest merged report, the PR diff, and the refreshed CI test history. DetailsCaused by this PR
The new The same test passed on all four platforms in the previous PR run. The refreshed database covers October 8–November 5 and has no A possible fix is to write each resource path only once in Triaged by the Playwright bot - agent run |
This comment has been minimized.
This comment has been minimized.
🟢 The latest MCP failure is a pre-existing flakeHi, I'm the Playwright bot. I checked the latest merged report, the failed job, the PR diff, and the refreshed CI test history. DetailsThe latest MCP report has one failure, which is not likely caused by this PR. This verdict covers MCP only; the separate verdict identifying the test-runner ZIP extraction regression still applies. Pre-existing flake
The refreshed test-results database records the same test, browser, platform, and error on The PR changes ZIP extraction to reject existing destination files. It does not change SSE sessions, persistent browser profiles, or local storage, and this failure is a storage assertion, not an extraction error. Triaged by the Playwright bot - agent run |
Attachments that share a path and content type map to the same zip entry. The reporter added the entry once per attachment, and the extractor now refuses to overwrite an existing file. Drop the extract-zip unit tests.
Test results for "tests 1"23586 passed, 704 skipped Merge workflow run. |
Test results for "MCP"5194 passed, 616 skipped Merge workflow run. |
Summary
wxflag.O_EXCLfails when the destination exists, including a symlink, so the kernel enforces the check.