Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lennart Poettering, Christian Brauner founded a new company

amutable.com

Post reply on HN
Print view View original

381–390 of 770 posts

Re: Lennart Poettering, Christian Brauner founded a new company

#381

Post by Gigachad »

Nextgrid wrote: post #98
MarkusWandel wrote: post #78

My only experience with Linux secure boot so far.... I wasn't even aware that it was secure booted. And I needed to run something (I think it was the Displaylink driver) that needs to jam itself into the kernel. And the convoluted process to do it failed (it's packaged for Ubuntu but I was installing it on a slightly outdated Fedora system). What, this part is only needed for secure boot? I'm not sec... oh. So go bac…

Secure Boot only extends the chain of trust from your firmware down the first UEFI binary it loads. Currently SB is effectively useless because it will at best authenticate your kernel but the initrd and subsequent userspace (including programs that run as root) are unverified and can be replaced by malicious alternatives. Secure Boot as it stands right now in the Linux world is effectively an annoyance that’s only t…

Isn’t the idea that the kernel will verify anything beneath it. Secure boot verifies the kernel and then it’s in the hands of the kernel to keep verifying or not.

Re: Lennart Poettering, Christian Brauner founded a new company

#382

Post by Gigachad »

cwillu wrote: post #96
9NRtKyP4 wrote: post #67

Remote attestation is another technology that is not inherently restrictive of software freedom. But here are some examples of technologies that have already restricted freedom due to oligopoly combined with network effects: * smartphone device integrity checks (SafetyNet / Play Integrity / Apple DeviceCheck) * HDMI/HDCP * streaming DRM (Widevine / FairPlay) * Secure Boot (vendor-keyed deployments) * printers w/ sign…

It very clearly is restrictive of software freedom. I've never suffered from an evil maid breaking into my house to access my computer, but I've _very_ frequently suffered from corporations trying to prevent me from doing what I wish with my own things. We need to push back on this notion that this sort of thing was _ever_ for the end-user's benefit, because it's not.

Remote attestation seems more useful for server hosts to let VPS users verify the server hasn’t been tampered with.

Re: Lennart Poettering, Christian Brauner founded a new company

#383

Post by notepad0x90 »

cferry wrote: post #367

Please don't bring attestation to common Linux distributions. This technology, by essence, moves trust to a third party distinct of the user. I don't see how it can be useful in any way to end users like most of us here. Its use by corporations has already caused too much damage and exclusion in the mobile landscape, and I don't want folks like us becoming pariahs in our own world, just because we want machines we bo…

Please do, I disagree with this commenter.

You already trust third parties, but there is no reason why that third party can't be the very same entity publishing the distribution. The role corporations play in attestation for the devices you speak of can be displaced by an open source developer, it doesn't need to require a paid certificate, just a trusted one. Furthermore, attestation should be optional at the hardware level, allowing you to build distros that don't use it, however distros by default should use it, as they see fit of course.

I think what people are frustrated with is the heavy-handedness of the approach, the lack of opt-out and the corporate-centric feel of it all. My suggestion would be not to take the systemd approach. There is no reason why attestation related features can't be turned on or off at install time, much like disk encryption. I find it unfortunate that even something like secureboot isn't configurable at install time, with custom certs,distro certs, or certs generated at install time.

Being against a feature that benefits regular users is not good, it is more constructive to talk about what the FOSS way of implementing a feature might be. Just because Google and Apple did it a certain way, it doesn't mean that's the only way of doing it.

Re: Lennart Poettering, Christian Brauner founded a new company

#384

Post by uecker »

Cu3PO42 wrote: post #313
direwolf20 wrote: post #301

Earlier quoted context omitted.

Secure boot is initialized by the first person who physically touches the computer and wants to initialize it. Guess who that is? Hint: it's not the final owner. It's only secure from evil maker attacks if it can be wiped and reinitialised at any time.

You seem to be under the impression that you cannot reset your Secure Boot to setup mode. You can in the UEFI, doing so wipes any enrolled keys. This, of course assumes you trust the UEFI (and hardware) vendors. But if you don't, you have much bigger problems anyway. Is it possible someone will eventually build a system that doesn't allow this? Yes. Is this influenced in any way by features of Linux software? No.

It is certainly influenced by the features of Linux software. If Linux does not support this then this preserves a platform as an escape route where this is not possible and this substantially reduces the incentive to provide certain content and services (!) only when this is enabled.

Re: Lennart Poettering, Christian Brauner founded a new company

#385

Post by filmor »

smartmic wrote: post #94
shrubble wrote: post #74

Earlier quoted context omitted.

There’s a reason why Devuan (a non systemd Debian) exists. Don’t want to get into a massive argument, but there are legitimate reasons for some to go in a different direction.

