5 ms·

This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-n

by Spivak 1y ago

This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-notify which is the way services can tell systemd that they're ready. The protocol is literally sending the string READY=1 over a file descriptor. libsystemd contains a reference implementation but it's a protocol specifically for the reason that every service isn't supposed to link to libsystemd. Maintainers thought it was easier to link in all of libsystemd (and therefore xz) into OpenSSH just for the sd_notify function. Just link in a huge library into security critical code, what could go wrong?!

panick21_ 1y ago
Putting to much unnecessary stuff into libsystemd is something sub-optimal that they do. Its a bit lazy. But it is correct that people should link it like that.
- Spivak 1y ago
  From the horse's mouth. https://mastodon.social/@pid_eins/112202687764571433 https://mastodon.social/@pid_eins/112202687764571433 > In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial I'm actually surprised that they added the note about code duplication after adding the standalone implementation specifically so people won't do that.
AlotOfReading 1y ago
You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html https://www.freedesktop.org/software/systemd/man/latest/sd_n...) explicitly says: using this library should be preferred in order to avoid code duplication Then, if you're not intimately familiar with systemd you might wonder which is more standardized and less likely change between the API and the protocol. Maybe you make the reasonable assumption that it's the API. Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add. All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.
blucaz 1y ago
It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd <-- libsystemd <-- xz. The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers. Idiots instead rant about "muh systemd" and use it to attack other maintainers.

by Spivak 1y ago

panick21_ 1y ago

Putting to much unnecessary stuff into libsystemd is something sub-optimal that they do. Its a bit lazy. But it is correct that people should link it like that.

Spivak 1y ago
From the horse's mouth. https://mastodon.social/@pid_eins/112202687764571433 https://mastodon.social/@pid_eins/112202687764571433 > In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial I'm actually surprised that they added the note about code duplication after adding the standalone implementation specifically so people won't do that.

AlotOfReading 1y ago

You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html https://www.freedesktop.org/software/systemd/man/latest/sd_n...) explicitly says: using this library should be preferred in order to avoid code duplication Then, if you're not intimately familiar with systemd you might wonder which is more standardized and less likely change between the API and the protocol. Maybe you make the reasonable assumption that it's the API. Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add. All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.

blucaz 1y ago

It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd <-- libsystemd <-- xz. The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers. Idiots instead rant about "muh systemd" and use it to attack other maintainers.