On Mon, Apr 01, 2024 at 02:23:19PM -0000, François Rigault wrote:
> 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.
Or (if production of the binary is expensive or can be fiddly), commit
the binary but include a script to generate it that can be run by others
to check that the included binary is legit.
Call it "Reproducible Tests" to go along with reproducible builds.
Cryptography has the same concept now, learning from the Dual EC DBRG
backdoor:
https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
So "nothing-up-my-sleeve scripts" could be another moniker.
--
Scott Schmit