Stable release 2.0.7 #1393
Stable release 2.0.7 #1393
Conversation
Dead2
added
the
Next Stable
|
What do you mean? The commit is in this PR already, and there is no other commit in the source PR. Edit: Actually the commit is already there. But github does not show it in the above list, only in the commits tab. The list above seems to only show about half the actual commits, weird.. |
|
Oh! I am sorry! |
Technically, we weren't actually doing this the way C wants us to, legally. The zmemcpy's turn into NOPs for pretty much all > 0 optimization levels and this gets us defined behavior with the sanitizer, putting the optimized load by arbitrary alignment into the compiler's hands instead of ours. Backport note: Replaced zmemcpy with direct memcpy, as that is what we end up with in a later commit anyway.
* This avoids conditional branch when it's known at build time that TZCNT instructions are always supported
It would seem that on some platforms, namely those which are !UNALIGNED64_OK, there was a likelihood of chunkmemset_safe_c copying all the bytes before passing control flow to chunkcopy, a function which is explicitly unsafe to be called with a zero length copy. This fixes that bug for those platforms.
Sample input from https://www.openwall.com/lists/oss-security/2022/03/26/1. Co-authored-by: Tavis Ormandy <taviso@users.noreply.github.com>
Co-authored-by: Eric Biggers <ebiggers@kernel.org>
…zconf.h via zlib.h.
…e shell when running configure
…for small lengths due to shift returning 0. * Treat 0 byte input as 1 byte input when calculating compressBound and deflateBound
* Test both compressBound() and deflateBound() as those share same code fragment.
Removed tests for features not supported in 2.0.x: - cxx related settings, as stable does not use gtest/gbench. - Emscripten - Add_subdirectory - Symbol prefix - oss-fuzz, their buildfile is incompatible with this branch
…n and congestion. The free Github Actions VMs have 2 cores, the dedicated s390x VM has 4 cores.
* Add __msan_unpoison() calls to DFLTCC inline assembly. * Make parameter block sizes symbolic constants. * Move dfltcc() definition after struct dfltcc_param_v0 definition. Backported from commit 1f5ddcc.
gzsetparams() now returns a Z_STREAM_ERROR in this case.
memLevel 9 would cause deflateBound() to assume the use of fixed blocks, even if the compression level was 0, which forces stored blocks. That could result in a bound less than the size of the compressed data. Now level 0 always uses the stored blocks bound.
A fixed block could be chosen when a stored block was smaller. Now the smaller of the two is always chosen.
Dead2
force-pushed
the
stable-pre-release
branch
from
232a3ca
to
d35a28b
Compare
|
All checks pass! |
We're getting closer and closer to next stable release... Still need some testing before we can do official release... |
|
I don't know if it is very helpful but for the python bindings I test the compatibility with proper zlib. I simply take all possible compression levels, memory levels and windowbits settings and run them through zlib-ng's deflate and see if zlib's inflate can properly handle them. Then I do the same thing the other way round. This results in thousands of compatibility tests. |
Changes since 2.0.6: - Fix CVE-2022-37434 #1328 - Fix chunkmemset #1196 - Fix deflateBound too small #1236 - Fix Z_SOLO #1263 - Fix ACLE variant of crc32 #1274 - Fix inflateBack #1311 - Fix deflate_quick windowsize #1431 - Fix DFLTCC bugs related to adler32 #1349 and #1390 - Fix warnings #1194 #1312 #1362 - MacOS build fix #1198 - Add invalid windowBits handling #1293 - Support for Force TZCNT #1186 - Support for aligned_alloc() #1360 - Minideflate improvements #1175 #1238 - Dont use unaligned access for memcpy #1309 - Build system #1209 #1233 #1267 #1273 #1278 #1292 #1316 #1318 #1365 - Test improvements #1208 #1227 #1241 #1353 - Cleanup #1266 - Documentation #1205 #1359 - Misc improvements #1294 #1297 #1306 #1344 #1348 - Backported zlib fixes - Backported CI workflows from Develop branch
|
Heads up: This is getting released later today, unless something comes up in last minute testing. I'd like it if people would do a quick review of this PR. (You don't need to read every line, just say what you did do; cursory review, tested on x86-64, agree with the proposed changes, etc). I meant to release this late last week, but I have been out with the flu for a week now, and I am finally able to spend a little time in front of a monitor again. I have been running this on a production web server for a while now without problems, unfortunately I no longer have access to big server deployments since I am no longer employed (I became 100% disabled recently). |
|
GCC 12.2 on x86-64 i9-9900K (no AVX-512) 2.0.62.0.7Code size is slightly smaller. |
|
Thank you very much for the release! FWIW, I ran some additional tests on s390x, and all is looking good. |
|
Thanks very much for releasing. I updated the python bindings to include the new version. Since the wbits bug is fixed these bindings can be used as a one-to-one replacement for python's zlib module. |
Changes since 2.0.6:
RCflags and deleteGCC_WINDRES#1318 Makefile.in: distclean should remove pkgconfig file(s) instead of clean #1365