Live data from Hacker News

Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

fosstodon.org

21–30 of 62 posts

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#21
post #18

Earlier quoted context omitted.

> MSFT_PRIVATE The only evidence I can find of this... Is another comment from you. (Googled: '"MSFT_PRIVATE" partition'. One result.)

OK - try an LUbuntu Install disk for 22.04; run the installer, after Welcome,Location,Keyboard in the Partition task, create a new Partition Table; make a new disk partition, see the list of available partition types, choose ext4; see FLAGS [apple-tv-recovery,bios-grub,boot,diag,hidden,hpservice,lba,legacy-boot,lvm, msft-data , msft-reserved ,palo,prep,raid,root,swap]

Those are standard partition types that have existed for decades.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#22

Earlier quoted context omitted.

> A back door in the same library is not likely. But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.

I pointed out this weakness the other day on the internet. I got attacked by open source software armies.

Maybe it was because you weren't pointing out anything new?

There was a pull request to stop linking liblzma into libsystemd a month before the backdoor was found

https://github.com/systemd/systemd/pull/31550

This was likely one of many things that pushed the attackers to work faster, and forced them into making mistakes.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#23

libsystem is such a bizarre abstraction covering far too much surface area. The name alone is a code smell. Why is the same library used for both internal service management and for services implementing on-demand launches and notifications?

That is the systemd way, and what many of us have pointed out for years as a major risk of the approach.

I have never seen anybody point to it as a security risk before this happened. Would be happy to see a reference of somebody saying that prior to the xz event

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#24

Earlier quoted context omitted.

> A back door in the same library is not likely. But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.

I pointed out this weakness the other day on the internet. I got attacked by open source software armies.

Please don't throw despicable systemd zealots and honorable open source zealots into the same bucket ;)

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#25
post #2

As per the well known XZ-utils backdoor, we decided to take a step further and drop libsystemd dependency altogether by implementing the missing bits with few small patches (one upstream, the other to be forwarded).

Bravo. On BSD somehow OpenSSH doesn't require systemd, but on Linux it did. Magic.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#26

libsystem is such a bizarre abstraction covering far too much surface area. The name alone is a code smell. Why is the same library used for both internal service management and for services implementing on-demand launches and notifications?

I like parts of systemd very much: units and their sandboxing/isolation/chroot of processes. Many other parts are terrible beyond measure: journald for example. I think the concept of on-demand processes managed by the end manager is a good idea, but systemd is strong arming the services into accepting its philosophy.

What's wrong with journald? I do not know much about it, aside from having to use journalctl to view logs occasionally.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#27
post #2

As per the well known XZ-utils backdoor, we decided to take a step further and drop libsystemd dependency altogether by implementing the missing bits with few small patches (one upstream, the other to be forwarded).

Bravo. On BSD somehow OpenSSH doesn't require systemd, but on Linux it did. Magic.

Why would it require even systemd?

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#29
post #2

As per the well known XZ-utils backdoor, we decided to take a step further and drop libsystemd dependency altogether by implementing the missing bits with few small patches (one upstream, the other to be forwarded).

Bravo. On BSD somehow OpenSSH doesn't require systemd, but on Linux it did. Magic.

As a Debian user since the 1990s, this situation has once again made me thankful that I've moved important systems I'm responsible for away from Debian and over to OpenBSD and FreeBSD whenever possible.

Even if Debian wasn't perfect before systemd was introduced, at least I knew there was a very high probability that I could trust it to function well.

That stopped being the case after systemd was introduced. I've had far too many problems caused by systemd, to the point where all trust I had in newer versions of Debian has been lost.

Initially, I thought that maybe the problem was with me. But as I investigated the issues I was having with systemd, I'd see so many other bug reports, forum postings, mailing list postings, IRC logs, blog articles, and other online communications from people who were also having many other problems with systemd.

Debian offered a much better user experience before it switched to systemd, and a much worse user experience since.

Re: Ubuntu 24.04 (and Debian) removed libsystemd from SSH server dependencies

#30

libsystem is such a bizarre abstraction covering far too much surface area. The name alone is a code smell. Why is the same library used for both internal service management and for services implementing on-demand launches and notifications?

That is the systemd way, and what many of us have pointed out for years as a major risk of the approach.

This reads as though your objection is to the scope of systemd rather than its implementation detail, which isn’t where my objection lies.

I have nothing against the service management stack also addressing common principles like logging and on-demand starts a la inetd, but the notion that applications should link against a component of the service manager which is also used by the service manager boggles my tiny mind.

Post reply on HN