And Void Linux. And Gentoo. And Alpine Linux. And Slackware. And others.

Gentoo doesn't "exist" because it is necessary to have an alternative to systemd. Gentoo is simply about choice and works with both openrc and systemd. It supported other inits to some degree as well im the past.

Re: Lennart Poettering, Christian Brauner founded a new company

#386

Post by vaylian »

blixtra wrote: post #23
redleader55 wrote: post #6

Can you share more details at this point about what you are trying to tackle as a first step?

As per the announcement, we’ll be building this over the next months and sharing more information as this rolls out. Much of the fundamentals can be extracted from Lennart’s posts and the talks from All Systems Go! over the last years.

Probably also some of the things that were described here? https://0pointer.net/blog/fitting-everything-together.html

Re: Lennart Poettering, Christian Brauner founded a new company

#387

Post by notepad0x90 »

Nextgrid wrote: post #98
MarkusWandel wrote: post #78

My only experience with Linux secure boot so far.... I wasn't even aware that it was secure booted. And I needed to run something (I think it was the Displaylink driver) that needs to jam itself into the kernel. And the convoluted process to do it failed (it's packaged for Ubuntu but I was installing it on a slightly outdated Fedora system). What, this part is only needed for secure boot? I'm not sec... oh. So go bac…

Secure Boot only extends the chain of trust from your firmware down the first UEFI binary it loads. Currently SB is effectively useless because it will at best authenticate your kernel but the initrd and subsequent userspace (including programs that run as root) are unverified and can be replaced by malicious alternatives. Secure Boot as it stands right now in the Linux world is effectively an annoyance that’s only t…

There is the integrity measurement architecture but it isn't very mature in my opinion. Even secureboot and module signing is a manual setup by users, it isn't supported by default, or by installers. You have to more or less manage your own certs and CA, although I did notice some laptops have debian signing keys in UEFI by default? If only the debian installer setup module signing.

But you miss a critical part - Secure Boot, as the name implies is for boot, not OS runtime. Linux I suppose considers the part after initrd load, post-boot perhaps?

I think pid-1 hash verification from the kernel is not a huge ask, as part of secure boot, and leave it to the init system to implement or not implement user-space executable/script signature enforcement. I'm sure Mr. Poettering wouldn't mind.

Re: Lennart Poettering, Christian Brauner founded a new company

#388

Post by sam_lowry_ »

xorcist wrote: post #295
blibble wrote: post #163

Earlier quoted context omitted.

yeah, the fix for pulseaudio was to throw it away entirely for systemd, I don't think I have a single linux system that boots/reboots reliably 100% of the time these days

There were dozens of other init systems that, like systemd, wasn't a shell script. What set systemd apart is the collection of tightly integrated utilities such as a dns resolver, sntp client, core dump handler, rpc-like api linking to complex libraries in the hot path and so on and so forth that has been a constant stream of security exploits for over a decade now. This is a case where the critics were proven to be…

What set systemd apart was RedHat, and now Pottering repeats the old trick with Microsoft behind his back.

I think he will succeed and we will be worse off, collectively.

Re: Lennart Poettering, Christian Brauner founded a new company

#389

Post by sam_lowry_ »

fao_ wrote: post #296
bee_rider wrote: post #279

Earlier quoted context omitted.

PipeWire is like 10 years newer than PulseAudio. It probably had a chance to learn some lessons! IIRC before PulseAudio we had to mess around with ALSA directly (memory hazy, it was a while ago). It could be a bit of a pain.

I remember ALSA. Sure, it was finnicky to use `alsamixer` to unmute the master channels now and then, but I personally never had any trouble with it.

Alsa with dmix is my current setup on ArchLinux.

Re: Lennart Poettering, Christian Brauner founded a new company

#390

Post by s_ting765 »

digiown wrote: post #130
Nextgrid wrote: post #98

Earlier quoted context omitted.

Secure Boot only extends the chain of trust from your firmware down the first UEFI binary it loads. Currently SB is effectively useless because it will at best authenticate your kernel but the initrd and subsequent userspace (including programs that run as root) are unverified and can be replaced by malicious alternatives. Secure Boot as it stands right now in the Linux world is effectively an annoyance that’s only t…

A basic setup to make use of secure boot is SB+TPM+LUKS. Unfortunately I don't know of any distro that offers this in a particularly robust way. Code signature verification is an interesting idea, but I'm not sure how it could be achieved. Have distro maintainers sign the code?

Opensuse have been working on making secure boot/TPM FDE unlock easy to use for a while now. https://news.opensuse.org/2025/11/13/tw-grub2-bls/
Post reply on HN