All of the data transformation (codecs, compression etc.) libraries should be in WUFFS. That's exactly what it's for, and unlike the C++ this was written in, or indeed Rust, it's able to provide real compile time safety guarantees for the very affordable price of loss of generality (that is, you can't use WUFFS to write your video game, web browser, word processor, operating system or whatever)

For example in C++ array[index] has Undefined Behaviour on a bounds miss. Rust's array[index] will panic at runtime on a bounds miss, at least we know what will happen but what happens isn't great... WUFFS array[index] will not compile if it could incur a bounds miss. Show the compiler why index will be a value that's always in-bounds when the index occurs.

It appears that XZ actually is in WUFFS!

https://github.com/google/wuffs/tree/main/std/xz

Yeah, it's just a coincidence (†), but I started working on Wuffs' LZMA and XZ decoders last December. It works well enough to decode the Linux source code tarball correctly (producing the same output as /usr/bin/xz).

    $ git clone --quiet --depth=1 https://github.com/google/wuffs.git
    $ gcc -O3 wuffs/example/mzcat/mzcat.c -o my-mzcat
    $ ./my-mzcat     < linux-6.8.2.tar.xz | sha256sum 
    d53c712611ea6cb5acaf6627a84d5226692ae90ce41ee599fcc3203e7f8aa359  -
    $ /usr/bin/xz -d < linux-6.8.2.tar.xz | sha256sum 
    d53c712611ea6cb5acaf6627a84d5226692ae90ce41ee599fcc3203e7f8aa359  -

(†) Also, I'm not "Jia Tan"! You're just going to have to trust me on both of those claims. :-/

> Also, I'm not "Jia Tan"! You're just going to have to trust me on both of those claims. :-/

No need to trust – it's actually easily verified :) Your activity pattern (blue) is entirely different than jia tan's (orange): https://i.k8r.eu/vRRvVQ.png

(Each day is a row, each column is an hour in UTC. A pixel is filled if a user made a commit, wrote a comment, etc during that hour)

So, if one person were to login to one account for a certain time, and then switch accounts for a few hours... Hmmm :o)

Then they'd still need to sleep at some time ;)

Complete a bunch of activities over a duration of 8 hours. Have a piece of software that relays all of those activities at a slower rate over the span of the next 24 hours.

I've already written about just that over in the xz thread a few days ago: https://news.ycombinator.com/item?id=39893388

> Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies.

> You'd basically have to have a team of devs working at really odd times and a queuing system that automatically queues all emails, github interactions, commits, etc to dispatch them at correctly distributed timestamps.

> And you'd need a source pattern to base your distribution on, which is hard to correctly model as well.

Note that while what you suggest is possible, it'd become visible if you look at issues, questions, emails, etc sent to the project author and how long it took for the author to reply to them. If you plot this reply delay by the hour of day that the message arrived, a pattern emerges.

The xz backdoor was not about safety. Nor was it really about compilation or compile time checks -- they slipped an extra object file to the linker.

You're right that Wuffs' memory-safety isn't relevant for this attack.

Still, Wuffs doesn't use autotools, and if you're pulling the library from the https://github.com/google/wuffs-mirror-release-c repository then that repo doesn't even contain any binary-data test files.

Brotli:11 gets within 0.6 % of LZMA density but decodes 3–5x faster.