In reply to @raitobezarius:matrix.org
(b) the user forcibly creates an unencrypted /boot with an encrypted / via manual partitioning

In reply to @raitobezarius:matrix.org
that's inherent to how this graphical installer works

In reply to @septem9er:fairydust.space
This definitly is not the case with calamares on other OSes. You should be allowed to have an unencryped boot with an encrypted root without the installer putting your secrets into the unencryped boot partition.

In reply to @raitobezarius:matrix.org
what is missing is an warning or an assertion

There is a warning, see this screenshot.

But it sound more like the general "unencryped boot partitons can be unsecure" than an "we will place your FDE secrets there".

In reply to @septem9er:fairydust.space

Hey,
it seems like there is an regression of CVE-2023-36476 in the Nixos-calamares-extension, aka. the graphical NixOS-Installer.
The commit fixing this was reverted for some reason. It seems like they wanted to fix it another way in this commit. I haven't really looked into what they try to do in this commit, however the commit message was the following:

Do not use crypto_keyfile.bin in UEFI, but leave BIOS the same.

Which doesn't really make sense to me, because the original CVE applied to BIOS systems mostly. So leaving BIOS systems the same wouldn't fix the issue.

Someone reported this here, I could reproduce this with the latest Nixos-GNOME ISO, with the following steps:

1. Start the ISO on a BIOS (legacy) system / in BIOS mode
2. Select manual partitioning in the installer
3. Create an unencrypted legacy-boot partition with mountpoint /boot
4. Create an encrypted root partition with mountpoint /

After the installation is done, there is an luks-keyfile in an zstd/cpio archive in /boot/kernels/***-secrets, which does open the root partition.

Blast-RADIUS is a protocol vulnerability, and thus affects all RADIUS implementations using non-EAP authentication methods over UDP.