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).
when mounting a fuse fs by fstab on can write:
/nix/store/sdlflj/bin/somefuseexe#argument /mountpoint fuse setuid=someuser
mount is run by root, and setuid is a way to tell mount.fuse to run
somefuseexe as someuser instead. Under the hood, mount.fuse uses su.
The problem is that mount is run by systemd in a seemingly very empty
environment not containing /run/current-system/sw/bin nor
/run/wrappers/bin in $PATH, so mount fails with "su command not found".
We now patch the command to run su with an absolute path.
man mount.fuse3 indicates that this option is reserved to root (or with
enough capabilities) so not using
/run/wrappers/bin/su is thus correct. It has the very small advantage of
possibly working on non nixos.
For a while now it's possible to specify an additional config file in
`wpa_supplicant`[1]. In contrast to the file specified via `-c` this was
supposed to be used for immutable settings and not e.g. additional
networks.
However I'm a little bit unhappy about the fact that one has to choose
between a fully imperative setup and a fully declarative one where the
one would have to write credentials for e.g. WPA2-enterprise networks
into the store.
The primary problem with the current state of `wpa_supplicant` is that
if the `SAVE_CONFIG` command is invoked (e.g. via `wpa_cli`), all known
networks will be written to `/etc/wpa_supplicant.conf` and thus all
declarative networks would get out of sync with the declarative
settings.
To work around this, I had to change the following things:
* The `networking.wireless`-module now uses `-I` for declarative config,
so the user-controlled mode can be used along with the
`networks`-option.
* I added an `ro`-field to the `ssid`-struct in the
`wpa_supplicant`-sources. This will be set to `1` for each network
specified in the config passed via `-I`.
Whenever config is written to the disk, those networks will be
skipped, so changes to declarative networks are only temporary.
[1] https://w1.fi/cgit/hostap/commit/wpa_supplicant?id=e6304cad47251e88d073553042f1ea7805a858d1
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
