Lennart Poettering, Christian Brauner founded a new company

I was hoping banks would turn to using Yubikeys/U2F for authentication/transaction signing, and not these Draconian measures.

> I suggested this as a possible solution in another HN thread a while back, but along the lines of "If a bank wants me to have a secure, locked down terminal to do business with them, then they should be the ones forking it over, not commanding control of my owned personal device."

Most banks already do that. The secure, locked down terminals are called ATMs and they are generally placed at assorted convenient locations in most cities.

Yeah, to some extent I just wanted to think about where the boundary ought to be. I somewhat suspect the bank or Netflix won’t be willing to send me a device of theirs to act as their representative in my pocket. But it is basically the only time a reasonable person should consider using such a device. Anybody paying to buy Netflix or the bank a device is basically being scammed or ripped off.

Why should I need a separate device? Doesn't a hardware security token suffice? I wouldn't even mind bringing my own but my bank doesn't accept them last I checked. (Do any of them?)

If the bank can't be bothered to either implement support for U2F or else clearly articulate why U2F isn't sufficient then they don't have a valid position. Anything else they say on the matter should be disregarded.

> with little issue

Citation needed. The fact that the infosec industry just keeps growing YoY kinda suggests that there are in fact issues that are more expensive than paying the security companies.

Also worth remembering that around 2010, the music and film industry associations of America were claiming entitlement to $50 billion dollars annually in piracy-related losses beyond what could be accounted for in direct lost revenue (which _might_ have been as much as 10 billion, or 1/6th of their claim):

https://youtu.be/GZadCj8O1-0

These guys pathologically have had a chip on their shoulder since Napster.

HN is for the kind of hacker who makes the next Uber or AirBNB. It's strongly aligned with the interests of corporate shareholders.

Unless Lennart Pottering uses remote attestation to verify who is attesting to whom.

Do you want the control systems of the subway to get modified by a malicious actor? What about damn releases? Heat pumps in apartment buildings? Robotaxis? Payroll systems? Banks?

Amutability is a huge security feature, with tons of real world applications for good.

The fact that mega corps can abuse consumers is a separate issue. We should solve that with regulation. Don't forsake all the good that this tech can do just because Asus or Google want to infringe on your software freedoms. Frankly, these mega corps are going to infringe on your rights regardlessly, whether or not Amutable exists as a business.

Don't throw the baby out with the bath water.

That's like saying we shouldn't build anything that can be used for good if it can also be used for evil.

By that logic, we should just turn off the internet. Too much potential for evil there.

More seriously, the argument being presented seems to just be "attestation tech has been used for evil in the past, therefore all attestation tech is bad," which is obviously an unsound argument. A sound argument would have to show that attestation tech is _inherently_ bad, and I've already provided examples that I think effectively counter that. I can provide more if needed.

I get that we want to prevent attestation tech from being used for evil, but that's a regulatory problem, not a technical one. You make this point by framing the evil parties as "corporate and government interests."

Don't get me wrong, I am fully against anything that limits the freedoms of the person that owns the device. I just don't see how any of this is a valid argument that Amutable's mission is bad/immoral/invalid.

Or maybe another argument that's perhaps more aligned with the FOSS ideology: if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?

Apple uses Blind Signatures for attestation. It's how they avoid captchas at CloudFlare and Fastly in their Private Relay product

https://educatedguesswork.org/posts/private-access-tokens/

I don't think that a 100% anonymous attestation protocol is what most people need and want.

It would be sufficient to be able to freely choose who you trust as proxy for your attestations *and* the ability to modify that choice at any point later (i.e. there should be some interoperability). That can be your Google/Apple/Samsung ecosystem, your local government, a company operating in whatever jurisdiction you are comfortable with, etc.

Well, if a rootkit gets installed later, attention might be handy? Or am I missing something?

Which is why I personally filed off the VIN from my car's engine.

The scandal you cited was that guns controlled by the federal government don't have any obvious reasonable path to being owned by criminals; there isn't an obvious reason for the guns to have left the possession of the government in the first place.

There's not really an equivalent here for a computer owned by an individual because it's totally normal for someone to sell or dispose of a computer, and no one expects someone to be responsible for who else might get their hands on it at that point. If you prove a criminal owns a computer that I owned before, then what? Prosecution for failing to protect my computer from thieves, or for reselling it, or gifting it to a neighbor or family friend? Shifting the trust doesn't matter if what gets exposed isn't actually damaging on any way, and that's what the parent comment is asking about.

