Rewrite xz in rust

[jmwielandt]

tukaani-project/xz#102

I think in this case it makes a little bit of sense xD

[Geno1024]

oh you get it earlier

[Lattay]

I know this is a joke, but just for the sake of argument, I don't see what Rust would have brought to prevent this backdoor. It's not like someone exploited a buffer overrun. It could have been hidden in some macro madness instead of test file, maybe.

[jmwielandt]

@Lattay as har as i know, your macro can't be cryptographycally encrypted. it would be obfuscated, but only in a traditional way instead of having an unreadable blob of bytes

[Rudxain]

macro can't be cryptographycally encrypted

Unless we took inspiration from Befunge or Malbolge, lol. We could write a Brainfuck-like interpreter that decrypts the program at load-time, then runs it. We would have achieved obfuscation and obscurity (not true security, because the key is embedded in the interpreter).

This doesn't directly allow us to encrypt the macro, but we can split the interpreter (plaintext) and program (ciphertext blob). We could even add several layers of indirection to the interpreter, and encryption with multiple keys spread across the codebase. We could even use existing data from the codebase as keys, to further hide the decryption points.

But all of this is moot (and maybe BS, considering I'm no expert at insidious obfuscation), as it would be extremely sus to embed an interpreter in a program that's supposed to NOT be Turing-complete

[Lattay]

@jmwielandt no idea honestly, just spitballing. I don't understand macro writing. But remember that the backdoor is not just some build script: it is a conjunction of bash, m4 macros and manipulated corrupted compressed binary blob. I just guessed one could replace the m4 part with rust proc macros.

[porky11]

At least when only using standard rust features, it would be more a little more difficult to hide something like that.
But that would apply to most languages.
At least having one standard build system, which uses only Rust by default, seems like an improvement to me.
It would be easier to see when something suspicious happens like writing to actual files in tests or executing external scripts/programs from tests.
People still have to be aware of these issues.

[jmwielandt]

earlier today i watched a video about the changes introduced in rust 1.77 and it mentioned something about cargo build scripts. I've found this: https://doc.rust-lang.org/cargo/reference/build-scripts.html. idk what its capabilities are but i comment it in case some wise person can enlighten us.

in other matters...

i don't wanna brag but...

is an honor to me to contribute to the memes.

ps: i'm sorry mr. lasse in case my issue on the xz repo bothered you, it wasn't the idea. i sincerely apologize to you (and understand if you don't unblock me).

[Rudxain]

I don't even know Mr. Lasse's personality, but I can already imagine what he was thinking:

Damn it, another one of those "Rustaceans". This spam is never-ending 🤦

[porky11]

@jmwielandt So you are a rust fanatic, and don't even know about build scripts?
Build scripts might also be very malicious, I guess.