5 ms·

Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. e

by ptx 3y ago

Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)

bonzini 3y ago
Yes, it's usually regenerated already. However even the source is often pretty gnarly. And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.
- jnxx 3y ago
  > And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
mysidia 3y ago
The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz" part of the backdoor that they even put in the repo. It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.
WatchDog 3y ago
gradle-wrapper is just a convenience, you can always just build the project with an installed version of gradle. Although I get your point, it’s a great place to hide nefarious code.
deleted 3y ago
[deleted]

by ptx 3y ago

bonzini 3y ago

Yes, it's usually regenerated already. However even the source is often pretty gnarly. And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.

jnxx 3y ago
> And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.

mysidia 3y ago

The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz" part of the backdoor that they even put in the repo. It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.

WatchDog 3y ago

gradle-wrapper is just a convenience, you can always just build the project with an installed version of gradle. Although I get your point, it’s a great place to hide nefarious code.

deleted 3y ago

[deleted]