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.

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

@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".

@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

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)

@mjg59 I have no direct contact with you, but this is all solid advice. Stay well.

@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.

@mjg59 "better is always good"

@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

@mjg59

Ubuntu might run all their mirrors on the same server, but Debian doesn't. Where you get your signatures, and where you get the binaries, are meant to be different sources. It'd be a multinational effort to deploy a targeted attack this way.

@shaknais And there's one set of people responsible for pushing that, and I know all of them and trust all of them, but why do you?

@shlee Whilst I'm happy to move over to aus.social - wondering about starting another small community aus.art for artists (unless there already is one this newbie is not aware of...)
thoughts?

@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.

@mjg59 If it's proprietary software, it's most likely proprietary malware.

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.

@mjg59 The tests in deblob-check will check for test data and report them.

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.

@Suiseiseki Have you run it against the compromised xz repo? What would manual checking have told you?

@mjg59 No, as I can't be bothered - I don't use systemd.

Assuming the backdoor part was disguised in an array of numbers, manual checking with cpu_rec or whatever would have uncovered that such is CPU instructions.

@Suiseiseki No, it wouldn't, because it was encrypted. Please try to ensure you know what you're talking about before talking.

@Suiseiseki "Ah but why would test data be encrypted we could tell the difference because of the entropy" no, you couldn't, because the test data in question was supposed to be malformed compressed data and good compression and good encryption result in equivalent levels of entropy

@mjg59 Sir I have been informed that there is no social problem that cannot be solved with the proper licensing terms.

@jwz Ah that would explain SF liquor licensing

@mjg59 CA licensing, to be fair.

@mjg59 And avoid Telegram if you are using it multi-device... Meaning you cannot have e2ee. My big question.. Why isn't it enabled by default? Their protocol is supposedly engineer to be optimized for messaging. Why wasn't e2ee ever considered important by a messenger that had to deal with such difficulties (the regime)

@tinkerer because Telegram is bullshit

@mjg59 I'm not talking, I'm writing.

Turns out that in that specific case, it could be hidden as compressed data that didn't look out of place.

For test data that is compressed, the way to test it is to decompress it and see what it contains - of course you should be wary if you can't figure out how to decompress it (although that is extremely common to occur for compressed formats that don't use headers).

@Suiseiseki it was deliberately invalid compressed data because it was a test

@mjg59 😉

@mjg59 @shaknais And further, there is one set of people who control the private key, and if that leaks it is trivial to do man-in-the-middle attack substituting malwared binaries instead of a real Debian package. Debian do not publish any public information about who that set of people is, and how the private key is protected, so even if someone personally know all details (how can you verify that?) the process is not transparent or inspire confidence

@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.

@jas @shaknais I'm in a position to verify all of that but obviously whether you trust me there is a personal opinion!

@mjg59 ah the gnome software special

@mjg59 @shaknais Trusting a transparency ledger like Sigstore or Sigsum on what the intended Debian packages are seems preferable to me, compared to trusting you to trust a set of unidentified people behaving accountable (and that they never make mistakes or could be coerced). We can configure machines to only trust binaries whose checksum are recorded in Sigstore/Sigsum. There are still tons of problems left, but it would mitigate some concerns.

@jas @shaknais There's definitely more technology we could apply to the problem that would make it easier to express this trust, but there's weird pushback in some cases

@mjg59

...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

@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.

@lil5 Cool what do you think people on the street are carrying because it's not a fucking laptop

@mjg59 as long as you trust Ghidra. 🤔

@GerardThornley Ah but I can simply examine its source code

@mjg59 🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢...

@GerardThornley fuck

@GerardThornley (seriously this is what the bootstrappable builds project is for)

@mjg59 we're gonna have to start making our own transistors...
In maybe a century or two, we might know the truth about early 21st century computing.
As long as the effort hasn't been infiltrated in the meantime... 😏

@tinkerer @mjg59 I worked part-time at the data-centre that hosted the very first servers of the telegram guy’s original ‘big break’ (and saw him and his ‘developers’) and the answer to your question is that he copied existing stuff, with minimal effort involved, for markets where the originals didn’t gain traction (usually because the companies behind those didn’t really bother with the markets in question, like Facebook didn’t with Russia back in late aughts)

Telegram was simply WhatsApp for ex-USSR and at the time they didn’t even consider security

@mjg59 some people fetch Debian repos over Tor specifically to avoid this

@noisytoot Makes it easy to backdoor the kind of person who uses Tor

@mia @mjg59 And... Still now? I mean, I don't know much about cryptography (to audit MTP2 proto) but they could still make e2ee the default (if they wanted).

@dotstdy @mjg59 That menu is about these Flatpaks' default permissions, not whether or not you trust the software inside them.

@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.

@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. This is a normal and sensible response.

@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

Because you have my keys. Or at least, you should. Considering I have published to Debian in the past, and I cross-signed the entire tree to be able to prepare the package.

@shaknais That protects the upload process as long as it works as it ought to, what happens next?

@mjg59

You sign, what I have already signed. If both signatures check out with multiple rings, then everything works.

If you break something, my package is invalidated because you don't have my original private key, only the public.

@mjg59 The "not wanting to trust humans and building a society with ruled by technology" is unfortunately a very common ideology in full-blown tech-fascists as well as FOSS nerds. Which may explain some of the overlap.

@jas @mjg59

Well, the Release key rolls regularly, so it would only be a limited time attack, if it did leak. And all the keys are cross-signed, so the individual packages would still break because they can't be resigned to something else. A new package could feasibly be deployed.

@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

@shaknais But that's not what Debian does?

@shaknais @mjg59 Targetted attacks (per-IP substitute) are still easy if you can get valid signatures for the Debian archive public key. And would likely be undetected in the normal case. Especially so since the default transport is non-https. Signatures on Debian packes (*.deb) are not verified commonly, only the signature on the top-level InRelease file, so I don’t understand what you mean by cross-signing here?

@mjg59 Don’t mistake criticism of Signal for being advise not to use it.

@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

@mjg59
crazy idea: @lil5 can use XMPP and deltqchat even if vast majority of people don't

@ahltorp Unfortunately a lot of criticism of Signal is phrased in rather absolutist terms that go like "Signal sucks because <some reason>. Use <other thing> instead!".

As opposed to, say, "Signal is great for a lot of people, and you should be using it whenever possible even though it isn't perfect about <thing>."

Could it be even better in some respects? Oh, sure. But it's still damn good about what it tries to do.

@mjg59

@mjg59 @buherator “Only the binary can tell you the truth” — Chris Rohlf

@jas @mjg59 @shaknais you seem to be reinventing IMA which is already in the Linux kernel

@mjg59
Unless you trusting trusted ghidra 🤪

@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 alterior motive...

@dotstdy but the accusation is right...

@karolherbst I like lots of stuff about gnome, the design work is broadly very clean and nice in particular. And it has a pretty good degree of consistency across the whole ecosystem. There are things which annoy me, and then there's things like this which are pretty bad. Wcyd it's software.

@dotstdy sometimes it matters more who brings up criticism than the criticism itself in order to judge if it's constructive or just demoralizing people having to read through it.

@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.

@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/

@gusseting Happy to host the VMs for your new instance if you think there is value in it.

An Australian artist instance would be fun... but you're more than welcome on A.S (from the admin)

@shlee thankyou - but given that I don't even know what a VM is - I. have much to learn.
I think switching this account over to aus.social might be a good start + learning experience, then working out how to host my own art account, then start hosting others, along with a curation account that is part of the fee for joining the server. curation accounts can be tricky, but I had one - noticingceramics on IG that was popular, I just have a hatred for meta these days :)

@gusseting Please keep me in mind if you want to start your own "instance". I'll help with the technical details.

@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.

@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".

@eighthave @mjg59 I am a free/libre software supporter, but to play the devils advocate here, wouldn’t it be possible for Microsoft (or Apple, or…) to publicly post all their source code with recipes how to build them reproducibly etc to fulfill QA, security and auditing needs? They don’t have to change the license, just openly publish things to allow public audits. Today this is not realistic, but may happen.

@jas @mjg59 Sure "source available" would be an improvement over secret source code, but that is only one piece of the puzzle. Free software means all users are free to fix and deploy issues on their own schedule, regardless of what the copyright holder thinks. That is also a key piece of delivering trustworthy software.

@eighthave @mjg59 Indeed and the power control is the real problem that free software helps with. Open source misses this point, and is not different from proprietary software in this regard. This is a social issue more than technical. Free software may not even be sufficient - just consider the AOSP ecosystem, is it realistic for anyone but Google to sustain it?

@jas @mjg59 I agree, the focus must be on the four freedoms and user freedom. Unfortunately, Google has proven quite masterful at maintaining control even when working with free software. AOSP and Chromium are two key examples. The key is that Google makes sure it is the upstream, while suppressing things that shift the power to the developer community around it. With AOSP, there is a big enough community to maintain it without Google. That requires them all getting separately organized.