The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective

This TPM stuff is focused on verifying the integrity of the the boot chain. It's meant to protect against things like replacing GRUB or changing GRUB options in a malicious way. If that stuff is detected, the system won't boot.

It's goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.

If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now

What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.

But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.

And distros already control what you can and cannot do by how they choose to build the OS. Lets consider Aeon and Universal Blue.

Aeon is an OS that implements things that Poettering is discussing. Uses TPM to verify the integrity and unlock the disk if everything is fine. It also is immutable, which limits user customization in some ways as part of its philosophy. It discourage OS modifications and encourages use of Flathub and distrobox.

The Universal Blue family of distros does not implement Poettering's stuff (though there is an option to do so). But it has similar restrictions as Aeon, discourages OS modifications, encourages use of Flathub/Homebrew/Distrobox.

My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don't need to worry about the software being signed with some third party's key to boot.

Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution

I agree in some respects. I like immutable distros, flatpaks, and sandboxed/containerized stuff, but sometimes you just need to install software on the host, unsandboxed. The big thing is that immutable distros want the OS and software on top to be cleanly separated.

Some say to use Hombrew, which will take up quite a bit of space and will not always work (like SELinux permission issues) and I don't necessarily like it how puts all its dependencies on your PATH.

Notably, Systemd came up with system extensions. Seems complicated, have never gotten around to using them.

Then I look over at BSD land and their solution is stupidly simple. OS stuff goes into places like /usr/bin while user installed stuff goes into /usr/local/bin. I don't really see why immutable distros can't just have a normal package manager but have everything installed to a different place like /usr/local/bin and put that on the PATH.