It turns out it's actually possible to fall back to WPA2 in case the
authentication fails with WPA3. This was suggested to me in the hostapd
mailing list: add another network block with only WPA2 and lower
priority, for each network with WPA3. For clients with missing/broken
WPA3, wpa_supplicant will:
1. try the network block with higher priority first
2. fail and temporarily disable the network block
3. try the fallback network block and connect
This takes a little more time (still <5s) because wpa_supplicant
retries a couple times before disabling the network block, but it allows
old client to gracefully fall back to WPA2 on mixed WPA2/WPA3 networks.
To avoid downgrade attacks, clients with proper WPA3 should disable
this; in the future we may want to disable this option by default.
I was confused why I couldn't find a mention of udev.log_priority in
systemd-udevd.service(8). It turns out that it was renamed[1] to
udev.log_level. The old name is still accepted, but it'll avoid
further confusion if we use the new name in our documentation.
[1]: 64a3494c3d
The programs.ssh.knownHosts.*.publicKeyFile is broken, because it's
scoped to a set of host names, but to insert those host names on each
line of the file we'd have to parse out blank lines and comments, so
only the first line works. It would be much easier all round if users
just provided known hosts files in the normal format, and we pointed
ssh directly to them. This way, it would be possible to have multiple
keys for a single host (which is extremely common due to multiple
algorithms being commonplace).
We add an option for this instead of relying on extraConfig, because
we need to make sure /etc/ssh/ssh_known_hosts is always included to
ensure programs.ssh.knownHosts keeps working.
/etc/ssh/ssh_known_hosts2 is another OpenSSH default that seems a bit
weird, but there's no real reason to change that so we'll leave it.
The Intel SGX DCAP driver makes the SGX application enclave device and
the SGX provisioning enclave available below the path `/dev/sgx/`. Since
Linux 5.11, a derivation of the DCAP driver is part of the kernel and
available through the X86_SGX config option; NixOS enables this option
by default.
In contrast to the out-of-tree DCAP driver, the in-tree SGX driver uses
a flat hierarchy for the SGX devices resulting in the paths
`/dev/sgx_enclave` for the application enclave device and
`/dev/sgx_provison` for the provisioning enclave device.
As of this commit, even the latest version of the Intel SGX PSW
libraries still tries to open the (legacy) DCAP paths only. This means
that SGX software currently cannot find the required SGX devices even if
the system actually supports SGX through the in-tree driver. Intel wants
to change this behavior in an upcoming release of intel/linux-sgx.
Having said that, SGX software assuming the SGX devices below
`/dev/sgx/` will prevail. Therefore, this commit introduces the NixOS
configuration option `hardware.cpu.intel.sgx.enableDcapCompat` which
creates the necessary symlinks to support existing SGX software. The
option defaults to true as it is currently the only way to support SGX
software. Also, enabling the SGX AESM service enables the option.
The permissions of the devices `/dev/sgx_enclave` and
`/dev/sgx_provison` remain the same, i.e., are not affected regardless
of having the new option enabled or not.
