Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catch up master to base zlib repo master #1

Open
wants to merge 323 commits into
base: master
Choose a base branch
from

Conversation

Yurmusp
Copy link

@Yurmusp Yurmusp commented Oct 1, 2020

No description provided.

Per request, but its utility is likely to be very limited. See the
comments in zlib.h.
Limit read() and write() requests to sizes that fit in an int.
This allows storing the return value in an int, and avoiding the
need to use or construct an ssize_t type. This is required for
Microsoft C, whose _read and _write functions take an unsigned
request and return an int.
Also declare z_size_t when compiling solo.
There have been many reports of bugs in the assembler codes
intended to speed up deflate and inflate. They are third-party
contributions in contrib, and so are not supported by the zlib
maintainers.
However this ends up not really being solo, since it has to
include external libraries.
delphij and others added 30 commits September 3, 2023 21:50
To avoid warnings when building with -Wmissing-prototypes.
A bug fix in zlib 1.2.12 resulted in a slight slowdown (1-2%) of
deflate. This commit provides the option to #define LIT_MEM, which
uses more memory to reverse most of that slowdown. The memory for
the pending buffer and symbol buffers is increased by 25%, which
increases the total memory usage with the default parameters by
about 6%.
The appnote says that if the number of entries in the end record
is 0xffff, then the actual number of entries will be found in the
Zip64 end record. Therefore if the number of entries is equal to
0xffff, it can't be in the end record by itself, since that is an
instruction to get the number from the Zip64 end record. This code
would just store 0xffff in the end record in that case, not making
a Zip64 end record. This commit fixes that.
fdopen() is not used by zlib anymore. The #defines are vestigial.
Since each element in s->d_buf is 2 bytes, the sx index should be
multiplied by 2 in the assert.

Fixes #897
If it is negative, then the code will enter an infinite loop.
Archive formats such as .zip files are generally susceptible to
so-called "traversal attacks". This allows an attacker to craft
an archive that writes to unexpected locations of the file system
(e.g., /etc/shadow) if an unspecting root user were to unpack a
malicious archive.

This patch neutralizes absolute paths such as /tmp/moo and deeply
relative paths such as dummy/../../../../../../../../../../tmp/moo

The Debian project requested CVE-2014-9485 be allocated for the
first identified weakness. The fix was incomplete, resulting in a
revised patch applied here. Since there wasn't an updated version
released by Debian with the incomplete fix, I suggest we use this
CVE to identify both issues.

Link: https://security.snyk.io/research/zip-slip-vulnerability
Link: https://bugs.debian.org/774321
Link: https://bugs.debian.org/776831
Link: https://nvd.nist.gov/vuln/detail/CVE-2014-9485
Reported-by: Jakub Wilk <[email protected]>
Fixed-by: Michael Gilbert <[email protected]>
gz_intmax() is noted in zlib.map. This assures it's always there.
There used to be one, but no more. It is up to the user or vendor
to compile zlib.
The --version-script linker option is not supported by the linker on AIX systems
This avoids trying to compare a match starting one byte before the
current window. Thanks to @zmodem (Hans) for discovering this.
Not all C compilers have a -w option.
This enables the addition of zlib to other projects.
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.