ping @twz123 for review

@GrahamcOfBorg eval
@GrahamcOfBorg build zlib

Please ping me if no one else merges this within a day or two.

Are we sure we want to send this vulnerability through staging instead of sending it straight to master as a critical fix? It's been very widely shared, and is zlib has a huge number of dependents, meanwhile it could take it a month or more to get through staging, since we just started a cycle.

I'm not advocating one way or the other, but want to make sure we make a considered decision.
cc @NixOS/security

Directly to master please.

It rebuilds all stdenvs, so binaries won't be there so soon either way. We might want to fix stable sooner than unstable?

As for unstable; I wasn't following the current staging-next iteration now (as I'm mostly unavailable this week), so perhaps it might be ready enough to go with this at once (say, merge this to staging-next and then soon to master when a few binaries are there).

Shall I rebase the commit onto staging-next or do you prefer a cherry-pick?
I'd suggest the cherry-pick as #165642 has already been merged to staging.

Going via staging-next is only worth it if staging-next is actually in a good state, we have to look into that first.

For NixOS 21.11 I think release-21.11 would be preferable, since we have no active staging run there right now.

Shall I rebase the commit onto staging-next or do you prefer a cherry-pick? I'd suggest the cherry-pick ashttps://github.com//pull/165642 has already been merged to staging.

Picked that commit into staging-next, please rebase onto staging-next. That's easiest to create the backport.

Backporting will be done by hand as the mentioned PR has already been backported into staging-21.11.

• qt5.qtbase can no longer find zlib on x86_64-darwin. Example 21.11 log: https://hydra.nixos.org/build/171602278

EDIT: split to #167708

• qt5.qtbase can no longer find zlib on x86_64-darwin. Example 21.11 log: https://hydra.nixos.org/build/171602278

The Qt-bundled zlib was updated in
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a0a2bf2d95d4fcd468b6ce3c2e728d95425dd760
which says Pick-to: 6.2 6.3 6.3.0 5.15 but it seems there is no pick to any Qt5 version (least 5.12.10, which is in our stable).

I hope we don't use the bundled one, but the commit (or some around it) might contain other necessary changes for newer zlib in Qt. Darwin defaults to Qt 5.12 even on newest nixpkgs... so perhaps that would better get addressed some time, too.

Well the root cause might be similar to PyPy

• pypy3 fails to find zlib. Example on staging-next: https://hydra.nixos.org/build/172082854 pypy3 fails to build, can't find zlib #167115

This broke support for cross-compiling zlib, causing everything depending on it to break:

mindavi@nixos:~/nixpkgs$ nix build .#pkgsCross.aarch64-multiplatform.zlib
mindavi@nixos:~/nixpkgs$ tree result
result
└── share
    └── man
        └── man3
            └── zlib.3.gz

3 directories, 1 file
mindavi@nixos:~/nixpkgs$ nix build .#pkgsCross.aarch64-multiplatform.zlib.dev
mindavi@nixos:~/nixpkgs$ tree result-dev
result-dev
├── include
│   ├── zconf.h
│   └── zlib.h
├── lib
│   └── pkgconfig
│       └── zlib.pc
└── nix-support
    └── propagated-build-inputs

4 directories, 4 files

Commit on which I tested this (merge staging-next to master): b4729ba

Maybe this section in the log points to something?

zlib-aarch64-unknown-linux-gnu> Checking for shared library support...
zlib-aarch64-unknown-linux-gnu> No shared library support; try without defining CC and CFLAGS
zlib-aarch64-unknown-linux-gnu> Building static library libz.a version 1.2.12 with aarch64-unknown-linux-gnu-gcc.

(This may well be an upstream issue, but I think it's still valuable to note here)