Viewing Poettering as some kind malicious entity undermining projects sounds like a conspiracy theory. But now with him working for Microsoft his actions do look like a lot like the "embrace, extend, and extinguish" pattern to me. Yes, yes "Microsoft <3 Linux", of course...

And now I am supposed to cheer for the groundwork for the creation of an allmighty authority with the ability to "sanction" some (parts of) operating systems, but not others?

https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

All I can see is that Microsoft mandate that laptop hardware sold with Windows installed have secure boot capability and that the MS-signing keys are shipped in the TPM. This has been true for, what, over 10 years?

How are they making things harder?

[1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

I'm not sure that's the same thing as Microsoft making it harder in general for people to bring and use their own keys (or just turn it off altogether).

UEFI Drivers can be Option ROM on the PCIe cards, commonly found of graphics cards. If you where to leave this certificate out of your boot chain, how would you validate this drivers? Well, you can't.

This results in your not having any GPUs and your device is "bricked" until you can hopefully piggyback on something else. It's not really a proper brick.

This is just a design flaw in my opinion. Microsoft taking the easy route for being the org responsible for signing UEFI code when there was no other options (LetsEncrypt wasnt a thing in 2010/2012). And I don't think Microsoft envisioned themselves in the position they are currently inn.

There are workarounds though, you can read the drivers loaded during boot from the TPM Eventlog and enroll each driver into the approve list for Secure Boot (The `db` variable). But this isn't necessarily future proof if anything changes.

I think the current policy is here:

https://techcommunity.microsoft.com/t5/hardware-dev-center/u...

It doesn't mention kernel mode. The focus on kernel mode may not even be appropriate because many bad things can happen without kernel mode (wiping local disks, operating the hardware beyond safe parameters).

Systemd is not making the alternatives more difficult to maintain, the alternatives are more difficult and more difficult to maintain. Matter of perspective, really.

It's a very MS approach instead of a UNIX - do one job.

Having a world writeable initrd - that is an fs image with executables to be run as root before any other security settings have been enabled (etc) has always struck me as a bad idea.

Yes I'm aware that this technology, like literally every other technology ever invented (from the pointy stick all the way up), can be used for evil. That is a human problem not a "this technology exists problem"...

> ...the groundwork for the creation of an allmighty authority with the ability to "sanction" some (parts of) operating systems, but not others

"We must backdoor/ban all crypto because imagine what the criminals would do with it!"

So if we want to actually change this, we should aim to create another CA, not attack sysD or secure boot(though its design is stupid to rely on Microsoft but it's too late now).

I don't trust these groups or corporations so I'll stick to custom keys for this stuff, but I think having a working group with a signed boot loader is much better than the current situation (Microsoft signs a shim that basically bypasses secure boot on some devices and then Linux users set up a Rube Goldberg machine of 4 different levels of bootloader to get verified boot working).

I'm running the MS shim right now and I don't see why the systemd shim would be worse in any way.

>“Democratize” use of PCR policies by defining PCR register meanings, and making binding to them robust against updates, so that external projects can safely and securely bind their own data to them (or use them for remote attestation) without risking breakage whenever the OS is updated.

In what world is this a good thing? This is a one way street to an all seeing police state. I never had a problem with systemd from a technical perspective but looks like Poettering is drinking the TCB kool aid by the barrel.

This (especially) includes the machine's firmware and kernel because that's where malware could effectively hide itself from countermeasures deployed on the machines directly.

If I can then also make sure that the various admin interfaces in our network can only be used by machines in a known-good state, I would sleep ever so much better knowing that the various hacks we have seen happening to 1Password, Uber, etc this year cannot happen on my network.

I would even say that this is helpful for my users because they will never risk being "the one who let the ransomware in".

This isn't about your own private machine. This is about corporation-owned machines in an enterprise network and as we see with nearly biweekly news articles about large-scale ransomware attacks, private data leaks and compromised employee machines, I would argue that the currently employed solutions clearly don't work.

Not wishing to pick on you personally, but the above paragraph is wonderful example of the sort of logic going around that bothers me.

You trace a faultless journey from responsibility to desiring total control.

That's not what responsibility is.

You're describing the feeling of culpability within a brutal regime - where Vader simply force-chokes a lieutenant for "failing me once too often".

Responsibility involves leadership, which involves not stripping every subordinate of their agency, dignity and humanity. It involves trusting people. Sadly, computers make a "zero trust" ecosystem far too easy now, and that's how they can destroy our society. Good computing is figuring out ways to preserve liberal democratic society while also improving it.

It’s not that you can’t trust your employees. It’s that you can’t trust them to defend themselves from being mugged.

The forcing function for all this removal of freedom is defense against malicious hackers. The removal of freedom is not the goal so much as a side effect.

It works the same way in the real world. We would not need borders or armies or police if everyone were nice.

> The problem isn’t that you can’t trust people.

Good. It's always best to have an optimistic view of our fellows, that's how we build good social structures.

> The problem is that people are defenceless in the face of malicious hackers

So. Make then not defenceless. We arm them. With education and other tools they need to defend themselves. Digital Self Defence (Or Digital Literacy 2.0 if you want a fluffier title) is the project I am committed to. Defensive tools belong in the hands of users.

> with vastly more expertise

We can balance the theatre twofold, by giving people more defensive capability, knowledge and rights, and by attacking the knowledge base and knowledge value of malicious actors. We must recognise that many of our own institutions play part of the problem, from vendor malware, and backdoors to security disinformation. Cyber-law needs radical reform to give end-user better security rights, and "surveillance capitalism" needs dragging to the dock.

> zero day vulnerabilities.

Starting maybe with an all out assault on "zero days", including the companies, agencies and re-sellers of them, using the law.

> It’s that you can’t trust them to defend themselves from being mugged.

Part of ones job then, is to enable them to defend themselves. You cannot follow your children around for the rest of their lives in case bullies pick on them. You need to teach them fighting skills so they won't be doormats. That's the reality of the digital workplace today. Also, don't give your kids gold Rolex Oyster watches and diamond rings to mooch around scuzzy neighbourhoods with. Limit assets, practice compartmentalisation. Half an ounce of sensible opsec is worth a ton of authoritarian technical non-solutions.

> The removal of freedom is not the goal so much as a side effect.

The removal of freedom is NEVER an acceptable "side effect" of any security action. Security and freedom are not diamtrics. Otherwise "the terrorists win" and one may as well join the ranks of malicious principles and directly attack our own people (which is the stance many US agencies have taken since 2001 toward baby and bath-water alike)

> real world ... borders armies police

But this isn't the real world. Its a digital one which is different. The old military model of perimeters and weapons isn't working and smart people in cybersecurity know that. The collateral damage of that broken model is our digital economy and liberal democracy itself (which are intimately linked in the American/Western mind if you believe one jot in things like startups and entrepreneurialism).

We'll simply have to do better than handing over the responsibilities of our elected guardians to unelected companies considered by some [1] to be criminally motivated. We still have laws, schools and hopefully enough common sense to avoid that.

EDIT: subtracted fulmination.

[1] https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor.... https://en.wikipedia.org/wiki/Microsoft_litigation

Perhaps the hopeless people you describe are the product of a hopeless context - the "enterprise context" you mention. That culture seems to encourage intellectual sloth and shrugging ambivalence, and you give good examples.

> Go look at /r/sysadmin or /r/

Please, I'd rather not :)

> executives who believe they're above things like "phishing awareness campaigns

My goodness I've met them. They're basically paid too much. I had to make a humint/influence piece for a major bank in London. Cybersec referred to it as "the cock problem"; basically mostly male with high six figure salaries whose security weakness was they "don't give a fuck". Same kind of fellas who would get pissed-up and drive their Aston Martin DB into a children's play-park. Major liability. They've learned they can transgress with impunity and just use money to solve it. What do they care if other people's money gets hacked? Not the best model for business, which requires a more upright mind-set to excel at. But banks don't exactly need to compete in a real business world.

> Technical measures are much cheaper and vastly more effective

Only in the short term. You'll need to forever keep your technical measures one step ahead of the mixture of malice and idiocy out there. A changed culture replicates and even grows itself.

But ultimately, while I always wanted people to take training courses in computer use, I still implemented security measures, because I knew that people were at the company to work, not to take training courses. I want security measures in place for the same reason I want computers in the first place: so that I can let the computer worry about it for me. I don't want to have phishing awareness campaigns when I can just make the spam filter more effective. I don't want to tech people not to click the flashing greed download button when I can just roll out an ad blocker across the entire organization. I don't want to send an emergency email blast to my coworkers telling them not to download TOTALLY_NOT_A_VIRUS.PDF.EXE from the chain email going around and keep one step ahead of the mixture of malice and idiocy out there when I can just set up a system to scan email attachments for viruses in the first place. Yes, I want a more informed and educated workplace, and I worked to make that happen, but I want computers to work for me and do the hard part for me as well

What we need to do with Digital Self Defence is raise awareness of civic cyber-security needs from school ages 5 upwards (My government in the UK have started on this project). We also need to screen for digital literacy.

The goal to teach people how technology works is admirable and necessary, but it is no defence against a motivated attacker. The attackers will always have a massive information advantage just because they have so much more time to aquire it.

The fundamental issue is that you can't have one without the other, and that's bothering me. It's not like only corporate grade laptops come with TPMs now (like they did in the past).

Safetynet on my phone is the same thing and it's very much "about my own private machine". Seeing the reactions and the lack thereof about these developments makes me think this will end terribly.

AFAIK, secure boot can be disabled, both in the BIOS and in the Kernel.

In some machines that's not be the case due to contracts with Microsoft, but those already can't run Linux in the first place, so you probably won't buy them for the purpose of running Linux.

The suggestions in the original post do not change anything about this.

I want to be able to access all services with whatever client I please. Not be required to run approved software and hardware that puts them in control.

So.... vote with your feet and choose a bank that shares your values more closely?

That never worked and will not work now. You can't choose something that's not being offered.

EDIT:

Also,

> It sounds like you're demanding to use someone's service on your own terms.

Well, sort of; a service agreement is a relationship, and TPM/remote attestation is a huge overreach by the corporate party. It's only fair to want to push back on what's becoming an abusive relationship.

Why do you think you're entitled to something that's not being offered?

I think there's a general point here about how retail banking is not really an ideal free market, because the barrier to entry is too high. If no bank is providing a set of services that fit the compromises you want to make, then either your problem is with the government (who arguably over-regulate the space) or not enough people share your values to warrant creating a banking business around it.

> Well, sort of; a service agreement is a relationship, and TPM/remote attestation is a huge overreach by the corporate party. It's only fair to want to push back on what's becoming an abusive relationship.

On the flip side, the bank has to manage a complicated series of risks, and their investors might not want to pay the mitigation costs of the risks created by allowing anyone to use their service however they like. Hence the ToS.

It's not that I feel entitled, and more that I'm required to use a bank to not starve, or at least to participate in the modern society. I'm not in this relationship by choice, I'm forced into it at metaphorical gunpoint by the economy.

And, it still means the advice to "vote with your feet" is invalid. I have no one to vote for.

> there's a general point here about how retail banking is not really an ideal free market, because the barrier to entry is too high.

There's an even more general point here, that this applies to pretty much every good and service. Not just banking, not just phones, not just computing. It applies to cars and clothes and food and housing just as well. Hence me saying that voting with your feet/wallet doesn't work in general. Mature markets end up supply-driven - vendors collectively decide what choices are available; the only way to have a vote is to become a vendor yourself, which is a long, hard and risky process.

> On the flip side, the bank has to manage a complicated series of risks, and their investors might not want to pay the mitigation costs of the risks created by allowing anyone to use their service however they like. Hence the ToS.

Sure. There are conflicting interests here. But the right answer isn't one party dictating how the entire relationship works. That's abuse.

At my last job, it was impossible to be paid except by direct deposit into a bank account. At certain times during the past couple years, it was impossible to go into my bank to do any transacting. I feel like I should be able to have a job without needing a smart phone and an app.

They are not obliged by law in any way. However leading up to this point, whatever happens on my side of the network socket has been my discretion. Disrupting this dynamic just bothers me.

For now.

I wrote about this nearly a decade ago:

https://www.theregister.com/2013/11/14/microsoft_surface_rt_...

AFAIK, rather than make the firmware unlockable, MS sent vast amounts of inventory to landfill.

1. If the user can supply private keys that are treated as first class citizens, then yay!

2. If the user can't supply private keys, or the user's private key is treated as a second class citizen, then boo.

Given who is driving TPM usage right now (ie: Microsoft), my intuition says situation 2 is far more likely. I'm continually surprised by the number of people who think this is an unreasonable and/or paranoid.

Secureboot is a scary technology but as long as we can disable it and provide our own keys I don't see the problem. And if we lose these abilities than I'm certain it won't be Poettering or systemd to blame

Thanks to remote attestation, the custom ROM scene for Android is pretty much dead now, because there's little point of customizing the OS when it automatically makes important services no longer accessible from the phone.

The problem is that if you are inside a project developing something like this, you can clearly visualize your expected use case, but it's impossible to know what other use cases will be contrived. Of course in this case, we have predicted a few major malfeasances and I think anyone supporting a project like this needs to know the harmful use cases and be responsible for developing with them in mind.

The traditional boundary is one drawn by device ownership: my device, my rules; their device, their rules. I.e. my phone can do whatever, their servers can refuse working with me.

Remote attestation is at best a way for simplifying their own service, at a big cost to users' freedom. In reality, it's a bit of that, plus mostly making sure the customers are locked into a bank-controlled channel that can be used to upsell more financial products.

Your device your rules seems to cover this, too: they’re saying they don’t want to do business under other rules – the app is just showing the UI for that policy client side.

It’s frustrating but that seems not unreasonable given the massive ratio of people being compromised versus intentionally customizing the OS. I miss the free-for-all of the 90s in some ways but statistically zero of the non-IT people I know wouldn’t hand root on their phone over to some guy in another country based on a prompt on a webpage.

I guess I see two problems here:

1) They shouldn't be allowed to make that policy in the first place. Their policy is effectively dictating what devices I can own and what can I do with them, which is unreasonable when the devices in question are general-purpose computers.

2) My device is being used against me and against my wishes here; I'm not sure who's more to blame here - the bank for taking advantage of the API, Google for providing it, or the phone vendor for implementing it and locking me out of it, or Google again for effectively forcing the phone vendor to lock me out of it.