The first two examples you give seem to be about an unscrupulous government punishing someone for owning a computer that they consider tainted, but it honestly doesn't seem that believable that a government who would do that would require a burden of proof so high as to require cryptographic attestation to decide on something like that. I don't have a rebuttal for "an organization trying to avoid cross-tenant linkage" though because I'm not sure I even understand what it means: an example would probably be helpful.

I'm confused. People talking about remote attestation which I thought was used for stuff like SGX. A system in an otherwise untrusted state loads a blob of software into an enclave and attests to that fact.

Whereas the state of the system as a whole immediately after it boots can be attested with secure boot and a TPM sealed secret. No manufacturer keys involved (at least AFAIK).

I'm not actually clear which this is. Are they doing something special for runtime integrity? How are you even supposed to confirm that a system hasn't been compromised? I thought the only realistic way to have any confidence was to reboot it.

Did AI write this comment?

The value is being able to easily and robustly verify that my device hasn't been compromised. Binding disk encryption keys to the TPM such that I don't need to enter a password but an adversary still can't get at the contents without a zero day.

Of course you can already do the above with secure boot coupled with a CPU that implements an fTPM. So I can't speak to the value of this project specifically, only build and boot integrity in general. For example I have no idea what they mean by the bullet "runtime integrity".

https://attestation.app/about For mobiles, it helps make tampering obvious.

https://doc.qubes-os.org/en/latest/user/security-in-qubes/an... For laptops, it helps make tampering obvious. (a different attestation scheme with smaller scope however)

This might not be useful to you personally, however.

I am aware of that, my (personal) view is that DRM is a social issue caused by modes of behaviour and the existence or non-existence of technical measures cannot fix or avoid that problem.

A lot of the concerns in this thread center on TPMs, but TPMs are really more akin to very limited HSMs that are actually under the user's control (I gave a longer explanation in a sibling comment but TPMs fundamentally trust the data given to them when doing PCR extensions -- the way that consumer hardware is fundamentally built and the way TPMs are deployed is not useful for physical "attacks" by the device owner).

