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/6e636819e8f070330d835fce46289a3ff72a7b89 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
<<attachment: smime.p7s>>
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
