6 ms·

The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. I thin

The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. I think Systemd has a view that those things should reliably work together. I do not fancy a revival of the past where the user has to cobble a mesh of hopefully compatible libraries to achieve the same, taking weeks to study the Arch manual and resolving tons of gotcha's, all to be broken by next week's update. The integration of all this stuff is now actively under test and maintenance with systemd. And yes, the mentioned services also have an impact on the scope of service managing. Because if you have a unit that depends on a disk that needs to be unencrypted, this has to be resolved somehow in the right time. I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large. So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?

udev4096 2y ago
systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html https://0pointer.de/blog/brave-new-trusted-boot-world.html
- donnachangstein 2y ago
  Most 'systemd haters' see boot security as unnecessary, or a toy no one would use, and that UEFI secure boot is a conspiracy orchestrated by Microsoft. It fits the personality profile of not wanting to learn new things. After all, we didn't need it in 2002, so why do we need it now? There is no fixing these people, so it doesn't make sense expending energy convincing them.
  - M95D 2y ago
    That's almost entirely correct, with one exception: > It fits the personality profile of not wanting to learn new things. 'systemd haters' learn a lot. They learn how to write manual boot scripts, set up mdev instead of udev, compile their own kernel, install their own u-boot or coreboot, strip binary blobs, etc. etc. They know MORE than the average systemd guy. They just don't want to learn systemd. Isn't the whole purpose of systemd to ease and automate administration and configuration, so the user need not care? Doesn't that imply that systemd admins/users know LESS? ---- Now let me make my own characterization of 'systemd enthusiasts'. These people are overworked sysadmins that hate manual configuration. They want it easy, everything automated, they want to not care about it, they want the distro to auto-do everything and not even ask, they want less admin work. Systemd does all these things for them and they are in heaven. They're so enthusiastic that they feel we should all be one big happy family under the systemd umbrella. But they fail too see that no company or manager will tolerate people that are _not_ overworked. When something becomes automated, people previously doing the manual job are fired. A 10 people non-systemd team that works day-and-night to set manually up boot, mounts, network, services, cron, backups, logs, etc., as soon as systemd automates the work, will be cut down to just one guy (or less) and he will still work day-and-night, same as before, doing the work of the entire team. And he won't be able to take break because there's nobody left to replace him. They also fail to see that resilience comes from diversity. Uniformity, systems where software is identical, updates are identical, configuration is identical, permissions are identical, etc., will also fail identically and probably at the same time, and will be hacked identically and at the same time (by automated bots/tools).
    - cf100clunk 2y ago
      An enjoyable perspective on how workload can affect techno-tribalism. Like many who have worked in, or run, mixed shops over the years, I've lamented the interpersonal friction that can happen amongst camps. It can be corrosive, almost to the point of destruction, at which point I've had to fire people for using terms like ''hater'' or worse. Good riddance, because we had work to do.
- immibis 2y ago
  The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo. I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.
  - udev4096 2y ago
    sbctl [0] makes secure boot a lot easier. you just enable setup mode from BIOS and it will take care of enrolling and managing the keys. Are you immibis from libera.chat by any chance? [0] - https://github.com/Foxboron/sbctl https://github.com/Foxboron/sbctl
    - bmacho 2y ago
      There was this SixOS presentation[0] 2 months ago of a single man's own distro, among a lot of things he claims that he's created the most secure boot process ever > On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm. [0] : https://news.ycombinator.com/item?id=42884727 https://news.ycombinator.com/item?id=42884727
  - fc417fc802 2y ago
    The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation. The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though. In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.
- swe02 2y ago
  As someone who uses systemd, "boot security" is pointless. If someone has enough access to your hardware to try booting a different kernel, they have time to load a signed shim that passes secure boot and launches unsigned code. The only boot security real users need is disk encryption.
  - fc417fc802 2y ago
    There are multiple possible configurations. Only the most basic will permit an arbitrary payload as you describe. I've never been entirely clear about the security model when the signed shim is permitted. I assume I'm missing some nuance. Disk encryption alone won't protect you from either persistent malware (remote) or evil maids (local).
  - viraptor 2y ago
    "on a system not configured for boot security, you get no boot security" is indeed correct. If you care about boot security, your local platform doesn't give you the chance to boot custom kernels and not passing secure boot doesn't give you decryption keys.
  - craftkiller 2y ago
    > signed shim How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.
    - wkat4242 2y ago
      You don't but 99.99% of people do :) Especially because most Linux distros use a key signed by Microsoft by default.
      - akdev1l 2y ago
        The “people” don’t really matter. Anyone who needs a secure boot environment is having their own MOK and probably a private CA.
  - bigfatkitten 2y ago
