On Sat, Mar 30, 2024 at 08:51:03PM +0100, Dmitry Belyavskiy wrote: > Dear Kevin, > > On Sat, Mar 30, 2024 at 8:12 PM Kevin Kofler via devel < > devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Miroslav Suchý wrote: > > > 4) Fetch build artifacts before executing tests > > > > > > https://github.com/rpm-software-management/mock/issues/1352 > > > > Or better: Do not execute tests to begin with! rm -rf test in %prep and > > NEVER run tests during builds. Even when the tests are all legitimate, all > > it does is slow down the build (e.g., compare glibc build times without > > and > > with tests) and every so often break it because the test, not the > > software, > > is broken. And a claimed "test file" is what allowed the payload to be > > snuck > > in here. > > > > It's a terrible idea. Sorry. Yes, it's a terrible idea. Also it doesn't solve anything. Because if you can inject code into the tarball to inject code into the tests, then you can also inject code into the output binaries, but you can also inject it into configuration tests. Our official policy is to run tests during build, because that helps to catch many silly mistakes and miscompilations. If we stop doing that, we'll close one avanue of attack, leaving a few ~equivalent avanues of attack open which share the characteristic that if one is accessible to the attacker, most likely all are. > > Unit tests are something for upstream developers. They should NEVER be run > > in a distribution build. > > > > The first thesis is completely wrong. Having, say, a 30+ downstream patches > and declining to run upstream tests is the most effective way to break a > gazillion use-cases. > > But the fuzzing tests look quite dangerous to me here and now. No one can > review a corpse of binary files :( Meh, the primary purpose of such tests is to stress the code under sanitizers. Those test cases are not added randomly, they are added by upstream developers when they solve an issue. To construct an attack, somebody would need to construct a sample that does not trigger any failures with sanitizers, but actually causes a misbehaviour allowing taking control of execution. Then this control would need to be used to modify the build artifacts (because presumably doing something in the sandboxed build environment is not particularly interesting), and _then_ the attacker would need to convince the maintainers to commit the sample. This is all theoretically possible, but pretty hard to pull off. Again, I think that the important aspect is reviewability, not some simple rule about the format of files. 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
