Those blobs were not in systemd,
that was not my point, nevertheless putting it this way: nobody knows.
For the example about compression methods you could generate your binary using a piece of
code, that can be reviewed (maybe using a fixed seed as inspired by
https://git.rootprojects.org/root/xz/commit/6e636819e8f070330d835fce46289...
btw!). If you want to test systemd against a broken journal then can't you commit a
valid journal (that can be reviewed) and some code that generates a corrupted one?
The obfuscated C code is a different problem - at least it can be reviewed/audited and the
maintainer can ask to simplify it.
My point is that everything should get reviewed before merge. I would hope that, as a
lesson learnt from this attack, no unreviewed "corrupted binary" exist anymore
in any project, since really, nobody knows what they actually contain.