In https://github.com/openzfs/zfs/commit/658fb802 OpenZFS introduced a
new compatibility feature. This is accompanied by some default profiles
which are located in the $out output of the Nix derivation. However,
these compatibility profiles are used by both the zpool executable
located in $out and the libzfs library located in $lib. This
inadvertently creates a cycle, because zpool refers to $lib to link
against libzfs but libzfs refers back to $out for the compatibility
profiles.
There are two possible routes to rectify this problem:
1. Patch the zpool source code to not read the compatibility profiles
and adjust the build system to put them into the $lib output.
2. Simply remove the $out/$lib split.
Since no other derivation in nixpkgs refers to the $lib output
explicitly we opt for the latter, because this is also in accordance
with upstream.
This option allows to use portions of the system RAM as block devices.
It was configured to 'y' (built-in, therefore not unloadable or
reconfigurable) and configured 16 4MB RAM disks which, to my knowledge,
currently have no purpose in NixOS.
Removing the option restores it to it's default value of 'm', which
enables it to be loaded at runtime (which is also required to be able to
change it's configuration without rebuilding the kernel).
For some reason fetchcvs was taken from the cross package set when
cross compiling netbsd.* instead of from buildPackages. I suspect that
this was no issue previously because it just could be substituted as it
only ever produced fixed output derivations. However since
00a2084a40 the evaluation of fetchcvs
would depend on `stdenv.cc` (via its openssh dependency). Since
netbsd.libc is required to evaluate stdenv.cc this caused a infinite
recursion when staging the cross stdenv for pkgsCross.amd64-netbsd. The
fix for this is pretty easy: Just take fetchcvs from buildPackages
explicitly instead of hoping for mkDerivation to get it right.
Resolves#119323.
In wpa_supplicant and hostapd 2.9, forging attacks may occur because
AlgorithmIdentifier parameters are mishandled in tls/pkcs1.c and
tls/x509v3.c.
Fixes: CVE-2021-30004
