Extract the release archive without shelling out to tar#134
Merged
Conversation
The first automatic release failed on the host: "tar: This does not look like a tar archive". Shelling out to `tar -xf` for a zip only ever worked because the machine it was written on was Windows, where tar is bsdtar and reads zip. The runner is Linux, where tar is GNU tar and does not. Nothing about calling the system archiver was portable, so it is gone. Zip reading now happens in Node with zlib, which behaves the same everywhere and lets unsafe entries be rejected before anything is written rather than after. Deliberately minimal — store and deflate, no zip64, no encryption. The archives come from our own release workflow, and anything else should be refused loudly rather than half-understood. Verified against the archive from the failed run: all six entries extract byte-identically to an independent implementation (Windows Expand-Archive), including the 21 MB wasm. A crafted archive containing "../evil.txt" is rejected with nothing written outside the target, and both that and a checksum mismatch exit non-zero so the workflow fails. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the first automatic release, which reached the host and then died on extraction:
Cause
The sync shelled out to
tar -xffor a zip. That works on Windows and macOS, wheretaris bsdtar and reads zip, and fails on Linux, where it is GNU tar and does not. It passed my local testing purely because I tested it on Windows — "call the system tar" was never portable, it just matched the machine it was written on.Everything before extraction worked correctly: the release was built, packaged, dispatched, downloaded and its checksum verified.
Fix
Zip reading now happens in Node with
zlib. No dependency on which archiver a host has installed, identical behaviour everywhere, and unsafe entries are rejected before anything is written instead of being caught by the audit afterwards.Deliberately minimal — store and deflate, no zip64, no encryption. The archives come from our own release workflow, and anything else should be refused loudly rather than half-understood.
Verification
Run against the actual archive from the failed run:
Expand-Archive, an independent implementation — including the 21 MB wasm. Hand-rolled zip parsing deserves a second opinion, so it got one.../evil.txtis rejected with nothing written outside the target directory;No artifact is included here on purpose: once this is merged, re-running the failed sync will publish it, which is the pipeline doing its job.
Ordering
#133 (rolling sync branch) is still open and independent of this. Either order works.
🤖 Generated with Claude Code