> I miss the free-for-all of the 90s in some ways but statistically zero of the non-IT people I know wouldn’t hand root on their phone over to some guy in another country based on a prompt on a webpage.

There must be some other way of handling it. We wouldn't have the Fisher-Price tech of 2020s without the free-for-all 90s! The ability for technically proficient users to do whatever the hell they want with their own general-purpose computers is fundamental to developing new technologies, products and services, and better alternatives to existing ones. Between Fisher-Price consumer tech and locked down corporate tech (because security!), it looks like we're heading for an era where a general-purpose computer will be something available only to few certified employees in corporate-sponsored labs.

In terms of practical security, custom ROMs are often safer than the forgotten and obsolete software left on a device when updates stop rolling out. Sandbox escapes and exploits to get root access are more realistic threats than airport security flashing a different OS through your phone recovery or some kind of conspiracy to stuff malware into an open source repository.

As long as you take care to only install software from reliable sources (i.e. download.lineageos.org, F-Droid.org) I don't see the problem.

That’s not a theoretic DRM issue, but a practical attack on the software ecosystem.

The complexity and bugs of these "protections" is likely to cause more actual security issues AND headaches to average users than the "evil maid" scenario these blog posts like to speak of.

Don´t you love our modern leaders?

You jest, but a weaker form of "you can usually trust the police and governments today to do the right thing" is very much true for regular citizens in civilized countries.

