> 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. -- _______________________________________________ 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
