Test isolation is still assuming the attack comes in the test phase. The attack can come in the `make`, or in the `make install` too. That's why the idea of other techniques being discussed are still valid, but perhaps not abstracted out enough for a wider defense.
However, the test isolation concept is a good defense. Once the build artifacts is generated, the integrity of the build artifacts must be ensured during any post build phase. Some tests do expect to be executed right after the build, when the build artifacts are still in specific directories within the source root, so that's why I was thinking of something more like at the file system level (e.g., a snapshot that it is then restored, or something like that).
On 3/31/24 23:20, Adam Williamson wrote:
On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:Adam, Is there a way already to achieve test isolation during the rpm build?Nothing systematic that I'm aware of, no. It would be tricky because there is no one universal Standard Test System (not even within a single language ecosystem, let alone across all of them). Currently you'd have to design something unique, if you wanted to implement this for your package. I suppose one approach would be to split the sources-required-for-build and the test suite into Source0 and Source1 (respectively) and only extract Source0 during %prep. Don't extract Source1 until %check (i.e. after %build and %install are already done). I'm just spitballing, though, haven't checked if this is really practical. Of course, another approach is to really do what Kevin suggests and not ship the test suite in the package source at all, but instead run the tests via Fedora CI, and configure the package to be gated on that CI check (so it wouldn't go to stable without the tests passing). But that's rather a different approach (and would still require 'custom' work to cut the tests out of the source, or at least delete them before running the build). And I still think at this point we are falling into the trap of thinking too specifically about an attack vector which just *happens* to be the one chosen in *this specific instance*. It's still worthwhile, on some level, for someone to think about that kind of hardening, of course. I am just not convinced it is the most useful thing Fedora could be doing right now in the general area of "supply chain hardening".
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
