Thread by @CopperheadOS

These are completely conflicting opinions:

1) Closed source software with no obfuscation and all compiled code accessible in a controlled environment is substantially harder to audit
2) Publishing sources doesn't make it substantially easier for attackers to find vulnerabilities

It's extremely hard to make the case that publishing sources makes it easier to find vulnerabilities when you're talking about simply stripping out comments and internal naming from Java / JavaScript code...

Take a look at underhanded-c.org/_page_id_25.ht… if you think sources are magic.

If you're trying to find an intentional backdoor, the developers are your adversaries. If you're looking at the sources they choose to publish, you're looking at the code in the format where they cleverly hid a vulnerability in a deniable way if they aren't total idiots.

Assuming your adversaries are idiots is always a bad move. It is not necessarily a good idea to even bother looking at the source code if you're looking for a backdoor. Imagine trying to find a backdoor in C sources by someone like @johnregehr with undefined behavior as a hobby.

Oh, and don't be so sure that reproducible builds where you're *highly* encouraged to use exactly the same (out-of-date!) toolchain as the adversaries is a great idea.

AOSP/CopperheadOS/Chromium builds are reproducible. Is it a security feature? We wouldn't claim it to be one...

Anyone that isn't a complete idiot isn't going to make a backdoor that isn't 100% deniable by being a completely plausible vulnerability.

The best way to do it is leveraging a library or toolchain bug where it's not even a bug in the code written by the adversary...

How often do you run into library / toolchain bugs? Just pick one, trigger the same bug you triggered by accident and there's your backdoor. It's not even a bug in your code. It's not just completely deniable that you added a backdoor, it won't even appear to be your mistake.