More thoughts on #xz: it seems that the bootstrap code for the backdoor was hiding in difficult-to-understand code. I hope this prompts people to start taking code readability seriously as a security factor.
It's much harder to hide malicious code in code that's easy to understand.
@joepie91 Difficult to understand is a nice wording for basically hard obfuscated.
Noone reviewed this and said "i understand all of this".
@mcfly I was thinking through whether this code would have made it through the dependency auditing process at $customer, and my conclusion was "no, it would not" - they have a policy that code that we cannot understand will never be approved, and this is basically why that policy exists...
@mcfly $customer auditing involves everything that is part of the release, so also test files - an eval on anything related to a binary file would definitely be considered something that warrants suspicion and probably rejection.
Like, it's just a general rule of "if it's in the release, it must be explainable and possible to reason about". Google dependencies frequently get rejected because they do not meet this standard...
I think that that one rule alone - "anything that cannot be explained, cannot be accepted" - would prevent most attempts at backdoors, to be honest. At the cost of not tolerating needlessly bad code.
@joepie91 I agree in theory but i see it too often different.
Code reviewing is often something that is done in an improvable way.
I will try to use this to get money and ressources for some training there.
@mcfly (Which can be a real cost; some developers are going to insist on dubious programming practices, and that means simply not being able to use or distribute their work.)