> I guess this is twofold: First we assume they are the same when there really
> is no reason an attacker would do so. So we can end up with different
> signatures depending on the rpm version being used.
I don't see what there is to gain for an attacker in that situation. It's
pretty much by design that newer and older rpm's can see different signatures.
> Then there's this "the newer rpm could check this but we leave that to the
> older version that has less of a chance to figure things out". Not sure if
> this really is realistic this "use rpm V6 to check signatures and then hand
> the packages down to an older rpm version".
There's no scenario where v6 would be used to check for signatures and then
hand to v4. That compat stuff is about letting packages *signed* by rpm v6 be
verified by older versions, to the best of their abilities. Those abilities do
not include these newer signatures, whatever they are.
The policy stuff is something that could use some further elaboration in the
commit message actually. In the current implementation you can put 100
signatures in there, and somebody strips 99 of them out and nothing will
notice, but in the future, the user will be able to specify which signatures
and signature types are required in order to pass verification.
Just that the policy stuff is out of scope for this initial patch.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3439#issuecomment-2485953975
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/3439/[email protected]>
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