Yes, you can imagine DRM schemes that make use of them but you can also imagine equally bad DRM schemes that do not use them. DRM schemes have been deployed for decades (including "lovely" examples like the Sony rootkit from the 2000s[1], and all of the stuff going on even today with South Korean banks[2]). I think using TPMs (and other security measures) for something useful to users is a good thing -- the same goes for cryptography (which is also used for DRM but I posit most people wouldn't argue that we should eschew all cryptography because of the existence of DRM).

[1]: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... [2]: https://palant.info/2023/01/02/south-koreas-online-security-...

This whole discussion is a perfect example of what Upton Sinclair said, "It is difficult to get a man to understand something, when his salary depends on his not understanding it."

A rational and intelligent engineer cannot possibly believe that he'll be able to control what a technology is used for after he creates it, unless his salary depends on him not understanding it.

You could tell this sort of insinuation to anyone. Including you.

Argument should be technical.

I'm really not trying to be slick, but I think it's quite difficult to convince people about anything concrete (such as precisely how this model is fundamentally different to models such as the Secure Boot PKI scheme and thus will not provide a mechanism to allow a non-owner of a device to restrict what runs on your machine) without providing a concrete implementation and design documents to back up what I'm saying. People are rightfully skeptical about this stuff, so any kind of explanation needs to be very thorough.

As an aside, it is a bit amusing to me that an initial announcement about a new company working on Linux systems caused the vast majority of people to discuss the impact on personal computers (and games!) rather than servers. I guess we finally have arrived at the fabled "Year of the Linux Desktop" in 2026, though this isn't quite how I expected to find out.

> Attestation of what to whom for which purpose? Which freedom does it allow users to control their keys, how does it square with remote attestation and the wishes of enterprise users?

We do have answers for these questions, and a lot of the necessary components exist already (lots of FOSS people have been working on problems in this space for a while). The problem is that there is still the missing ~20% (not an actual estimate) we are building now, and the whole story doesn't make sense without it. I don't like it when people announce vapourware, so I'm really just trying to not contribute to that problem by describing a system that is not yet fully built, though I do understand that it comes off as being evasive. It will be much easier to discuss all of this once we start releasing things, and I think that very theoretical technical discussions can often be quite unproductive.

In general, I will say that there a lot of unfortunate misunderstandings about TPMs that lead people to assume their only use is as a mechanism for restricting users. This is really not the case, TPMs by themselves are actually more akin to very limited HSMs with a handful of features that can (cooperatively with firmware and operating systems) be used to attest to some aspects of the system state. They are also fundamentally under the users' control, completely unlike the PKI scheme used by Secure Boot and similar systems. In fact, TPMs are really not a useful mechanism for protecting against someone with physical access to the machine -- they have to trust that the hashes they are given to extend into PCRs are legitimate and on most systems the data is even provided over an insecure data line. This is why the security of locked down systems like Xbox One[1] don't really depend on them directly and don't use them at all in the way that they are used on consumer hardware. They are only really useful at protecting against third-party software-based attacks, which is something users actually want!

All of the comments about DRM obviously come from very legitimate concerns about user freedoms, but my views on this are a little too long to fit in a HN comment -- in short, I think that technological measures cannot fix a social problem and the history of DRM schemes shows that the absence of technological measures cannot prevent a social problem from forming either. It's also not as if TPMs haven't been around for decades at this point.

[1]: https://www.youtube.com/watch?v=U7VwtOrwceo

> but the way this will be used is by corporations to lock us out into approved Linux distributions. Linux will be effectively owned by RedHat and Microsoft, the signing authority.

This is the intent of the Poettering and Brauner.

> but the way this will be used is by corporations to lock us out into approved Linux distributions. Linux will be effectively owned by RedHat and Microsoft, the signing authority.

This is basically true today with Secure Boot on modern hardware (at least in the default configuration -- Microsoft's soft-power policies for device manufacturers actually requires that you can change this on modern machines). This is bad, but it is bad because platform vendors decide which default keys are trusted for secure boot by default and there is no clean automated mechanism to enroll your own keys programmatically (at least, without depending on the Microsoft key -- shim does let you do this programmatically with the MOK).

The set of default keys ended up being only Microsoft (some argue this is because of direct pressure from Microsoft, but this would've happened for almost all hardware regardless and is a far more complicated story), but in order to permit people to run other operating systems on modern machines Microsoft signed up to being a CA for every EFI binary in the universe. Red Hat then controls which distro keys are trusted by the shim binary Microsoft signs[1].

This system ended up centralised because the platform vendor (not the device owner) fundamentally controls the default trusted key set and is what caused the whole nightmare of the Microsoft Secure Boot keys and rh-boot signing of shim. Getting into the business of being a CA for every binary in the world is a very bad idea, even if you are purely selfish and don't care about user freedoms (and it even makes Secure Boot less useful of a protection mechanism because it means that machines where users only want to trust Microsoft also necessarily trust Linux and every other EFI binary they sign -- there is no user-controlled segmentation of trust, which is the classic CA/PKI problem). I don't personally know how the Secure Boot / UEFI people at Microsoft feel about this, but I wouldn't be surprised if they also dislike the situation we are all in today.

Basically none of these issues actually apply to TPMs, which are more akin to limited HSMs where the keys and policies are all fundamentally user-controlled in a programmatic way. It also doesn't apply to what we are building either, but we need to finish building it before I can prove that to you.

[1]: https://github.com/rhboot/shim-review

Do you have a way to tell the software to trust your kernel? If so, yes. Things like the web show how we can achieve distributed trust.

TLDR We already know how this will be misused to take away people's freedom not to run their own software stack but to dissent against fascism. It's immoral to build even with the best intentions.

Unfortunately the parent commenter is completely right.

The attestation portion of those systems is happening on locked down devices, and if you gain ownership of the devices they no longer attest themselves.

This is the curse of the duopoly of iOS and Android.

BankID in Sweden will only run with one of these devices, they used to offer a card system but getting one seems to be impossible these days. So you're really stuck with a mobile device as your primary means of identification for banking and such.

There's a reason that general purpose computers are locked to 720p on Netflix and Disney+; yet AppleTV's are not.

Torrenting is becoming more popular again. The alternative to being allowed to pay to watch on an "insecure" device isn't switching to an attested device, it's to stop paying for the content at all. Games industry, same thing (or just play the good older games, the new ones suck anyway).

Finances, just pay everything by cheque or physical pennies. Fight back. Starve the tyrants to death where you can, force the tyrants to incur additional costs and inefficiencies where you can't.

This is already the world we live in when it comes to the most popular personal computing devices running Linux out there.

Is the joke here that all of those things have already been happening for a while now?

Dunno about the others but Pottering has proven himself to deliver software against the grain.

[flagged]

It was also heavily pushed by Red Hat by making everyone's lives harder if they didn't support it.

Linux has been majority developed by large tech companies for the last 20+ years. If not for them, it would not be anywhere close to where it is today. You may not like this fact, but it's not really a new development nor something that can be described as infiltration. At the end of the day, maintaining software without being paid to do so is not generally sustainable.

> This is why I moved to the BSDs. Linux started as a grassroots project but turned commercial

Thanks, this may be the key takeaway from this discussion for me

As a complete guess, I would say that 90% of Linux systems are run by "big tech drones". And also by small companies using technology.

Open source operating systems are not a zero sum game. Yes there is a certain gravitational pull from all the work contributed by the big companies. If you aren't contributing "for-hire", then you choose what you want to work on, and what you want to use.

General purpose operating systems are fine and in some cases, preferable. However, they should be small, simple and designed with first class portability. Linux is none of those.

Why shouldn't they use the kernel, systemd, and a few core utilities? Why reinvent the wheel? There's nothing requiring them to pull in a typical desktop userspace.

I agree but it's difficult to argue against it. There is just so much you get for free by starting with a Linux distro as your base. Developing against alternatives is very expensive and developing something new is even more expensive. The best we can hope for is that someone with deep pockets invests in good alternatives that everyone can benefit from.

How are you defining "general-purpose OS"? Are you saying IoT and robotics shouldn't use a Linux kernel at all? Or just not your general purpose distros? I would be interested to hear more of your logic here, since it seems like using the same FOSS operating system across various uses provides a lot of value to everyone.

I don't think this is generally true. If you are running Linux in your stack, your device probably is investing in 1GiB+ RAM and 2GiB+ of flash storage. systemd et al are not a problem at that point. Running a UI will end up being considerably more costly.

I work on embedded devices, fairly powerful ones to be fair, and I think systemd is really great, useful software. There's a ton of stuff I can do quite easily with systemd that would take a ton of effort to do reliably with sysvinit.

It's definitely pretty opinionated, and I frequently have to explain to people why "After=" doesn't mean "Wants=", but the result is way more robust than any alternative I'm familiar with.

If you're on a system so constrained that running systemd is a burden, you are probably already using something like buildroot/yocto and have a high degree of control about what init system you use.

I’m skeptical about the push toward third-party hardware attestation for Linux kernels. Handing kernel trust to external companies feels like repeating mistakes we’ve already seen with iOS and Android, where security mechanisms slowly turned into control mechanisms.

Centralized trust Hardware attestation run by third parties creates a single point of trust (and failure). If one vendor controls what’s “trusted,” Linux loses one of its core properties: decentralization. This is a fundamental shift in the threat model.

Misaligned incentives These companies don’t just care about security. They have financial, legal, and political incentives. Over time, that usually means monetization, compliance pressure, and policy enforcement creeping into what started as a “security feature.”

Black boxes Most attestation systems are opaque. Users can’t easily audit what’s being measured, what data is emitted, or how decisions are made. This runs counter to the open, inspectable nature of Linux security today.

Expanded attack surface Adding external hardware, firmware, and vendor services increases complexity and creates new supply-chain and implementation risks. If the attestation authority is compromised, the blast radius is massive.

Loss of user control Once attestation becomes required (or “strongly encouraged”), users lose the ability to fully control their own systems. Custom kernels, experimental builds, or unconventional setups risk being treated as “untrusted” by default.

Vendor lock-in Proprietary attestation stacks make switching vendors difficult. If a company disappears, changes terms, or decides your setup is unsupported, you’re stuck. Fragmentation across vendors also becomes likely.

Privacy and tracking Remote attestation often involves sending unique or semi-unique device signals to external services. Even if not intended for tracking, the capability is there—and history shows it eventually gets used.

Potential for abuse Attestation enables blacklisting. Whether for business, legal, or political reasons, third parties gain the power to decide what software or hardware is acceptable. That’s a dangerous lever to hand over.

Harder incident response If something goes wrong inside a proprietary attestation system, users and distro maintainers may have little visibility or ability to respond independently.

I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this.

Chaining trust from POST to login feels like trying to make a theoretically perfect diamond and titanium bicycle that never wears down or falls apart when all I need is an automated system to tell me when to replace a part that’s about to fail.

> the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech

Reminds me of my old Chromebook Pixel I wiped chromeos from. Every time it booted I had to press Ctrl-L (iirc) to continue the boot, any other keypress would reenable secure boot and the only way I knew to recover from that was to reinstall chromeos, which would wipe my linux partition and my files with it. Needless to say, that computer taught me good backup discipline...

Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.

Just because OpenSSL had a CVE posted about today, that didn't mean we should go back to use HTTP for the web.

Yes, you can. I really don't want to be in the business of building OSes. If these guys make it so that getting reasonable boot security is a simple toggle, I'd be grateful.

> the kernel will verify anything beneath it

Yes that's the case - my argument is that Linux currently doesn't have anything standardized to do that.

Your best bet for now is to use a read-only dm-verity-protected volume as the root partition, encode its hash in the initrd, combine kernel + initrd into a UKI and sign that.

I would welcome a standardized approach.

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/

> 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.

Have a look at Ubuntu Core 24 and later. Though it's not exactly a desktop system, but rathe oriented towards embedded/appliances. Recent Ubuntu desktop (from 25.04 IIRC) started getting the same mechanism gradually integrated in each release. Upcoming Ubuntu 26.04 is expected to support TPM backed FDE. Worth a try if you can set up a VM with a software TPM.

Keep in mind though, there's been plenty of issues with various EFI firmwares, especially on the appliances side. EFI specs are apparently treated as guidelines rather than actual specification by whoever ends up implementing the firmware.

Fine as long as it's managed by the user. A good check is who installed the keys. A user–freedom–respecting secureboot must have user–generated keys.

> you cannot use unsigned drivers because the kernel can detect and activate the lockdown mode

You don't need to load a driver; you can just replace a binary that's going to be executed as root as part of system boot. This is something a hypothetical code signature verification would detect and prevent.

Failing kernel-level code signature enforcement, the next best step is to have a dm-verity volume as your root partition, with the dm-verity hashes in the initrd within the UKI, and that UKI being signed with secure boot.

This would theoretically allow you to recover from even root-level compromise by just rebooting the machine (assuming the secure boot signing keys weren't on said machine itself).

This happens much less frequently than the manufacturer of "my" computing device verifies that I haven't tampered with it. On net, it's a wholesale destruction of user freedom.

The better question then is why the actual f** can an OTA firmware update touch anything in the steering or powertrain of the car, or why do I even need a computer that's connected to anything, and one which does more than just make sure I get the right amount of fuel and spark, or why on earth do people tolerate this sort of insanity.

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.

Banks do this because they have made their own requirement that the mobile device is a trust root that can authenticate the user. There are better, limited-purpose devices that can do this, but they are not popular/ubiquitous like smartphones, so here we are.

The oppressive part of this scheme is that Google's integrity check only passes for _their_ keys, which form a chain of trust through the TEE/TPM, through the bootloader and finally through the system image. Crucially, the only part banks should care about should just be the TEE and some secure storage, but Google provides an easy attestation scheme only for the entire hardware/software environment and not just the secure hardware bit that already lives in your phone and can't be phished.

It would be freaking cool if someone could turn your TPM into a Yubikey and have it be useful for you and your bank without having to verify the entire system firmware, bootloader and operating system.

Then work with the bank to prove the signer is trustworthy.

“buggy”

Phones don't implement UEFI.

This perspective is astonishingly historically ignorant, and ignores how "Open Source Software" was a deliberate political movement to simultaneously neuter the non-company-friendly goals of FOSS while simultaneously providing a competing (and politically distracting) movement that deliberately courted companies.

The Free Software movement was successful enough that by 1997 it was garnering a lot of international community support and manpower. Eric S. Raymond published CatB in response to these successes, partly with a goal of "celebrating its successes" — sendmail, gcc, perl, and Linux were all popular projects with a huge number of collaborators by this point — and partly with a goal of reframing the Free Software movement such that it effectively neuters the political basis (i.e. the four freedoms, etc.) in a company-friendly way. It's very easy to note when reading the book, how it consistently celebrates the successes of Free Software in a company friendly way, deliberately to make it appealing to companies. Often being very explicit about its goals, e.g. "Don't give your workers good bonuses, because research shows that the better a ''hacker'' the less they care about money!".

A year later, internal memos from Microsoft leaked that showed that management were indeed scared shitless about Linux, a movement that they could neither completely Embrace, Extend, and Extinguish, nor practice Fear, Uncertainty, and Doubt on, because the community that built it were too strong, and too dedicated. Management foresaw that it was only a matter until Linux was a very strong competitor — even if that's taken 20 years, they were decently accurate in their fears, and, to be honest, part of why it's taken 30 years for Linux to catch up are deliberate actions by Microsoft wrt. introducing and adopting technologies that would stymie the Free Software movement from being able to adapt.

> Nobody says that you will not have alternatives

Maybe you want to reread through this thread.

> Eventually you will not be able to block ads.

That's so far down the slippery slope and with so many other things that need to go wrong that I'm not worried and I'm willing to be the one to get "told you so" if it happens.

Why not? Being terse does not make one right...

I don't think Mr Pottering was brought by accident, maybe his decade of contribution making sure systemd services can be manipulated by a supervisor (in the case of wsl and ms) is a valuable asset. Systemd don't even need to change much to become the devil itself, it just have to upstream merge changes already consolidated in the past 5 years or so... But logically it's safe because for this to become a problem systemd would have to be adopted by the majority of distributions and its maintainers would have to concede to the pressure of big corps and such...oh, wait

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

Do you really think Laptop makers would buy a whole company to figure out how to remove that option?

https://0pointer.net/blog/authenticated-boot-and-disk-encryp...

Yes, system data should be locked to the system with a TPM. That way your system can refuse to boot if it's been modified to steal your user secrets.

I mentioned it somewhere else in the thread, and btw, I'm not affiliated with the company, this is just my charitable interpretation of their intentions: this is not for requiring _every_ consumer linux device to have attestation, but for specific devices that are needed for niche purposes to have a method to use an open OS stack while being capable of attestation.

I agree with you - but considering what they want to implement and what it can be used for there are probably investors that might not want to be outed (this early). Kinda paranoid I admit, but history has shown that stuff like this WILL be misused.

"In every way"

About ten years ago I took a three day cross-country Amtrak trip where I wanted to work on some data analysis that used mysql for its backend. It was a great venue for that sort of work because the lack of train-internet was wonderful to keep me focused. The data I was working with was about 20GB of parking ticket data. The data took a while to process over SQL which gave me the chance to check out the world unfolding outside of the train.

At some point, mysql (well, mariadb) got into a weird state after an unclean shutdown that put itself into recovery mode where upon startup it had to do some disk-intensive cleanup. Thing is -- systemd has a default setting (that's not readily documented, nor sufficiently described in its logs when the behavior happens) that halts the service startup after 30 seconds to try again. On loop.

My troubleshooting attempts were unsuccessful. And since I deleted the original csv files to save disk space, I wasn't able to even poke at the CSV files through python or whatnot.

So instead of doing the analysis I wanted to do on the train, I had to wait until I got to the end of the line to fix it. Sure enough, it was some default 30s timeout that's not explicitly mentioned nor commented out like many services do.

So, saying that things are "much better in every way" really falls on deaf ears and is reminiscent of the systemd devs' dismissive/arrogant behavior that many folk are frustrated about.

> systemd is so much better in every way,

How can I cancel a systemd startup task that blocks the login prompt? / how is forcing me to wait for dhcp on a network interface that isn't even plugged in a better experience?

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.

The problem is not systemd vs SysV et al, the problem is systemd spreading like a cancer throughout the entire operating system.

Also trying to use systemd with podman is frustrating as hell. You just cannot run a system service using podman as a non-root user and have it work correctly.

Here are a few examples of problems systemd has caused me:

System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.

Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.

At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.

There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point:

Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am.

I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.

I'd be interested in what other init alternatives offer the security options systemd does

> in every way

You realize that quite a few senior and experienced developers and devops engineers do not share this view, right?

This is basically propaganda for the war on general purpose computing. My user data is less safe on a Windows device, because Microsoft has full access to that device and they are extremely untrustworthy. On my Linux device, I choose the software to install.

> Microsoft

the guys that copy your bitlocker keys in the clear

Considering that (for example) your data on ChromeOS is automatically copied to a server run by Google, who are legally compelled to provide a copy to the government when subject to a FISA order, it is unclear what Poettering's threat model is here. Handwringing about secure boot is ludicrous when somebody already has a remote backdoor, which all of the cited operating systems do. Frankly, the assertion of such a naked counterfactual says a lot more about Poettering than it does about Linux security.

Werner Von Braun only built the rockets; he didn't aim them, nor did he care where they landed.

(London. On some of my relatives.)

Road to hell is paved with good intentions.

Somebody will use it and eventually force it if it exists and I don't think gaming especially those requiring anti-cheat is worth that risk.

If that means linux will not be able to overtake window's market share, that's ok. At-least the year of the linux memes will still be funny.

Only by creating a new stalemate between essential liberty and a little temporary security — anticheat doesn't protect you from DMA cheating.

> resolve the Linux gaming vs. anti-cheat stalemate

It will.

Then just a bit later no movies for you unless you are running a blessed distro. Then Chrome will start reporting to websites that you are this weird guy with a dangerous unlocked distro, so no banking for you. Maybe no government services as well because obviously you are a hacker. Why would you run an unlocked linux if you were not?

I would rather have it unresolved forever.

I sincerely hope not.

We all know who controls the keys. It's the first party who puts their hands on the device.

Just to make it clear - on Android you don't have the keys. Even with avb_custom_key you can't modify many partitions.

> who controls the keys

Not you. This technology is not being built for you.

"cryptographically verifiable integrity" is a euphemism for tivoization/Treacherous Computing. See, e.g., https://www.gnu.org/philosophy/can-you-trust.en.html

As the immediate responder to this comment, I claim to be the next guy. I love systemd.

Remote attestation is literally a form of DRM

Secure boot and attestation both generally require a form of DRM. It’s a boon for security, but also for control.

I don't mind SystemD.

Hacker News has recently been dominated by conspiracy theorists who believe that all applications of cryptography are evil attempts by shadowy corporate overlords to dominate their use of computing.

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 think distributions like Fedora or Debian will ever go in that direction.

We don't really have any control over what Microsoft decides to do with Secure Boot. If they decide at one point to make Secure Boot reject any Linux distribution and hardware vendors prevent enrolling user owned keys, we're in just as much trouble as everyone else running Linux will be.

I doubt that will actually happen in practice though.

Hopefully cartel regulation would prevent Microsoft from using their market leader position to force partners to remove all support for competitors.

But I'm losing hope with those.

> 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 the 3rd party CA (used e.g. go sign shim for Linux) is disabled by default, but again, they mandated there must be an easy toggle to enable it. I don't begrudge them to much for it, because there have been multiple instances of SB bypass via 3rd party signed binaries.

All of this is to say: this is not a scenario I'm worried about today. Of course this may change down the line.

> 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?

Nothing, but openbsd is amazing and just works. Anyone still using Linux on the desktop in 2026 should switch.

Systemd upstream has reviewers and maintainers from a bunch of different companies, and some independent: Red Hat, Meta, Microsoft, etc. This isn't changing, we'll continue to work through consensus of maintainers regardless of which company we work at.

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.

It prevents malware that obtained root access once from forever replacing your kernel/initrd and achieving persistence that way.

So both consent to sex and now one thinks they're entitled to marriage. That's where this inevitably leads, user/customer lock-in and control.

While the bank use case makes a compelling argument, device attestation won't be used for just banks. It's going to be every god damned thing on the internet. Why? Because why the hell not, it further pushes the costs of doing business of banks/MSPs/email providers/cloud services onto the customer and assigns more of the liabilities.

It will also further the digital divide as there will be zero support for devices that fail attestation at any service requiring it. I used to think that the friction against this technology was overblown, but over the last eighteen months I've come to the conclusion that it is going to be a horrible privacy sucking nightmare wrapped in the gold foil of security.

I've been involved in tech a long, long time. The first thing I'm going to do when I retire is start chucking devices. I'm checking-out, none of this is proving to be worth the financial and privacy costs.

A fundamentally flawed way to make an argument?

Yeah I know what analogies are.

Why does my bank need to know whether the machine in my hands that is accessing their internet APIs was attested by some uninvolved third party or not?

You know we used to hand people pieces of paper with letters and numbers on them to do payments right? For some reason, calling up my bank on the phone never required complicated security arrangements.

TD Bank never needed to come inspect my phone lines to ensure nobody was listening in.

Instead of securing their systems and working on making it harder to have your accounts taken over (which by the way is a fruitful avenue of computer security with plenty of low hanging fruit) and punishing me for their failures, they want to be able to coerce me to only run certain software on my equipment to receive banking services.

This wasn't necessary for banking for literally thousands of years.

Why now? What justification is there?

A third party attesting my device can only be used to compel me to only use certain devices from certain third parties. The bank is not at all going to care whether I attest to it or not, they are going to care that Google or Microsoft will attest my device.

And for what? To what end? To prevent what alleged harm?

In what specific way does an attested device state make interacting with a publicly facing interface more secure?

It WILL be used to prevent you from being able to run certain code that benefits you at corporation's expense, like ad blockers.

Linux is supposed to be an open community. Who even asked for this?

Trusted computing boil down to restricting what software I'm allowed to run on hardware I own and use. The technical means to do so are irrelevant.

Can it sets terms on my religious and political views? I'm not speaking about race and sex, you cannot choose them (ok, sex you could in some jurisdictions, and there is difference between sex and gender, please, don't be nitpicky here), but about things I can choose same as I can choose my hardware and software to run.

If there is real effective market (which is not in any country on Earth, especially for banks), you could say: vote with you money, choose bank which suits you. But it is impossible even with bakery, less with banks on market which is strictly regulated (in part as result of lobbying by established institutions, to protect themselves!).

So, on one hand, I must use banks (I cannot pay for many things in cash, here, where I live most of bars and many shops doesn't accept cash, for example, and it is result of government politics and regulations), and on other hand banks is not seen as essential as access to air and water, they could dictate any terms they want.

I see this situation completely screwed.

This appears to be the only comment worth reading. Thanks.

> Favorite color?

As per the announcement, we’ll be building a favorite color over the next months and sharing more information as it rolls out.

lol

Microsoft has a "minimum set of requirements" document about "Designed for Windows" PCs. You can't sell a machine with Windows or tell it's Windows compatible without complying with that checklist.

So, every PC sold to consumers is sanctioned by Microsoft. This list contains Secure Boot and TPM based requirements, too.

If Microsoft decides to eliminate enrollment of user keys and Secure Boot toggle, they can revoke current signing keys for "shims" and force Linux distributions to go full immutable to "sign" their bootloaders so they can boot. As said above, it's not something Amutable can control, but enable by proxy and by accident.

Look, I work in a datacenter, with a sizeable fleet. Being able to verify that fleet is desirable for some kinds of operations, I understand that. On the other hand, like every double edged sword, this can cut in both ways.

I just want to highlight that, that's all.

Have you run an Android device recently?

> client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.

It will be, no doubt. As soon as it is successfully tested and deployed for games, it will be used for movies, government services, banks, etc. And before you know you do not have control of your own computer.

> Who owns the garden?

Not you.

> everyone installs overlays over the top of that

Except this breaks cryptography and your computer is denied multiple services. Because you are obviously a hacker, why else would anyone want to compile and run programs.

> turning the integrity protection off (and no means to do so on PC hardware)

It's a flip of a switch, really. Once Microsoft decides you have had enough, the switch is flipped and in a couple of years no new Intel computer will boot your kernel.

"Ubuntu Core" is a similar product [1]

As I understand it, the main customers for this sort of thing are companies making Tivo-style products - where they want to use Linux in their product, but they want to lock it down so it can't be modified by the device owner.

This can be pretty profitable; once your customers have rolled out a fleet of hardware locked down to only run kernels you've signed.

[1] https://ubuntu.com/core

This is not about the person being attacked, it's about what this kind of thing does to us as a community. It's not what the site is for, and destroys what it is for.

[flagged]