A backdoor in xz

In my opinion, it's the opposite: non-corrupted files could be described using a custom human-readable assembly-like language which represents the primitives allowed in the compression format (something like "LITERAL 03 AA BB CC TREE ..."), while corrupted files could be crazy files found by users which happened to cause older versions of the software to misbehave, and which were added as a regression test.

> You can't reliably construct *those* with the built xz, because if the built xz is buggy it's going to generate a messed-up file [...] and you presumably want to detect cases where the compressor and decompressor are buggered-up in the same way

That is easy to avoid, you just need to add an "expected hash" to check that the compressor generated the correct data for the decompressor to test. But that doesn't help when you want to test that the decompressor remains compatible with data generated by *older* versions of the compressor (which the current code no longer generates), or even alternative compressor implementations. There's a lot of flexibility in compressor output, so it's not unusual for it to change.