I was talking about the same "install" that is already done (pre-installed on the drive that is first booted).

Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them.

This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens.

See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/syst...

▲

bri3d 4 hours ago | parent [-]

What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?

▲

NekkoDroid 4 hours ago | parent [-]

It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack.

If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.

	▲	bri3d 3 hours ago \| parent [-]
		What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.