Closing in favor of a more generic #3050
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065857806
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3010 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#event-12533384975
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is not about "preventing XZ", it's just somewhat inspired by it.
I really don't know why multiple people are arguing against rpm looking to do
some extra packaging hygiene enforcement here. In a similar vein, rpm would
prefer an unwritable build directory during %install.
Hashing the
Yes, this approach will never be complete. Something like the proposed feature
is only a building block. For the other stages, there could also be the
requirement to not modify files that have been available already. IMHO, other
attack vectors should be addressed with other tools.
What data
There are simpler ways to ensure that `%check` stage does not affect files in
the build directory. E.g. we could use an overlayed filesystem (overlayfs, aufs
etc.) to mount an empty directory on top of the build directory before
executing `%check` but use the original build directory for
I understand the difference between %build and %check, as well as the problem
of this could be worked around by future actors. I would still like to
understand the potential as a building blocks for hardening.
Do you see a path for a hashing-like validation in the %check phase that could
be
This issue shows misunderstanding of how the xz backdoor was intended to work.
Although its payload was hidden in the test files, it was extracted [when
running the `./configure` script][cox] that happens at the `%build` stage. If
you run tests on read only filesystem or even disable them, that
Having a separate short-circuit for check is fine, but it's NOT the same
benefit! I get that you look at the world through mock lenses, but not
everybody does :smile:
--
Reply to this email directly or view it on GitHub:
I opened https://github.com/rpm-software-management/rpm/issues/3015, which I
believe will be much easier to implement. And will gain the same benefit.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2035392608
You are
I opened this ticket from the discussion specifically because it's such a
no-brainer when you see it: "tests should not be able to affect built
binaries". How feasible it is in practise is another story, but it's worth at
least investigating.
--
Reply to this email directly or view it on
An idea was floated on fedora-devel to remove tests from packages altogether. I
empathetically disagree with that, but maybe it'd be useful to "sandbox" the
tests a bit. The test code is often of lesser quality and less reviewed.
The basic idea is to make sure that the `%check` section
There's not much you can do against a malicious upstream.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2031325567
You are receiving this because you are subscribed to this thread.
Message ID:
On the heels of the xz incident, one of the ideas (from @keszybz it seems) to
harden against malicious tests is to make buildroot readonly during %check.
Picked from https://github.com/rpm-software-management/rpm/discussions/3009 as
a clear actionable item.
--
Reply to this email directly or
13 matches
Mail list logo
