Am Mittwoch, dem 03.04.2024 um 16:00 +0200 schrieb Michael Matz: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote: > > > > > Seems reasonable, but note that it wouldn't make any difference to > > > > this attack. The liblzma library was modified to corrupt the sshd > > > > binary, when sshd was linked against liblzma. The actual attack > > > > occurred via a connection to a corrupt sshd. If sshd was running as > > > > root, as is normal, the attacker had root access to the machine. None > > > > of the attacking steps had anything to do with having root access > > > > while building or installing the program. > > > > There does not seem a single good solution against something like this. > > > > My take a way is that software needs to become less complex. Do > > we really still need complex build systems such as autoconf? > > Do we really need complex languages like C++ to write our software in? > SCNR :)
Probably not. > Complexity lies in the eye of the beholder, but to be honest in > the software that we're dealing with here, the build system or autoconf > does _not_ come to mind first when thinking about complexity. The backdoor was hidden in a complicated autoconf script... > > (And, FWIW, testing for features isn't "complex". And have you looked at > other build systems? I have, and none of them are less complex, just > opaque in different ways from make+autotools). I ask a very specific question: To what extend is testing for features instead of semantic versions and/or supported standards still necessary? This seems like a problematic approach that may have been necessary decades ago, but it seems it may be time to move on. Martin
