Dne 30. 03. 24 v 22:14 Zbigniew Jędrzejewski-Szmek napsal(a):
On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote:Zbigniew Jędrzejewski-Szmek wrote:I think there's some useful points here, but this would need to be qualified and/or made more flexible to be applied. For example, systemd repo has fuzzer case files, which are a mix of text, mojibake, and actual binary protocol samples. For example, dhcp input packets, dns packets. There are also other ~binary test files, for example corrupted journal files. The tests are defined via meson.build, so those files are "referred to in the build tools", and would not be allowed by the above definition. But if we dropped those, we'd lose very valuable testing of the codebase.On the other hand, "test files" are exactly how the payload of this backdoor was disguised! So a policy that deletes all binary test files or even all test files altogether would have prevented this backdoor.Well, if we made a rule that "binary" files are not allowed
I think that we should really not talk about binary files and talk e.g. about pre-generated files instead. This chapter in guidelines is already trying to cover this:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#pregenerated-codeBut maybe we should rewrite the "No inclusion of pre-built binaries or libraries" chapter above to be more generic.
Vít
, the attacker would e.g. commit some minified bash that generates whatever output is needed. The real problem was the complex and unreadable build system that made it easy to embed _multiple_ obfuscated components for the attack. To trust code, it needs to be reviewed. And if the code is reviewed, and the build system is sane, it's usually fairly easy to say "oh, this is a sample and the only way it's used is as input to a fuzzer binary", or "this sample is used as input to a unit test", etc. A policy against binary files would hinder this particular implementation of the attack, but the attacker had full control of the repo, so they would be able to arrange the attack around such a policy without too much trouble. Zbyszek -- _______________________________________________ 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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
