>> - Some old, insecure (MD5/SHA1 based) signatures are
rejected (this is
>> in line with the stronger crypto settings proposed elsewhere for F38)
>
> Such a hardcoded restriction, without a way for the local administrator to
> allow the legacy signatures, is not acceptable.
Mind you, I don't exactly agree with this style of explicit disabling
either (see
https://lists.rpm.org/pipermail/rpm-maint/2021-October/018344.html and
onwards). But. I doubt many people realize just how thin the ice is
(and has always been) with the existing parser. I consider this step a
matter of survival, and ultimately some legacy content becoming harder
to use is an acceptable tradeoff for *that*.
I don't know how deep this all is wired inside Sequoia, but I totally
agree (as you see in the thread linked above) that this should be
based on the system crypto policy. As explained in the change, nettle
(which doesn't support the system crypto policies AIUI) should be seen
as a temporary stepstone in Fedora, with a plan to switch to openssl
(which does) in the nearish future.
So technically this is a matter of "Sequoia should honor system crypto
policy", rpm is just a dumb API user here that sometimes get told
"nope" by the underlying libraries, whether due to crypto policy, FIPS
or whatever.
I opened [1] to track this issue.
It should be relatively straightforward to implement this. Sequoia
already has first class policy objects that are consulted on every
cryptograph operation [2]. What needs to be done is to read the
Fedora system policy and configure the rpm-sequoia's policy object [3]
appropriately.
:) Neal
[1]