Live data from Hacker News

Lennart Poettering, Christian Brauner founded a new company

amutable.com

121–130 of 770 posts

Re: Lennart Poettering, Christian Brauner founded a new company

#121
post #90

Earlier quoted context omitted.

Drive encryption is only really securing your data at rest, not while the system is running. Ideally image based systems also use the kernels runtime integrity checking (e.g. dm-verity) to ensure that things are as they are expected to be.

“ensure that things are as they are expected to be” according to who, and for who's benefit? Certainly not the person sitting in front of the computer.

This is only the case if the person sitting in front of it does not own the keys.

Re: Lennart Poettering, Christian Brauner founded a new company

#122
post #82

Earlier quoted context omitted.

"Just don't use X" doesn't solve any problems in any space, unfortunately. Plus, it's an avoidant and reductionist take. Note: I have nothing against BSDs, but again, this is not the answer.

It works for me and for millions of others. Stop trying to make everyone act like you act.

> Stop trying to make everyone act like you act.

Yeah! Telling people what to do is rude!

> Anyone still using Linux on the desktop in 2026 should switch

Oh.

Re: Lennart Poettering, Christian Brauner founded a new company

#123

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…

I am quite conflicted here. On one hand I understand the need for it (offsite colo servers is the best example). Basic level of evil maid resistance is also a nice to have on personal machines. On the other hand we have all the things you listed.

I personally don't think this product matters all that much for now. These types of tech is not oppressive by itself, only when it is being demanded by an adversary. The ability of the adversary to demand it is a function of how widespread the capability is, and there aren't going to be enough Linux clients for this to start infringing on the rights of the general public just yet.

A bigger concern is all the efforts aimed at imposing integrity checks on platforms like the Web. That will eventually force users to make a choice between being denied essential services and accepting these demands.

I also think AI would substantially curtail the effect of many of these anti-user efforts. For example a bot can be programmed to automate using a secure phone and controlled from a user-controlled device, cheat in games, etc.

Re: Lennart Poettering, Christian Brauner founded a new company

#124

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…

> * Secure Boot (vendor-keyed deployments) I wish this myth would die at this point. Secure Boot allows you to enroll your own keys. This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.

> Secure Boot allows you to enroll your own keys

UEFI secure boot on PCs, yes for the most part. A lot of mobile platforms just never supported this. It's not a myth.

Re: Lennart Poettering, Christian Brauner founded a new company

#127
post #90

Earlier quoted context omitted.

Drive encryption is only really securing your data at rest, not while the system is running. Ideally image based systems also use the kernels runtime integrity checking (e.g. dm-verity) to ensure that things are as they are expected to be.

“ensure that things are as they are expected to be” according to who, and for who's benefit? Certainly not the person sitting in front of the computer.

The system owner. Usually that is the same entity that owns the secure boot keys, which can be the person that bought a device or another person if the buyer decides to delegate that responsibility (whether knowingly or unknowingly).

In my case I am talking about myself. I prefer to actually know what is running on my systems and ensure that they are as I expect them to be and not that they may have been modified unbeknownst to me.

Re: Lennart Poettering, Christian Brauner founded a new company

#128
post #18

Earlier quoted context omitted.

The events includes a conference title "Remote Attestation of Imutable Operating Systems built on systemd", which is a bit of a clue.

I'm sure this company is more focused on the enterprise angle, but I wonder if the buildout of support for remote attestation could eventually resolve the Linux gaming vs. anti-cheat stalemate. At least for those willing to use a "blessed" kernel provided by Valve or whoever.

I sincerely hope not.

Re: Lennart Poettering, Christian Brauner founded a new company

#129
post #65

Exciting! It sounds like you want to achieve system transparency, but I don't see any clear mention of reproducible builds or transparency logs anywhere. I have followed systemd's efforts into Secure Boot and TPM use with great interest. It has become increasingly clear that you are heading in a very similar direction to these projects: - Hal Finney's transparent server - Keylime - System Transparency - Project Oak -…

I'm super far from an expert on this, but it NEEDS reproducible builds, right? You need to start from a known good, trusted state - otherwise you cannot trust any new system states. You also need it for updates.

Well, it comes down to what trust assumptions you're OK with. Reproducible reduces trust in the build environment, but you still need to ensure authenticity of the source somehow. Verified boot, measured boot, repro builds, local/remote attestation, and transparency logging provide different things. Combined they form the possibility of a sort of authentication mechanism between a server and client. However, all of the concepts are useful by themselves.

Re: Lennart Poettering, Christian Brauner founded a new company

#130

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…

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?

Post reply on HN