[Rpm-maint] [rpm-software-management/rpm] Implement a way to ensure build artifacts integrity after generating, and during post-build phases like %check (Discussion #3009)

[Carlos R.F.]

After the build artifacts are created, it would be ideal to somehow make them immutable during the test  in the %check. The goal is to protect their integrity.

This idea came from the Fedora devel discussion about how to build defense mechanism against xz kind of backdoors.

Ideas of how to implement it:

Zbyszek:

> If we wanted to pursue that, I'd suggest the following:
> remount $RPM_BUILD_ROOT read-only for the %check phase
> (or maybe overmount it with a writable overlayfs that is thrown
> away after %check finishes, and warn if any modifications were made.)
> %check is executed after %install, so everything should be in place
> before %check, and %check may be skipped, so no modifications to
> installed files should be done in %check.
> 
> Considering possible implemention details, machinectl has 'bind' and
> 'bind --read-only' that might be useful here. But mock uses
> systemd-nspawn in a way that does register the container with machined.
> So maybe it'd be more reasonable to just execute a mount command directly
> from mock.
> 
> This is independent of the test system and does not require splitting
> of the test sources.

Neal Gompa:

> Another thing to consider is making RPM unshare each build phase like
> it can for scriptlets now at install time[1].
> 
> Sandboxing and limiting in rpmbuild itself like we can with rpm can
> also help with this. I believe moss[2]' boulder tool does this.
> 
> [1]: https://github.com/rpm-software-management/rpm/pull/2666
> [2]: https://github.com/serpent-os/moss/tree/main/boulder


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3009
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/3009 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240401/312c8d40/attachment.html>