Woodman
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)
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
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
Build communities. Find people you trust and place more faith in their recommendations. Don't trust anyone who says there's a magical solution here.
(And for the love of God ignore anyone who's telling you not to use Signal right now, every alternative is meaningfully worse for the vast majority of people)
Nick_Lange@mjg59 "better is always good"
Ben Curthoys@Nick_Lange @mjg59 "don't let the best be the enemy of the good."
Tom Stoneham@mjg59 Indeed. Good enough is good enough.
Though it is worth telling people they can create a Signal account with an unregistered SIM card (it just needs to receive one SMS) so even that minimal metadata doesn't trace back to you.
mathew@tomstoneham @mjg59 All that phone number does is potentially let the government know you’ve downloaded and set up Signal. Signal can’t match your phone number to conversations.
https://theintercept.com/2024/03/04/signal-app-username-phone-number-privacy/
@mathew @mjg59 My thought was *Signal* can't but Signal *users* can. If someone has your number on their phone, that shows up in the Signal app, thereby matching you to your Signal identity.
One seized phone like that and all your Signal conversations on other seized phones are deanonymised.
In general, protestor threat models have to include police accessing information about you on other people's phones.
lil5@mjg59 let me know when signal supports more than just android and iOS (the support desktop apps don’t help with a dumb phone/or Linux phone).
Simplex, xmpp, deltachat all function on just a pc and/or smartphone.
Simplex, xmpp, deltachat all function on just a pc and/or smartphone.
Wolf480pl
Khleedril
Magnus Ahltorp@mjg59 Don’t mistake criticism of Signal for being advise not to use it.
Carlos SolísEven then - in case you somehow don't trust Signal's default servers to be uncompromised, projects to make Signal self-hostable are in progress. github.com/mollyim/flatline-pl…
lj·rk
bmaxv...but they could be publishing reproducible builds and we could globally share whatever checksum verifies the correct reproduction, so I would say that that particular thing could be improved that way.
But overall you are absolutely correct and I stand behind your message.
@bmaxv We'd need a mechanism for those checksums to be verified on first install and that's still a hard problem but yes I agree that this would be a better world than where we are now and we should be working on that
Noisytoot@noisytoot Makes it easy to backdoor the kind of person who uses Tor
jbaggs
Morten Linderud@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".
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".
Gerard@GerardThornley Ah but I can simply examine its source code
@GerardThornley (seriously this is what the bootstrappable builds project is for)
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
PJB@twomikecharlie @mjg59 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.
I know they don't do it for every component, but there's no reason they couldn't without releasing their source.
raptor 
@mjg59 @buherator “Only the binary can tell you the truth” — Chris Rohlf
pixx
Sheogorath@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
Florian Neumann 
@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.
jwz@mjg59 Sir I have been informed that there is no social problem that cannot be solved with the proper licensing terms.
Josh Simmons
Hooly@hooly @mjg59 ah yes "potentially unsafe" and "safe" in big boxes on the front page for the software you're installing refers not to the software you're in the process of installing from the software installation tool you're using, but instead to the flatpak configuration which users know about, and understand. This is a normal and sensible response.
☃️karolherbst☃️@dotstdy you really love to trash talk gnome on entirely unrelated occasions, just to trash talk gnome, don't you?
Maybe just stop it already.
@karolherbst it's not specifically a gnome issue, though gnome's phrasing is slightly worse than upstream flatpak.
@dotstdy yeah, but you hate gnome and the reason you brought up gnome here is because you wanted to hate on the project not because of the point you are bringing up here.
@karolherbst is it possible to be normal about software for five minutes without accusing everyone of having some nefarious ulterior motive...