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 $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.
@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.)
@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.
@joepie91 Yeah, we'd also have policies that *should* prevent something like this.
I am not sure though we would have catched that. Its in a testcase and also compressed so some "weird binary for testing, right?"
It is a good use case for the biweekly tech meetup with the devs though.
And a good reason for money for trainings for the developers to learn to do security reviews.
Knowledge gives confidence to reject something.