badgersnake 2y ago
My cryptenroll is currently broken by the latest system update (I think it was a bios update). It’s better, but I’m not sure it’s good.
DrillShopper 2y ago
> The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. This has not been my experience across Debian and Arch
- mattpallissard 2y ago
  Arch user here. These things work much nicer than any of the previous alternatives. Sure, kernel signing is a bit of a mess, but that's more of a product of how key-signing at a low-level works than anything. Cryptsetup, cryptenroll, unified kernel images, and systemd-boot worked for me out of box.
  - DrillShopper 2y ago
    They very much did not for me. I beat things into shape with sbctl but it was very much an uphill battle. idk why Arch seems allergic to packaging shim-signed (it's an AUR, why would I trust such a key component to essentialy a stranger?), but here we are I guess.
    - Timber-6539 2y ago
      The AUR is just a repository of PKGBUILDs. You don't need to trust a stranger to use PKGBUILD.
    - udev4096 2y ago
      you can inspect the PKGBUILD file very easily. it's same as alpine's abuild and various other build file formats from distros. don't just blindly build it
- donnachangstein 2y ago
  That's because Debian 'stable' has a half-assed implementation of systemd, frozen in time on some ancient version. So you are stuck waiting years between upgrades. Bookworm finally supports the crypto functions. Arch OTOH was where these functions first worked out of the box.
exabrial 2y ago
somehow they missed journal though...
duskwuff 2y ago
> The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. These are also all components which would be extremely difficult to make portable - they require tight integration with the kernel and its boot process. I can't imagine how you'd implement them in a portable fashion, short of either making changes to the kernel on one or both operating systems, or implementing a complex set of shims to make them present similar interfaces. Either one of those options would be a sizable project on its own - I can't fault the developer from shying away.
- exceptione 2y ago
  Good point. But it seems that it leaves you a choice of something that is either portable or feature-rich. It all depends on the purpose of the fork. If it is there to just provide the common service layer for applications in order to make applications portable, I could see a fork being valuable.

udev4096 2y ago

systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html https://0pointer.de/blog/brave-new-trusted-boot-world.html

donnachangstein 2y ago
Most 'systemd haters' see boot security as unnecessary, or a toy no one would use, and that UEFI secure boot is a conspiracy orchestrated by Microsoft. It fits the personality profile of not wanting to learn new things. After all, we didn't need it in 2002, so why do we need it now? There is no fixing these people, so it doesn't make sense expending energy convincing them.
- M95D 2y ago
  That's almost entirely correct, with one exception: > It fits the personality profile of not wanting to learn new things. 'systemd haters' learn a lot. They learn how to write manual boot scripts, set up mdev instead of udev, compile their own kernel, install their own u-boot or coreboot, strip binary blobs, etc. etc. They know MORE than the average systemd guy. They just don't want to learn systemd. Isn't the whole purpose of systemd to ease and automate administration and configuration, so the user need not care? Doesn't that imply that systemd admins/users know LESS? ---- Now let me make my own characterization of 'systemd enthusiasts'. These people are overworked sysadmins that hate manual configuration. They want it easy, everything automated, they want to not care about it, they want the distro to auto-do everything and not even ask, they want less admin work. Systemd does all these things for them and they are in heaven. They're so enthusiastic that they feel we should all be one big happy family under the systemd umbrella. But they fail too see that no company or manager will tolerate people that are _not_ overworked. When something becomes automated, people previously doing the manual job are fired. A 10 people non-systemd team that works day-and-night to set manually up boot, mounts, network, services, cron, backups, logs, etc., as soon as systemd automates the work, will be cut down to just one guy (or less) and he will still work day-and-night, same as before, doing the work of the entire team. And he won't be able to take break because there's nobody left to replace him. They also fail to see that resilience comes from diversity. Uniformity, systems where software is identical, updates are identical, configuration is identical, permissions are identical, etc., will also fail identically and probably at the same time, and will be hacked identically and at the same time (by automated bots/tools).
  - cf100clunk 2y ago
    An enjoyable perspective on how workload can affect techno-tribalism. Like many who have worked in, or run, mixed shops over the years, I've lamented the interpersonal friction that can happen amongst camps. It can be corrosive, almost to the point of destruction, at which point I've had to fire people for using terms like ''hater'' or worse. Good riddance, because we had work to do.
immibis 2y ago
The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo. I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.
- udev4096 2y ago
  sbctl [0] makes secure boot a lot easier. you just enable setup mode from BIOS and it will take care of enrolling and managing the keys. Are you immibis from libera.chat by any chance? [0] - https://github.com/Foxboron/sbctl https://github.com/Foxboron/sbctl
  - bmacho 2y ago
    There was this SixOS presentation[0] 2 months ago of a single man's own distro, among a lot of things he claims that he's created the most secure boot process ever > On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm. [0] : https://news.ycombinator.com/item?id=42884727 https://news.ycombinator.com/item?id=42884727
- fc417fc802 2y ago
  The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation. The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though. In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.
swe02 2y ago
As someone who uses systemd, "boot security" is pointless. If someone has enough access to your hardware to try booting a different kernel, they have time to load a signed shim that passes secure boot and launches unsigned code. The only boot security real users need is disk encryption.
- fc417fc802 2y ago
  There are multiple possible configurations. Only the most basic will permit an arbitrary payload as you describe. I've never been entirely clear about the security model when the signed shim is permitted. I assume I'm missing some nuance. Disk encryption alone won't protect you from either persistent malware (remote) or evil maids (local).
- viraptor 2y ago
  "on a system not configured for boot security, you get no boot security" is indeed correct. If you care about boot security, your local platform doesn't give you the chance to boot custom kernels and not passing secure boot doesn't give you decryption keys.
- craftkiller 2y ago
  > signed shim How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.
  - wkat4242 2y ago
    You don't but 99.99% of people do :) Especially because most Linux distros use a key signed by Microsoft by default.
    - akdev1l 2y ago
      The “people” don’t really matter. Anyone who needs a secure boot environment is having their own MOK and probably a private CA.
- bigfatkitten 2y ago

badgersnake 2y ago

My cryptenroll is currently broken by the latest system update (I think it was a bios update). It’s better, but I’m not sure it’s good.

DrillShopper 2y ago

> The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. This has not been my experience across Debian and Arch

mattpallissard 2y ago
Arch user here. These things work much nicer than any of the previous alternatives. Sure, kernel signing is a bit of a mess, but that's more of a product of how key-signing at a low-level works than anything. Cryptsetup, cryptenroll, unified kernel images, and systemd-boot worked for me out of box.
- DrillShopper 2y ago
  They very much did not for me. I beat things into shape with sbctl but it was very much an uphill battle. idk why Arch seems allergic to packaging shim-signed (it's an AUR, why would I trust such a key component to essentialy a stranger?), but here we are I guess.
  - Timber-6539 2y ago
    The AUR is just a repository of PKGBUILDs. You don't need to trust a stranger to use PKGBUILD.
  - udev4096 2y ago
    you can inspect the PKGBUILD file very easily. it's same as alpine's abuild and various other build file formats from distros. don't just blindly build it
donnachangstein 2y ago
That's because Debian 'stable' has a half-assed implementation of systemd, frozen in time on some ancient version. So you are stuck waiting years between upgrades. Bookworm finally supports the crypto functions. Arch OTOH was where these functions first worked out of the box.

exabrial 2y ago

somehow they missed journal though...

duskwuff 2y ago

> The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. These are also all components which would be extremely difficult to make portable - they require tight integration with the kernel and its boot process. I can't imagine how you'd implement them in a portable fashion, short of either making changes to the kernel on one or both operating systems, or implementing a complex set of shims to make them present similar interfaces. Either one of those options would be a sizable project on its own - I can't fault the developer from shying away.

exceptione 2y ago
Good point. But it seems that it leaves you a choice of something that is either portable or feature-rich. It all depends on the purpose of the fork. If it is there to just provide the common service layer for applications in order to make applications portable, I could see a fork being valuable.