Please make new release

[Neustradamus]

@madler: It is possible to release a new build with all build and CVE-2022-37434 fixes...?
A 1.2.12.1 or 1.2.13?

It is really important to have a solution to current 1.2.12.

Tickets/PRs:

• CMake Update #337
• Building static library in VIsual Studio 2017 #404
• Lost a function exporting entry in VC Module-Definition Files(.def) #604
• Fix CC logic in configure #607
• zlib 1.2.12 fails to compile #608
• Folders contrib/amd64, contrib/asm686, contrib/masmx64, contrib/masmx86 were removed in 1.2.12 but not from the CMakeLists.txt #609
• zlib v1.2.12 causes java.util.zip.ZipException #613
• [cmake][build] Remove ASM configure options #614
• Odd bug with zlib 1.2.12 configure on macOS with clang #615
• zlib v1.2.12 fails to build shared library #617
• Flyway migrations CRC32 checksum different after upgrading to 1.2.12 (from 1.2.11) #618
• crc32 functions produce errors when building 1.2.12 zlibstat on Windows #620 + Esri@05b33dd
• Copyright date was not updated, showing old 2017 instead of 2022, in win32/zlib1.rc used by CMakeLists.txt  #622
• RubyZip doesn't work well after updating zlib to v.1.2.12 #623
• Keep compatibility with older compilers (broken by v1.2.12) #624
• Cannot build zlib v.1.2.12 on Windows without compiler warnings #628
• Build failed with cr32 errors in Windows zlibvc 1.2.12 - Win32/x86 #629
• Please fix 1.2.12 compile #631
• Corrected date from 2017 to 2022 #632
• Query on go-forward plan for the Windows build #635
• Fix crc32.c build error on MSVC x86 build #638
• Fix MSVC vc14 ReleaseWithoutAsm build #639
• solution for VS 22, fix for Windows build #644
• Added VisualStudio 2022 files #645
• (RESOLVED) Zlib-1.2.12 fails to Make #646
• zLib 1.2.12 fails to build in VC++/Win32 due to mismatched declarations #660
• not found signal _uncompress when link by vs 2022 #661
• Use $CC if variable is set #662
• The ioapi.c file in minizip is incompatible with the C89 standard. #668
• Pre-build zlib1.dll 1.2.12.0 for everyone! #672
• cmake: respect custom RC flags with mingw #677

In more:

• minizip: use single ZREAD64 call in unz64local_getShort/Long/Long64 #557
• gzip_normalize function could modify the return type to void #657
• minizip: use default variables/rules in Makefile #681
• fix: Make tests optional #691
• Security and warning fix for minizip #694

About GitHub:

• Add continuous integration (CI) #492
• Added GitHub Actions workflows #506

Thanks in advance.

Linked to:

• Please make new release #422

cc: @gvollant.

[broonie]

Please, this would be very helpful for Debian.

[0-wiz-0]

and CVE-2022-37434...

[vcunat]

Though fix for that CVE seems to be buggy: eff308a#commitcomment-80589094

[Neustradamus]

@madler: Comments of:

• @bagder: eff308a#commitcomment-80589094
• @piru: eff308a#commitcomment-80595833

Have you seen the issue of @winterqt:

• Test 224 fails with CVE-2022-37434 patched zlib curl/curl#9271

Have you seen the PR of @winterqt:

• Fix segfault in inflate() when state->head is null. #688

[madler]

Fix should be fixed in 1eb7682 . (This is an example of why to not release too hastily.)

[Neustradamus]

@madler: Thanks!

Can you look all tickets specified here: #686 (comment) to fix problems, and after, plan a new release?

[hyder365]

Any update?

[moralground]

Could we have the new release please?

[Neustradamus]

@madler: Have you looked to solve all 1.2.12 cited bugs and create a new 1.2.12.1 or 1.2.13 release?

Please read at the top of this ticket...

• Please make new release #686

[moralground]

@madler: Have you looked to solve all 1.2.12 cited bugs and create a new 1.2.12.1 or 1.2.13 release?

Please read at the top of this ticket...

