On Sat, Mar 30, 2024 at 10:57 AM Eddie Chapman <ed...@ehuk.net> wrote: > > No, this is the the bad actor *themselves* being a > principal author of the software, working stealthily and in very > sophisticated ways for years, to manoeuvrer themselves and their software > into a position of trust in the ecosystem whereby they were almost able to > pull off the mother of all security nightmares for the world.
This is entirely speculative at this point. It isn't certain that the author is the one behind the exploit, and if they were, it is not known for how long their intentions were malicious, or even what their motivations were. It is also unclear what pseudonymous accounts with what projects are associated with the attacker. You could end up being right, but it probably makes sense to at least give things a few days for more facts to become available, before making decisions to retool the entire distro. I think the bigger challenge is what could have been done to prevent this sort of problem in the first place. There are so many projects that end up with code running as root that have one or two people taking care of them, and if somebody does the work to become one of those maintainers, there aren't many people looking out for problems. I think one thing that would help here is for distros to have better ways to ensure that the code in the scm matches the code in the tarball. It is pretty common for releases to be manipulated in some way (even if only to gpg sign them, but often to switch from commit IDs to version numbers and so on), and that can be a place where stuff gets added. That still says nothing about obfuscated code, which this also involved. -- Rich
