←back to thread

167 points sunshine-o | 1 comments | | HN request time: 0.001s | source
Show context
exceptione ◴[] No.43572744[source]
The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.

I think Systemd has a view that those things should reliably work together. I do not fancy a revival of the past where the user has to cobble a mesh of hopefully compatible libraries to achieve the same, taking weeks to study the Arch manual and resolving tons of gotcha's, all to be broken by next week's update.

The integration of all this stuff is now actively under test and maintenance with systemd.

And yes, the mentioned services also have an impact on the scope of service managing. Because if you have a unit that depends on a disk that needs to be unencrypted, this has to be resolved somehow in the right time.

I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large.

So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?

replies(5): >>43573274 #>>43573308 #>>43573459 #>>43575409 #>>43576185 #
udev4096 ◴[] No.43573274[source]
systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html
replies(3): >>43574018 #>>43574595 #>>43574860 #
immibis ◴[] No.43574595[source]
The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo.

I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.

replies(4): >>43574869 #>>43574936 #>>43575639 #>>43579535 #
1. fc417fc802 ◴[] No.43574936{3}[source]
The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation.

The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though.

In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.