InitWare, a portable systemd fork running on BSDs and Linux

(github.com)

Show context

exceptione ◴[03 Apr 25 17:18 UTC] 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 ◴[03 Apr 25 18:04 UTC] No.43573274[source]▶

>>43572744 #

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 ◴[03 Apr 25 19:56 UTC] No.43574595[source]▶

>>43573274 #

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 #

shawnz ◴[03 Apr 25 21:25 UTC] No.43575639{3}[source]▶

>>43574595 #

If the manufacturer wanted to conduct a supply chain attack on you, they wouldn't need secure boot to do it. They could just design an implant of their own using proprietary technology.

So why does the presence of secure boot as a user-controlled feature affect that risk calculation?

replies(1): >>43579737 #

1. immibis ◴[04 Apr 25 08:47 UTC] No.43579737{4}[source]▶

>>43575639 #

Because manufacturers aren't trying to add surreptitious implants. They're trying to prevent you installing operating systems other than the one they get a bulk discount if they force you to have.

replies(2): >>43580940 #>>43590295 #

2. shawnz ◴[04 Apr 25 11:54 UTC] No.43580940[source]▶

>>43579737 (TP) #

Whatever the intent, the point stands: why would they need secure boot to do that? They could just do it with proprietary controls. So how does the existence of secure boot as a user-controlled feature affect that risk?

replies(1): >>43585145 #

3. immibis ◴[04 Apr 25 17:04 UTC] No.43585145[source]▶

>>43580940 #

The specific proprietary controls you're referring to are called "secure boot".

replies(1): >>43585623 #

4. shawnz ◴[04 Apr 25 17:44 UTC] No.43585623{3}[source]▶

>>43585145 #

I think that is a uselessly reductive interpretation of what secure boot is because you could apply the same logic to any security technology. Why should we allow login passwords or user permissions or disk encryption, since those could be used as lock-out technologies by manufacturers, if they just ship them with defaults you can't control?

Manufacturers don't need any user-facing standardized controls to implement lockouts. So the possibility of a feature being used as a lockout shouldn't be a justification for taking away the option of having a user-controlled security feature. Taking it away from users isn't going to stop manufacturers from doing it anyway with proprietary technologies instead.

replies(1): >>43591716 #

5. bigfatkitten ◴[05 Apr 25 03:04 UTC] No.43590295[source]▶

>>43579737 (TP) #

They aren't doing that either. It's a tiresome point of FUD that comes up in every thread on secure boot.

6. immibis ◴[05 Apr 25 07:45 UTC] No.43591716{4}[source]▶

>>43585623 #

Because manufacturers do use secure boot to prevent you changing your OS and don't use fingerprint recognition to prevent you selling your device to someone else. If they did the latter, that would also be bad, but they don't.

↑