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
smime.p7s
Description: S/MIME cryptographic signature
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