The two problem cases are 1) people working to keep those governments in check, which is a necessary function for their operation but one that, by definition, said governments don't like, and 2) the private sector. The private sector can, and will, abuse everything it can get its hands on, to the extent permitted by the most strict reading of the letter of the law.

The "Wind West internet" is very much alive, but as it was in the 90s, its hidden and far away from the "normal" users. And regarding the part with the "suck it up and get on with your life" - I always was a "Don Quijote" type personality, i don't think i will change this attitude...

Yeah, sure - in a fantasy dream world. But the real world has a bit more sophisticated cyberattackers that will find a way in. And at the same time normal and powerusers of computers will have to deal with all the total-control-state-class "security" measures.

This looks pretty the same as "think of the children" censorship.

Simply storing hashes that are set on first boot (much like SSH does with known host hashes), and allowing the user/OS to reset the hashes, will be sufficient. M1 does this, as far as I know.

> Remote attestation because you can NEVER trust the client.

IRL, I don’t carry a weapon everywhere I go, because it’s clearly overkill. For this exact reason, overkill measures like remote attestation should not be a thing on general purpose computers.

But regardless, this entire article is about how to have an actually secure boot on Linux (and not remote attestation), something which is certainly good for the user. Otherwise you're actually more easily susceptible to malicious actors stealing your data on the system you "trust". None of the steps listed here require trusting anyone other than the TPM (which is admittedly a flaw so long as we cannot audit them) and you can even use your own keys in pretty much all cases (provided -as discussed in other comments- MS hasn't f'd that up). I personally use a boot-stub based booting method with my own SB keys (but ironically, don't encrypt my root, so go figure), so I can vouch for the fact that it was actually quite painless to setup. Please don't jump down the slippery slope before you actually try these methods and realize that this is just as easy to deploy (you only need to disable secure boot first) and certainly a more secure option than using shim and an unsecured initrd.

