9 ms·
Funny. I was just saying the same thing to one of my partners just 4 hours ago. Culpability also must be laid at RedHat's feet for sanctioning the practice of
by gladiatr72 3y ago
Funny. I was just saying the same thing to one of my partners just 4 hours ago.
Culpability also must be laid at RedHat's feet for sanctioning the practice of side loading libraries into such a critical service's address space. Their drive to cellularize systems management has overtaken their common sense.
The idea that they could not be bothered to answer the call of the sole maintainer of a library used in such a critical path in his time of need is, well, astonishing.
- dralley 3y ago1) Debian includes this downstream patch, also. 2) A potential explanation for "why now" is that systemd DID prevent these dependencies from loading automatically in a patch one month ago [0], and the patches to lzma enabling the backdoor merged a few days later, followed by (as we know) an immediate and somewhat heavy push to get distros to upgrade driven by sockpuppets. It could be a total coincidence, or it could be that the attacker jumped to pull the trigger before the window of vulnerability started closing on them [0] https://github.com/systemd/systemd/pull/31550#issuecomment-1972737923 https://github.com/systemd/systemd/pull/31550#issuecomment-1... I think it's a bit cheap to blame systemd here, and systemd does not equate directly to Red Hat either.
- 1oooqooq 3y agoI believe they were talking about sideloading a binary tarball instead of building and repackaging. Choosing a distro is nothing but choosing where you place your trust. I can understand debian cutting corners here and there. But RH have little excuses with the money they make. Yet, even a superficial analysis, show them to be less trustworthy than the anime-avatars maintaining gentoo or arch.
- dralley 3y agoArch was doing the same..