Live data from Hacker News

Lennart Poettering, Christian Brauner founded a new company

amutable.com

691–700 of 770 posts

Re: Lennart Poettering, Christian Brauner founded a new company

#691
post #366

Earlier quoted context omitted.

I installed Gentoo in 2014 and getting PulseAudio working was much easier than ALSA. It was also much better. I get ALSA followed the Unix philosophy of doing one thing but I want my audio mixer to play multiple sounds at once.

Gentoo in 2014 had dmix enabled by default without the need for any user configuration. I know because I was using it.

I got stuck for two weeks installing the kernel because I forgot to mount /boot. Perhaps I disabled it by accident when goofing around in alsamixer? Or my card did or didn't have hardware mixing?

I didn't actually know anything about Linux at the time and started with Gentoo because I saw a meme saying "install Gentoo" and people told me not to start with that distro. So it's possible I messed up the default config by accident.

Either way PulseAudio worked after I emerged it.

Re: Lennart Poettering, Christian Brauner founded a new company

#692
post #690

Earlier quoted context omitted.

> An adversary can simply boot their own own copy of shim with whatever OS they like. They'd need to get MS to sign it first, but otherwise yea. That's why I remove the MS keys on my non-windows systems.

I don't know all the ins and outs, but because of the Machine Owner Key (MOK) mechanism in shim, it should be possible to boot arbitrary OSes without MS signing anything. Your step of removing the MS keys works of course :) Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS. Also I think that firmware updates can be problematic?

> Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS

Yea, I bricked a Gigabyte board and still haven't been able to fix it. I just replaced it with an Asrock board and that has settings for what to do with option-rom when secureboot is enabled (always execute, always deny, allow execute, defer execute, deny execute and query user) and I have no clue what half of them specifically do (like, does "allow execute" only execute if a matching key exists and doesn't execute if it doesn't? and what is the difference between "always deny" and "deny execute"? and defer to when??). But I just set it to always execute and my problem is solved.

Re: Lennart Poettering, Christian Brauner founded a new company

#693

Earlier quoted context omitted.

To play devil's advocate, I don't think most people would be fine with their car ramming into a military base after an unfriendly firmware update. However, I agree that the risks to individuals and their freedoms stemming from these technologies outweigh the benefits in most cases.

If a malicious update can be pushed because of some failure in the signature verification checks (which already exist), what makes you think the threat actor won’t have access to signing keys? This is not what attestation is even seeking to solve.

Firmware upgrades don't need to use the same protocols. Without secure boot any applet can take a security hole escalate and persist until you take a trip to a zone of interest. With secure-boot+attestation, the vendors can choose not to let you download the latest map data, report you to the authorities, etc.

Why do people take DA as "Hail Satan" anyways.

Re: Lennart Poettering, Christian Brauner founded a new company

#694

Earlier quoted context omitted.

Not all. The ones that ship Linux preinstalled and with support don't.

I hope you are mistaken. It's embarrassing how far behind in security the desktop Linux ecosystem is.

I believe you are confusing security with freedom and "behind" with "advanced".

Re: Lennart Poettering, Christian Brauner founded a new company

#695

Earlier quoted context omitted.

I hope you are mistaken. It's embarrassing how far behind in security the desktop Linux ecosystem is.

They have a TPM that you can enable and add your own keys if you want to.

For now.

Re: Lennart Poettering, Christian Brauner founded a new company

#697
post #40

The immediate concern seeing this is will the maintainer of systemd use their position to push this on everyone through it like every other extended feature of systemd? Whatever it is, I hope it doesn't go the usual path of a minimal support, optional support and then being virtually mandatory by means of tight coupling with other subsystems.

Daan here, founding engineer and systemd maintainer. So we try to make every new feature that might be disruptive optional in systemd and opt-in. Of course we don't always succeed and there will always be differences in opinion. Also, we're a team of people that started in open source and have done open source for most of our careers. We definitely don't intend to change that at all. Keeping systemd a healthy project…

> we try to make every new feature that might be disruptive optional in systemd and opt-in

I find it hard to believe. Like, at all. Especially given that the general posture of your project leader is the exact opposite of that.

> systemd a healthy project

I can see that we share the same view that there are indeed differences in opinion.

Re: Lennart Poettering, Christian Brauner founded a new company

#698

Earlier quoted context omitted.

Hi Daan, Thanks for the answer. Let me ask you something close with a more blunt angle: Considering most of the tech is already present and shipping in the current systemd, what prevents our systems to become a immutable monolith like macOS or current Android with the flick of a switch? Or a more grave scenario: What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boo…

So adding all of this technology will certainly make it more easy to be used for either good or bad. And it will certainly become possible to build an OS that will be less hackable than your run of the mill Linux distro. But we will never enforce using any of these features in systemd itself. It will always be up to the distro to enable and configure the system to become an immutable monolith. And I certainly don't t…

> we will never enforce using any of these features in systemd itself. It will always be up to the distro

So, plausible deniability. It's not the systemd project, it's the distro.

> I certainly don't think distributions like Fedora or Debian will ever go in that direction.

In the past they made decisions that we can call unexpected. I believe that in the short term future they won't but in say ten years? I'm not sure. The technology (created by Amutable?) will be mature by that time and ready to close Linux down.

Re: Lennart Poettering, Christian Brauner founded a new company

#699

Earlier quoted context omitted.

Hi Daan, Thanks for the answer. Let me ask you something close with a more blunt angle: Considering most of the tech is already present and shipping in the current systemd, what prevents our systems to become a immutable monolith like macOS or current Android with the flick of a switch? Or a more grave scenario: What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boo…

> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle, hence every Linux distribution has to go through Microsoft's blessing to be bootable? Why are you buying hardware that Microsoft controls if you're concerned about this?

With TPM, Microsoft controls practically all the Intel hardware.

Re: Lennart Poettering, Christian Brauner founded a new company

#700

Earlier quoted context omitted.

Hi Daan, Thanks for the answer. Let me ask you something close with a more blunt angle: Considering most of the tech is already present and shipping in the current systemd, what prevents our systems to become a immutable monolith like macOS or current Android with the flick of a switch? Or a more grave scenario: What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boo…

> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle Theoretically, nothing. But it's worth pointing out that so far they have actually done the opposite. They currently mandate that hardware vendors must allow you to enroll your own keys. There was a somewhat questionable move recently where they introduced a 'more secure by default' branding in which t…

> today. Of course this may change down the line.

Given Microsoft's track record I don't believe this will stay that way for long.

Post reply on HN