3 ms·

You are right, but C/C++ was vulnerable to this particular MO because of its complicated build process.

• uecker 3y ago
  I would say today there is no real need for autoconf anymore in C / C++ and the build process could be fairly easy.
• kukkamario 3y ago
  There are million ways to hide exploits even in "safe" languages. If you have a bad actor that can spend couple years prepping how to hide an exploit, then it doesn't really matter which programming language is used. Build system is complex because of legacy and need to support millions of different platforms and distros.
  • lifthrasiir 3y ago
    Different platforms and distros still share a handful of common environments, while autoconf was invented back when there were hundreds of different environments to care about. Xz doesn't depend that much on the platform and could have ditched autoconf at least in the theory. But such switch is annoying in the world of C/C++.
  • josephg 3y ago
    I'd say there are fewer ways to hide exploits like this. Rust doesn't use configure scripts. And it has a built in testing mechanism - so there's no need for makefiles to run scripts. Any build scripts as complicated as configure in a rust project would be a much bigger red flag. And it would be rare and weird to see GNU_IFUNC in use in a rust project too. Sure; you can hide nasty code in rust. But I think it would have been harder. Not because rust is memory safe. But because rust is decades newer, and it doesn't inherit all of the quirks in C, in its build system and obscure mechanisms for dynamic linking.
• lewis1028282 3y ago
  It's easy to hide things in the Python build process as well. Things like using `getattr` instead of . (dot) etc