Also, I don't understand where remote attestation entered the conversation here, and I also don't see why that can't be a community based thing (al la let's encrypt is now everyone's CA) where you can choose your providers or even roll it yourself.

• provided ... MS hasn't f'd that up

I think you pinpointed the two reasons people are fuming about this.

Same here - stub, kernel, initrd and embedded cmdline all in a signed UKI on the ESP. I do encrypt my root however, so I wouldn't go as far as "painless" for the grub->efibootmgr switch (but I also switched initramfs generator so... always keep a rescue stick around).

But it's all about ownership and trust. I control the keys - hence I am the owner of my computer - and I don't trust e.g. Microsoft[1] to not eventually try to fuck me over. But that's not the important part.

> Also, I don't understand where remote attestation entered the conversation here, and I also don't see why that can't be a community based thing (al la let's encrypt is now everyone's CA) where you can choose your providers or even roll it yourself.

Remote attestation is mentioned five times in TFA and is where this can get really pernicious - indirectly limiting user choice because $safety_critical_industry (e.g. banking) only allows "the corporate keys" (likely including a few Linuxes too, but something like Gentoo couldn't be). They'll even have very good and completely valid security reasons for not allowing arbitrary user keys, but they'd lock me down to approved choices remotely. A reverse AGPL if you will.

Of course, workarounds will exist: "just multiboot", "just use multiple devices", "just choose the bank that allows you to whitelist your key" (assuming there is one, it's nice to dream) - but user freedom is reduced without malicious intent being strictly necessary anywhere in the process.

That's focusing on the negatives with my paranoiac hat on, of course.

[1] https://www.theregister.com/2022/07/07/lennart_poettering_re...

Oh man that takes me back. The last time I went down that rabbit hole was ~2015, I tried to implement a "fully encrypted" setup and started with Ubuntu (I know I know). Something something LUKS.

I spent ~2 days tinkering with it and never got it to work, something with the setup flow was totally broken if you also tried to encrypt root (or boot? idk like I said it's been _years_).

I also remember fun problems with grub. I was trying to dual-boot and the windows partition was using hardware-bitlocker (samsung SSD). Some kind of weird interaction was going on between grub, whatever the windows bootloader is called, and my motherboard's EFI I think. Anyways grub ended up fucking bitlocker up and I almost lost all my gaming saves. Had to use some kind of arcane recovery process to get back to being able to even _insert_ the key so the SSD would unlock and windows could continue booting.

Ended up saying screw it after a few days and just going back to windows for my gaming PC, vowing to never try dual-boot again.

More recently, you can even set up GRUB to ask you for the passphrase, so even /boot is encrypted, you only need a tiny 2MB partition at the front to hold the bootloader.

I had to set some kind of kernel flag or something (sorry, it's been years) to get it to ignore the drive until I unlocked it, as there was some kind of tight-loop where it would just keep trying to connect infinitely and not progress/fail/timeout.

I've been meaning to get back into linux again but it's going to be on a pristine/new machine.

This worked fine.

Months later (in this case I just left it connected to a TV and occasionally used it for gaming or whatever) I let it do an OS upgrade and it forgot how to read its disk when it rebooted. I spent maybe 30 minutes trying to fix it (former heavy Gentoo user, so I'm comfortable troubleshooting boot—among other—issues) without making any progress at all, then decided that was the end of that particular check-in with desktop linux. Maybe next time (spoiler: nope, though for different reasons. But maybe the next next time...)

I haven't tried encrypting a Linux root disk since.

That sounds way too exciting, even without that involved I keep my Windows install on its own disk.

With hardware FDE the data written to the raw flash is always encrypted, the AES key is just 0 by default. Macs work this way AFAIK. With "hardware bitlocker" you just change that key (on a fresh drive).

Full performance, better security. Seems awesome huh? Well being outside the happy-path when it comes to hardware configs on free software is just asking for trouble...

I don't trust Poetteringware. Poettering's team has a record of foisting technology on users, resulting in the need for e.g. the Devuan fork. I wish this work were being done by just about any other team than Poettering's.

They have been developing software, that enough people have deemed useful to include it in their distributions. Some have disagreed, and have made other choices. No one was forced to do anything, there have been no "foisting" and the "need" for Devuan is a subjective opinion.

There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development.

Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything. People got systemd on their OSes because they chose OSes whose developers chose to move to systemd.

It's not like Lennart comes to your home with a gun if you install OpenBSD.

The ramifications of those technical choices on the software ecosystem are so well understood [0], that there is no point in discussing "their own merits" in a vacuum.

What's most relevant to my professional and waning hobbyist interests are the shape and trajectory of the software ecosystem as a whole. To talk about systemd without talking about how it's developers interact with the software ecosystem is to talk about nothing.

[0] I graduated before systemd was a glint in Pottering's eye, but we somehow still covered it in school. Not only coupling vs cohesion in the abstract, but also how various design decisions (including init system arguments of old!) interacted with the ebb and flow of unix-like OS evolution.

They can't. GNU was a political project from day 1, with explicitly political goals; the unix-like design is for political, not technical, reasons.

> Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything.

Citation needed. If you maintain a widely-used open-source project there's a pretty strong social norm/pressure to merge contributions that don't have anything obviously wrong with them, even if the functionality they implement is something you don't actually want or need.

> People got systemd on their OSes because they chose OSes whose developers chose to move to systemd.

Because they chose OSes whose non-technical leadership chose to move to systemd, in violation of the project constitution, and then had the rump technical committee rubber-stamp it once the principled technical leadership had resigned in disgust and the decision was already a fait accompli, the way I remember it.

> It's not like Lennart comes to your home with a gun if you install OpenBSD.

Some will rob you with a six-gun, and some with a fountain pen. No, Lennart won't hack into your computer with an SSH exploit, but he'll get the software you're using (like Gnome) to push updates that stop it working on your computer, and so the end result ends up much the same.

While I agree with you in general, for some reason this particular developer tends to take decisions that have very extensive consequences and make choice extremely difficult.

He definitely isn't perfect but this sounds like quite the feat in Open Source.

*PulseAudio was simply broken but it's not the fault of the author distros picked up aplha-quality software

Someone made a decision, others didn't like it so forked. Sounds like open source is working exactly as it should?

This isn't very accurate. When Debian decided to switch to systemd, they also agreed to support other inits in the distribution.

This wasn't good enough, so Devuan itself was forked before this decision was made. The end result is that Debian had less people to support the init script alternatives. It became a self-fulfilling prophecy.

I'm confident Debian could support other inits if there was more Debian devs available to work on it. But because people left for Devuan the pool becomes smaller.

Even the last decision on inits from Debian says that the focus should not solely be on systemd.

https://lwn.net/Articles/808217/

That's true, but with systemd being the only init that packages had to support. Accordingly many package maintainers choose to only support systemd.

So if you want to run Debian without systemd, you have to be prepared for your fave packages to drop support for the other inits. It follows that you can't rely on the Debian package repository. So to support a Debian-like system without systemd, you have to fork the whole repository.

Devuan has init-script support for the packages in its repository. So it's open to the Debian maintainers to pull the scripts in; but they only want to support one init system, understandably. And the fact that nearly all other distros have systemd as a default init, it's natural that developers and maintainers are pleased with the systemd hegemony.

I'm just sorry that Debian made the decision it did. But Debian has always been the developers and maintainers; only incidentally the users. They were entitled to make that decision, and I think their process was exemplary.

[Edit] That "exemplary" process: actually I think it shouldn't have been pushed to the technical committee. It should have been a simple general resolution from the start. But I think the result would have been the same, and I found the debates very illuminating.

Highly inaccurate

FTFY

My point was a political one, I guess: this is more software that runs very deep in the system, coming from a team that has a record of producing software that is hard to opt-out of.

For PulseAudio on Debian, you have to take firm steps to ensure the package manager doesn't reinstall it. Much the same goes for systemd. I assume it will be much harder to opt-out of a secure boot released by that team. I believe that's on purpose: they could have made it easier to run without those packages, if they'd wanted to. I think it's clear that they wanted the opposite.

Please don't fan this flame.

Also brittle and unreliable. Every distribution needed custom-made init.d script, incompatible with every other distribution. No, thanks.

> systemd has everything and a kitchen sink, it is a big blob of software.

You can still pick and choose. Systemd is an umbrella project.

> Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver

systemd-resolved is exactly one of the things that you can pick and choose.

> was the final thing that made me question sanity of distro maintainers

And there are good reasons for that:

1) /etc/resolv.conf cannot be extended; you cannot express all the configuration that is needed for resolver today (e.g. per subnet zones) or dynamic enough (user-managed network links that go up and down).

2) applications are not supposed to use resolv.conf directly anyway; if they do, they are broken. The local nss config may be such, that they won't be able to find all hostnames, or the above mentioned per subnet zones, which they won't be able to resolve. Hence, they are supposed to use libc, which does the right thing. Even golang runtime respects this and thunks into libc for nss.

Maybe conceptually simple, but far from it in terms of reliability, predictability and ease-of-use.

> Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing [...]

So you read the comment at the top of the file and that made you question someone's sanity?

The slippery slope is not a fallacy if the slope is, in fact, slippery.

E.g. for my bank the app is the only 2FA option that doesn't come with additional costs.

The saving grace is that attestations can be forwarded but I'm sure even this will eventually get solved. (And the sheer fact they can be forwarded doesn't diminish the dangers of this use of the technology.)

That would require you to have root on a "trusted" device so you can extract the challenge-response that proves you are indeed "trusted". Which is becoming increasingly harder with each iteration.

This isn't a slippery slope, this is a vertical surface that was erected over seven years ago when SGX hit the market, just standing there.

Luckily the content I watch on Netflix is also freely available through torrents so I don't usually notice the difference, but the DRM fight was lost long ago. Whatever evil things the government is planning on enacting won't be beaten by someone telling the police officers that they use Arch btw.

[1] https://www.gnu.org/philosophy/loyal-computers.en.html

[2] https://www.gnu.org/philosophy/right-to-read.en.html

Sorry, but I expect my Linux install to be at least as secure as my Windows (Pro) installation. And without this, it's not. It's that simple. In years, most of you will be benefiting from this, it will become table stakes and the FUD will subside.

It's hard to really read this thread. If you care about user freedom, this sure ain't got nothing to do with it. Other than giving me the freedom to have a more secure computer.

Just sad to see the FUD cause people to just get so activated without even understanding the stakes at hand. (Think. It's not like MS is watching this feature to decide whether or not to allow user-key-enrollment on the ARM Surface).

Adding the fact that said company is designer, enforcer and gatekeeper of such technology makes everything more worrisome.

Lastly, telling that people are spreading FUD against the company which defined and is synonymous with FUD is ironic.

That’s all,

Thank you.

Please, you must understand, you devalue your point by demonstrating that you either don't understand the layering at play here, and where the real risks are, or you don't care to advocate in any sort of meaningful or compelling way. Instead, you just repeated FUD and waved your arms more. Again, about something we probably agree about, but is simply not at hand here.

I mean the issue that you're worried about? How about the millions of capable smartphones being tossed because of closed bootloaders? Android manufacturers, Google's Nest and Chromecast products, and Apple's iOS devices here are far greater offenders. And just more insidious. My 3 year old phone that works damn fine is considered literal garbage by Google (no security updates, means I use Lineage, means I can't bank, watch Netflix, use credit card apps, and more). Microsoft has never used security features to invalidate my old hardware. Ever.

Again, totally tangential from whether or not SystemD has first-rate support for this (mostly because at this point it's about UX and distro mechanics such that users and distros can freely secure their computers. The functionality to just lock-er-down has been here. For a decade). This issue is about capitalism, economic incentives, social politics, etc. But, I don't expect that conversation to play out on this site much.

Finally, Pixel and Chromebook prove that secure computing AND user freedom CAN be respected and can be user-empowering. Please, if you care, advocate for their models. (Which, again, I can also do on all x86 Microsoft devices and Microsoft Surface ARM, at least, today).

I'm all in favor of secure boot as long as I can enroll my own keys, but remote attestation gets scary quickly.

(Shakespeare: The Tempest)

Am I misunderstanding, or is the the only attack scenario listed?

Seems like a lot of work, complexity and potential problems of all sort to fix.. something quite minor?

I mean: 1) Get a lock? 2) Will it actually stop an Evil Maid? I'm thinking of stuff like physical key-loggers, hidden cameras etc etc

edit: fixed and shortened quote

I did the whole TPM thing previously on a Debian-only machine and it worked great until it stopped for some reason and I haven't had time to revisit. But on my latest machine I wanted to make sure Windows with SecureBoot worked and I was in a rush. So it's encrypted /boot for now.

I figure the threat is now that someone could clone the drive and brute force the passphrase and then tamper with /boot.

You can sign initrd and check it using (signed) grub. But yes you need local key enrollment. Maybe making this easier is the solution though? Instead of relying on Microsoft to be charitable with its keys.

>No rollback protection (no way to cryptographically invalidate access to TPM-bound secrets on OS updates)

Revoke the key used to sign either grub, the kernel or the initrd?

>Unified Kernel Image

UKI are systemd-specific and mostly a joke AFAICT. Linux supports embedding an initrd into its efi bin. Why make a new thing?

The main object of this whole article is to make PCRs contain hashes of the current system state. Its only advantage is that it can be used to restrict some TPM access. To do that, it tries to introduce a new way to do things which adds nothing to the average user. This is mainly useful for distributions that want to have complete control on the boot process (most Linux distributions do not). A distribution can already do most (everything?) of what is suggested using rotating keys/key revocation locally, but this would introduce the possibility of forced attestation of local state. It's a plus for big organizations, but I fail to see how this improves the state of Linux for the user. At best it's an alternative to using local signing (which is already possible), at worst it's an entry into attestation of local state (DRM).

That said, I’m in the camp of: this is good, and a lot of the comments here are FUD (aka Poettering probably hasn’t read Brave New World, or at least this isn’t that).

The world is already full of proprietary systems, including the one produced by the employer of systemd. WSL has improved a lot in the past years, he should be focusing on that, or at least use that as a testing ground.

Not confining new technology like systemd has lead to an infinite amount of CVEs to deal with in the past years, this could have been avoided by not allowing a tech prototype to bypass community adoption and impose itself as a ego-driven standard.

But no, this doesn't solve anything, because the root problem doesn't have anything to do with technology. The root problem is that people need to work together despite having conflicting goals and interests.

Like, e.g., the major issue with trusted computing isn't trusted computing. Everyone would like their devices to be secure against unwanted software doing bad things. The conflict is over who owns the device in the first place. I'd like to own my PC, the very one I'm writing this comment on. So does Intel, Dell, Realtek, Microsoft, my bank, every news site, half a dozen governments, and countless criminals specialized in exploiting digital technology. Whether or not TC is good for me hinges entirely on the answer to the ownership question.

As for complexity - it comes from the industry incrementally evolving technological solutions to what's a philosophical/sociological problem that doesn't have a theoretical solution yet (and might be unsolvable in general).

I'm starting to like Apple's approach more. It allows to have multiple OSes installed and each to have different level of trust. In UEFI, the equivalent would be that you could have Secure-core like security for one installed instance, 3rd party UEFI-enabled Secure Boot for another and no Secure Boot for yet another installed OS. Unfortunately, in UEFI it is all-or-nothing instead.

UDev & Gnome https://news.ycombinator.com/item?id=8416912 (8 years ago)

udev, https://news.ycombinator.com/item?id=6066848 (9 years ago, same behavior reported)

https://news.ycombinator.com/item?id=7211451

https://news.ycombinator.com/item?id=8203507 (8 years ago, community reports the same treatment)

I applaud Pottering's systemd projects as a masterful career move at the same time that I shake my fist at them, and how they build a path to undermine free computing.

They recentralize, and fragilize, the free software ecosystem.

They build features that are not requested, with the premise of small, incremental benefits while taking away choice by making the pre-existing standard of interoperable decoupled components difficult-to-impossible to continue to use.

This development pattern enforces deeper integration with their one blessed way, and tramples on the culture of the free software ecosystem, which the project efforts take part in, in all but ultimate aim. They do things that should not be done, although he's effective in creating and pursuing opportunities that advance the interests of Red Hat and now Microsoft.

I like that free software has let me build and explore things without getting sign-off and approval from authority, while the existence and strength of free software means I get to enjoy some of its benefits even while using devices made by companies that do not pay-forward their free/open software founding roots, specifically that developer system configuration escape hatches are needed on macOS, and Windows, for competitive reasons.

The ease of use, breadth of adoption, and creeping (and unnecessarily coupled) integration with widely used software are all small pennies, which "no one should object to", thrown to entice in front of the steamroller of centralized control of plausibly all software running (boot, OS, & applications) that makes founding fears of the free software community more likely to come to pass.

https://www.gnu.org/philosophy/right-to-read.html

Then again,

> users are not contributors nor customers,

and so

> "They are not _technically_ part of the "community".

https://news.ycombinator.com/item?id=7538184

When I travel, there is no way to decrypt my computers, since keys are with me. When I arrive home, I insert keys, start all computers, upgrade packages (automated), remove keys...