* [Please make new release #686](https://github.com/madler/zlib/issues/686)

Ping @madler

[thesamesam]

Fix should be fixed in 1eb7682 . (This is an example of why to not release too hastily.)

In reality, it's not. All distros were, are, and will be under pressure to backport CVE fixes quickly (if you think something is not worthy of a CVE, please dispute it with the organisation which publishes it -- they can note your disagreement and it'll affect how distros respond). All that then happens is we have to rely on word-of-mouth to get the extra fixup patches.

There is little motivation to wait for a release because we're never sure if one is going to come "soon" after the patch (it's rare that they happen, so it's unlikely to be worth waiting an extra week or two, as one is unlikely to happen then as well, from collective packagers' experience).

Besides, the last time we did have a release, a fixup release was needed afterwards anyway - which is fine (and normal!), but it just shows the nature of software development. Avoiding making releases won't stop people from using the patches.

The fact there's so many of these bugs being filed begging for a new release shows the current model isn't ideal.

If you want more confidence before making a release, my humble suggestion would be to communicate your plans to the community, and consider doing brief release candidates to smoke out issues. Distributions use these for testing but don't publish them to users.

[broonie]

I agree with everything @thesamesam said here. Alternatively if the project is going to move to a git snapshot model without releases it'd be good to know that so that distros can proceed accordingly. Releases are generally preferable though, and would help ensure that people picking up zlib directly rather than using a distro are getting security fixes, they're more likely to pick up a release when there are releases available.

Like I said earlier in the history of the bug it'd be really helpful for Debian, I keep expecting a new release for all the reasons people have outlined and there's other work queued up behind that.

[madler]

Closing. This issue only refers to other issues.

[Neustradamus]

@madler: Do not forget to solve all specified tickets here before the new release with CVE fix.

[madler]

I don't know what exactly you mean by "specified" or "tickets", but I'm certainly not going to attempt to address all outstanding issues and pull requests before the next release.

[Neustradamus]

@madler: Base on my first message, cleaned with closed.

Tickets/PRs:

• CMake Update #337
• Building static library in VIsual Studio 2017 #404
• Lost a function exporting entry in VC Module-Definition Files(.def) #604
• [cmake][build] Remove ASM configure options #614
• RubyZip doesn't work well after updating zlib to v.1.2.12 #623
• Corrected date from 2017 to 2022 #632
• Fix MSVC vc14 ReleaseWithoutAsm build #639
• solution for VS 22, fix for Windows build #644
• Added VisualStudio 2022 files #645
• cmake: respect custom RC flags with mingw #677

In more:

• minizip: use single ZREAD64 call in unz64local_getShort/Long/Long64 #557
• gzip_normalize function could modify the return type to void #657
• minizip: use default variables/rules in Makefile #681
• fix: Make tests optional #691

About GitHub:

• Add continuous integration (CI) #492

Please note how to merge:

• Fix CC logic in configure #607 (comment)

To look last updated Issues/PRs:

Issues:

• https://github.com/madler/zlib/issues?q=is%3Aissue+sort%3Aupdated-desc+is%3Aopen

PRs:

• https://github.com/madler/zlib/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

[madler]

Those are all either not high enough priority to address for the next release, or have already been addressed. Note that the stuff in contrib is not part of zlib.

[miklelappo]

@madler but is the next release even planned at the moment? Is there any approximate date?

[madler]

Real soon now.

[miklelappo]

Thanks for good news @madler!

[Neustradamus]

@madler has done the new build, the 1.2.13 has been released with the CVE-2022-37434 fix.

Thanks for this build and the merged commits from several people.

[miklelappo]

@madler thanks for a new release! Great job!

[AraHaan]

btw as for vs2022 I have made a PR for as well (and it includes ARM, ARM64, removes Itanium (seems it was removed back right after VS2010 and nobody noticed it, and finally also includes nuget packaging for developing using .NET that directly p/invokes the native library). That last update in my PR was needed as not all applications should depend on (possibly installed versions of zlib from package managers) as they might not find the exact version their application depends on.