Skip to content

fix: cap total zip expansion during tar conversion#25877

Draft
geokat wants to merge 1 commit into
mainfrom
george/plat-274-zip-upload-decompressed-without-aggregate-size-limit
Draft

fix: cap total zip expansion during tar conversion#25877
geokat wants to merge 1 commit into
mainfrom
george/plat-274-zip-upload-decompressed-without-aggregate-size-limit

Conversation

@geokat
Copy link
Copy Markdown
Contributor

@geokat geokat commented May 30, 2026

Summary

Reject ZIP uploads whose expanded tar output exceeds the file upload limit.

This change adds aggregate size enforcement when converting ZIP uploads to tar,
so small compressed archives can no longer expand without bound in memory. ZIP
uploads that exceed the configured expansion limit now return
413 Request Entity Too Large instead of being processed as an internal error.

Changes

  • add archive-level preflight checks for projected tar size
  • add writer-side aggregate limits while streaming tar output
  • propagate tar.Writer.Close() errors instead of dropping them
  • return 413 from POST /api/v2/files when expanded ZIP content is too large
  • add regression coverage for oversized ZIP expansion in archive and handler tests

Ref: https://linear.app/codercom/issue/PLAT-274/zip-upload-decompressed-without-aggregate-size-limit-sec-103

Reject zip uploads whose projected or actual tar expansion exceeds the
configured file size limit.

Add aggregate-size checks before conversion and while streaming tar
output, propagate tar close errors, and return 413 when expanded zip
content is too large.

Ref: https://linear.app/codercom/issue/PLAT-274/zip-upload-decompressed-without-aggregate-size-limit-sec-103
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant