Fwiw, it’s possible to use zstd instead of xz, which was created at and actively maintained at Facebook.
So if you were expecting Big Tech to identify this class of problem and do something about it, it seems like they are. But if you expected them to eliminate every single possible instance of such an issue, that’s a bit much isn’t it?
Build system is complex because of legacy and need to support millions of different platforms and distros.
Sure; you can hide nasty code in rust. But I think it would have been harder. Not because rust is memory safe. But because rust is decades newer, and it doesn't inherit all of the quirks in C, in its build system and obscure mechanisms for dynamic linking.
Bingo. This was a highly motivated, targeted, and well planned compromise of the supply chain itself. And funnily enough, using a memory-safe language could have actually made it less likely for this to be detected.
There were symptoms showing up prior to the discovery, most prominently Valgrind errors in otherwise unrelated project builds. (ref: https://bugzilla.redhat.com/show_bug.cgi?id=2267598)
As a result, there is a sentiment in the peanut gallery that "memory safe language == Rust".
You are correct in that a segfault in a project written in memory safe language gets more scrutiny. But imagine for a moment what would have happened if the compiler guaranteed that those Valgrind-caught memory access violations could not have occurred in the first place?
We got lucky, and the developers who wrote the actual backdoor were sloppy. They were aiming for sneakiness and evasion first, memory correctness would have likely been an afterthought. The next group tasked with a similar approach will know better.
But it’s a moot point because there are undoubtedly other mechanisms a malicious maintainer could use to inject a vulnerability. Just not this exact one.
The underhanded C contest would be a lot less entertaining in rust. Thats a good thing.
It wouldn't solve the underlying problem permanently. But I don't think there's any slam-dunk solution here. I'll take any small wins where we can get them.
>The compiler supports various methods to link crates together both statically and dynamically. This section will explore the various methods to link crates together, and more information about native libraries can be found in the FFI section of the book.
I’m talking about what happens in practice, which is shipping static binaries that contain all of their dependencies, except for libc.
Introducing such hidden bugs that are basically impossible to find is much harder in a memory safe, statically linked language.
We can argue about the specific implementation, but to suggest that it’s impossible seems incorrect to me.
Haven’t nation state actors openly infiltrated high level companies? This would provide a false sense of security imo. If anything, we need better testing and behavior heuristics for incoming code.
I develop cool thing X. Now, 100 minor things depend upon it.
Suddenly, Facebook (or anyone of that size!) starts using it, and decides to vet the maintainer/author.
Who says anyone has to cooperate? It's his software. He wrote it. Don't like it?
Well tough!
Now obviously Facebook could author a replacement. It could fork and maintain.
But the very nerve that Facebook(or anyone!) would insist upon a security audit of the anonymous author would be very, very strange.
Next up, I lend a neighbour my lawn mower, after he comes begging to borrow it. Oh but wait! My neighbour now wants me to sign a libabilty form, and also undergo a security check, all so he can borrow my lawnmower!
The hell?!?!
Hoping this illustrates my point. The project author owes nothing to anyone.
And it gets more wacky, if there are 100 companies demanding audits. What? Demand?!
This is where distros are the strong point. They aren't perfect, but they catch a lot of stuff on their own. And maintainers of different distros often backchannel, support each other in this.
In terms of some government org "vetting" people? Way to take the last vestiges of free software, and hacking, and turn it into a gatekeeping, bureaucratic nightmare. I guess one will need credentials, government id, a 10 year security check, to be fingerprinted, and so on? Security clearances work like that, and that's how you vet someone.
I’m also personally torn on how much we want giant private companies controlling more and more of the core compute infrastructure and software.
In an ideal world, the code and software itself would be automatically analyzed for malicious use cases in release and deployment pipelines, but that’s a magic hand wavy kind of ask of a huge magnitude and complexity.
The point of the anecdote is to supplement the parent poster by stating that their hypothetical scenarios are already happening.
We should have better testing and more eyes on incoming code for projects we depend on. But my point I guess is that vetting maintainers is not an option.
Same reason why commercial planes always have two vetted pilots in the cockpit and ATC watching their every move. People can and will do malicious shit, if their mental health declines.
Edit: A Russian sounding alias was also used.
Or maybe they actually are Chinese, and want me to believe the sentence above. :)
Spreading doubt is taught in bad actor-academy.
I think your comment is facetious and adds nothing to the conversation.
Neither this one, nor the previous one.
Jie would be female, Jia male
While gendered names do exist, you can't easily tell from the romanization, it depends on the exact characters used. And most likely "Jia" is the surname, or rather the romanization of one of five different surnames.
Also from that writeup. It also links to https://rheaeve.substack.com/p/xz-backdoor-times-damned-time... which suggests the actual TZ of 'Jia Tan' to be UTC+02/03