[fabrice_d]

But auditing the source is only useful if you can do reproducible builds to be sure you run the audited source.

This is rarely the case unfortunately, and for most of open source prebuilt software you use, you rely on trust and not on audit.

[Sir_Cmpwn]

That's not true. You could always, you know, run the version you compiled yourself.

[kasey_junk]

We’ve known for 30 years that’s not enough (depending on your risk characteristics).

Trusting trust is one of the seminal talks in software.

[Sir_Cmpwn]

We've known that in theory your compiler et al can be backdoored but in practice we can feel a lot safer compiling our own software than using proprietary binaries.

[kasey_junk]

I think that might be where we disagree. Without a competent security audit I think you are falling back to trust.

Open Source vs Closed source is not where I or the security professionals I know put most trust emphasis. I would enthusiastically trust something closed from Google over a rando open source project.

But back to the original point, even the most basic audit steps are the same on an open source project vs closed one. Observe what the binary does & inspect it for standard patterns.

[Sir_Cmpwn]

Observation only goes so far. You couldn't find backdoors unless you started to decompile it.

I think having a trusted compiler is an important first step to trusting software, even if you have to analyize it in depth yourself.

[kasey_junk]

2 actually:

https://www.dwheeler.com/trusting-trust/dissertation/wheeler...

But note you are now adding a lot of extra preconditions that are largely not available.

The counter argument is reverse engineering & black box audits are actually easier than getting the conditions right to trust code audits. As a bonus they work regardless of the code availability.