The 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.
Post
@mjg59 I agree that free software alone is not enough to make trustworthy software, but I have to emphasize that free software is a requirement for trustworthy software. That unlocks key practices like reproducible builds, public audits, etc. Without all that, the only option is "hope they are doing the right thing".
@mjg59 how about testing by experienced users and developers?
@mjg59
> "The only realistic way to develop trust in software is to trust the people who write it"
I cannot agre more!!
@mjg59 ah the gnome software special
@mjg59 too bad I can't cite this.
You absolutely nailed it. In fact the use of hard- and software produced by others is a delegation of responsibility carried out by implicit trust.
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.
If it's actually free software, it's most likely not malware.
>We all know how easy it is to hide dubious code in the open.
The libxz/libsystemd backdoor source code was not published - it was included as proprietary software without source code in the release archive - but it happened to be discovered early during execution.
Maybe a enhanced generic version of deblob-check would be useful.
@Suiseiseki No, nobody is checking whether something that appears to be test data is free software or not. That's not a thing anyone has ever done.
Obviously one would need to manually check the test data and see if it's free software.
For test data in Linux, deblob-check has reported it and it has been manually confirmed that such test data is proprietary and such therefore has been removed in Linux-libre.
@mjg59 💭 But didn't the libxz backdoor require the source available to figure out whether the behaviour was malice or just a quirk?
Since it's much easier to read intention from source metadata and source code itself, than from binaries.
@sheogorath Oh god no, bear in mind that the backdoor was embedding encrypted binary code into the library - it was actually initially easier to see that code in the binary than in the source
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)
@mjg59 @buherator “Only the binary can tell you the truth” — Chris Rohlf
@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.
@[email protected] @[email protected] I mean, hasn't Microsoft been shipping Windows debug symbols for ages, despite being closed source?
I know they don't do it for every component, but there's no reason they couldn't without releasing their source.
@twomikecharlie Assuming whatever built the source corresponds to the source, which, well, XZ and Solarwinds are counterarguments to
@mjg59 as long as you trust Ghidra. 🤔
@mjg59
This is what the opening line of the trusting trust paper argues for.
But people often misunderstand the message and focus on "compiler backdoor go brrrrr".
I believe that free software is vital. People should have control over everything that executes on their system. But let's not kid ourselves - even someone running linux-libre on a machine with open firmware on a custom fabbed RISC-V with no microcode hasn't verified every line of code they execute, and nor has the community as a whole
@mjg59 Yeah. So keep an eye on what your systems communicate with. Both externally and within your own network. (A big ask for normal humans, and apparently some large corporations.)
At some point we have to trust that other humans won't just lie to us - and that's true whether the software is free or proprietary. Debian could modify mirrors to push a backdoored package to a specific IP address, but the people wit the ability to do that are well known to the community and we trust that they wouldn't. That's not a function of Debian being free software - that's a function of an open community