Matthew GarrettThe presumption that free software is sufficient or necessary to ensure all software you depend on is trustworthy is simultaneously naive and ignorant of what software is capable of. The only realistic way to develop trust in software is to trust the people who write it, and development processes associated with free software make that trust easier.
But merely being free software isn't sufficient - software developed in a way that prevents arbitrary observers from witnessing design conversations may still be free software, but doesn't give us a strong reason to trust the developers. We all know how easy it is to hide dubious code in the open. The libxz backdoor was discovered by examining the binary and tracking that back to the source, not through source examination.
Frankly: binaries are the thing that executes on your system and embody the truth of software behaviour, and with modern technology it's often *easier* to determine that truth through the binary than through the source code (throw the "login" app from Reflections on Trusting Trust into Ghidra and you'd learn the truth even if the source code wouldn't tell you that)
bibor@mjg59 true but source access enables you having debug symbols, which are a blessing if you want to navigate to the critical parts you want to verify.
@twomikecharlie Assuming whatever built the source corresponds to the source, which, well, XZ and Solarwinds are counterarguments to
@mjg59 IIRC, I would argue, especially the xz backdoor is vastly better to analyze if you have the source and the build scripts, because of all the weird artefacts (obfuscated script, .so) in the build process it relied on. if you analyze the tarball with initial suspicion you can quickly see where's something wrong. In the binary this would've taken some time.
@twomikecharlie It's unambiguous that the issue was identified from the binary. What was in the source gave further insight, but in the end it was still an obfuscated binary.
@twomikecharlie And I'd challenge anyone to have identified the issue from the source without seeing the behaviour the binary had. I would never have seen it. I know nobody who's said they would have done.
@mjg59 yeah I agree about seeing the runtime behaviour is the absolute best indicator. The backdoor in the buildscript was near impossible to spot. But if suspicoun was rised, however, and I need to analyze the backdoor, i would rather being (and have been) able to analyze it with the build files and source to track the injection. So still better to have them than not.
@twomikecharlie Having the scripts and git history made it easier to identify what had happened, but I think the binary alone was enough to demonstrate malice
@mjg59 We can agree on that, If you run it, yes. Otherwise I honestly don't know anymore how hard the fishy functions were to spot statically.
@twomikecharlie Man I could only see it because I was told what to look for