Tootfinder

1/2 Looking at one of the #xz writeup, this struck my eye: “The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf.” Ah, GNU AutoHell, I remember it well. Tl;dr: With AutoHell, even if you're building for a 19-bit Multics variant from 1988, it’s got yo…

Zdaje się, że już wszyscy i ich babcie używają exploitu w xz/sshd, by szerzyć swoją agendę, więc i ja nie będę gorszy.
1. #Autotools to zły system budowania. Skryptu configure są absolutnie nieczytelne, więc nikogo nie powinno dziwić, że nikt nie zauważył złośliwego kodu — wszak nie różni się niczym od całej reszty tego bełkotu.
2. Statyczna konsolidacja i włączanie zależności są złe. W…

I suppose everyone and their grandmother is now using the xz/sshd exploit to further their own agenda, so I am going to take this opportunity to further mine as well.
1. #Autotools are a bad build system. If configure scripts are completely unreadable, there should be no surprise that people won't notice obfuscated malicious code in there, provided that everything else is obfuscated by design.
2. Static linking and vendoring is bad. Do you know why the prompt #security response was possible? Because we just had to revert to older liblzma. We didn't have to check, patch and re-release hundreds of projects. It wouldn't be this easy with #RustLang and cargo.
3. You can blame #OpenSource for being underfunded and open to abuse in core system packages. However, no IT project can be resilient to a sufficiently powerful bad actor, and that it happened to xz is just an incident. Corporate projects aren't resilient to it, neither is proprietary, closed-source software.
So, embrace #Meson, embrace dynamic linking, embrace distribution packaging and donate to open source developers.
#Gentoo