Submodule zip handling breaks permissions/compression #572
Description
Description
When deploying from a git repo that uses submodules on a linux host, deployed files that are not executable end of with 600 permissions, which prevents deployed application from serving them as static assets (at least with apache as proxy, where httpd runs as apache and files are owned by webapp).
It seems to be caused by an interaction with how git archive creates zip files (MS DOS format, zeroed out extended attributes), and pythons zipfile.writestr() implementation, which will assign owner read/write to those fields on posix if zeroed extended attrs are present (according to ChatGPT anyhow, didn't verify the exact failure on the python implementation end.)
See the attached patch for a workaround that I've tested on linux.
Steps to reproduce
Create a git repo with a submodule, that has a file with mode 644.
deploy the parent repo to elastic beanstalk.
Extract/inspect the generated zip file/deployed files. submodule files will have incorrect 0600 permissions (and be stored uncompressed).
Observed result
The generated zip file contains 0600 perms on non-executable submodule files.
using zipinfo -lv on the generated zip file,
A file that was originally 644 in the parent project looks like:
offset of local header from start of archive: 8348995
(00000000007F6543h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 0.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2025 Oct 6 14:07:16
file last modified on (UT extra field modtime): 2025 Oct 6 14:07:16 local
file last modified on (UT extra field modtime): 2025 Oct 6 18:07:16 UTC
32-bit CRC value (hex): 21592f61
compressed size: 307 bytes
uncompressed size: 770 bytes
length of filename: 35 characters
length of extra field: 9 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: text
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (00 hex): none
And a file that was 644 from a submodule looks like:
offset of local header from start of archive: 22029898
(000000000150264Ah) bytes
file system or operating system of origin: Unix
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2025 Oct 6 15:13:40
32-bit CRC value (hex): 093dfd8c
compressed size: 1491 bytes
uncompressed size: 1491 bytes
length of filename: 38 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (000600 octal): ?rw-------
MS-DOS file attributes (00 hex): none
Expected result
submodule files should either be 644/755 (the only perm modes that git archive respects - due to cross platform constraints)
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
- OS: Ubuntu LTS 24.04
- EBCLI version: 3.25.1
Attaching Patch used for local testing - partially AI generated
This patch fixes the behavior, and as a side effect, also compresses the submodule files instead of appending them uncompressed.
This drops the deployed app zip size for my test app from 500mb to 200mb.