Before opening a new feature request, please read Requesting New Features and consider if this is something you can contribute yourself. If this a new request, help us help you by filling in the template below.
What problem will this solve?
Premake's archive extraction functionality currently supports only the .zip format. It does not support formats such as .tar.gz, which are more common for source packages. This prevents project maintainers from using Premake's extraction functionality to help downstream developers automatically download and install dependencies.
In addition, the version of libzip in the contrib directory is outdated, and the current ZIP implementation has the following issues:
- Buffer overflows
Char arrays such as appended_full_name have fixed sizes, while unbounded sprintf and memcpy calls may write beyond their buffers.
- Path traversal allowing directory escape
Paths stored in archives are not validated, so ../abc may cause files to be extracted outside the destination directory.
- Directory escape through symbolic links
Symbolic links in archives are extracted as-is, and subsequent files are resolved through them. An archive can therefore contain a symbolic link named ./abc pointing to ../abc, followed by ./abc/xyz, causing xyz to be extracted outside the destination directory.
- Reserved filenames such as
CON and LPT are allowed on Windows.
- Other issues involving resource cleanup.
- It appears to use the old zlib headers in the libzip directory instead of the newer headers from the zlib directory that is actually linked.
What might be a solution?
Replace libzip with libarchive. When used together with zlib, it can extract common formats such as .zip and .tar.gz. Adding liblzma in the future would also allow common formats such as .tar.xz to be extracted.
Unlike libzip, libarchive provides some security safeguards that can prevent most of the issues described above.
What other alternatives have you already considered?
I used AI to make some fixes to the current ZIP implementation. They are available at mercury233#2 . After making the initial fixes, I found that using libarchive might be a better solution.
Anything else we should know?
Integrating libarchive may be challenging. It may require writing the corresponding Premake scripts and testing them across all supported platforms.
(You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!)
Before opening a new feature request, please read Requesting New Features and consider if this is something you can contribute yourself. If this a new request, help us help you by filling in the template below.
What problem will this solve?
Premake's archive extraction functionality currently supports only the
.zipformat. It does not support formats such as.tar.gz, which are more common for source packages. This prevents project maintainers from using Premake's extraction functionality to help downstream developers automatically download and install dependencies.In addition, the version of libzip in the
contribdirectory is outdated, and the current ZIP implementation has the following issues:Char arrays such as
appended_full_namehave fixed sizes, while unboundedsprintfandmemcpycalls may write beyond their buffers.Paths stored in archives are not validated, so
../abcmay cause files to be extracted outside the destination directory.Symbolic links in archives are extracted as-is, and subsequent files are resolved through them. An archive can therefore contain a symbolic link named
./abcpointing to../abc, followed by./abc/xyz, causingxyzto be extracted outside the destination directory.CONandLPTare allowed on Windows.What might be a solution?
Replace libzip with libarchive. When used together with zlib, it can extract common formats such as
.zipand.tar.gz. Adding liblzma in the future would also allow common formats such as.tar.xzto be extracted.Unlike libzip, libarchive provides some security safeguards that can prevent most of the issues described above.
What other alternatives have you already considered?
I used AI to make some fixes to the current ZIP implementation. They are available at mercury233#2 . After making the initial fixes, I found that using libarchive might be a better solution.
Anything else we should know?
Integrating libarchive may be challenging. It may require writing the corresponding Premake scripts and testing them across all supported platforms.
(You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!)