Re: Three steps we could take to make supply chain attacks a bit harder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux