The libz-sys crate is 4MB large, but it only uses 1/10th of the data it bundles.
The zlib repo has all kinds of irrelevant files: a PDF documentation, support files for dead platforms, multiple build C systems, interfaces for various other languages, tests and support utilities. None of that is used by the sys crate.
Also the CVE-2024-3094 has demonstrated that seemingly standard and innocent files like configure and test fixtures can be used to hide malware. While I don't expect libz to do such thing, it is better to have fewer obscure files in the crate, so that it's easier to review.
I haven't done the same for the zlib-ng crate, because it uses CMake and it's harder to see which files it uses. It might be better to switch it to the cc crate first.
The libz-sys crate is 4MB large, but it only uses 1/10th of the data it bundles.
The zlib repo has all kinds of irrelevant files: a PDF documentation, support files for dead platforms, multiple build C systems, interfaces for various other languages, tests and support utilities. None of that is used by the sys crate.
Also the CVE-2024-3094 has demonstrated that seemingly standard and innocent files like
configure
and test fixtures can be used to hide malware. While I don't expect libz to do such thing, it is better to have fewer obscure files in the crate, so that it's easier to review.I haven't done the same for the zlib-ng crate, because it uses CMake and it's harder to see which files it uses. It might be better to switch it to the
cc
crate first.