On 10/13/22 07:18, Kevin Kofler via devel wrote:
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.
Why are you using a new library written in Rust? Can you not use one of the
existing mature C implementations of OpenPGP? gpgme maybe?
Had there been such an option, we would've switched over years ago.
Gpgme is based around calling and communicating with an external gpg
process, which is a setup you do NOT want in the rpm context where
chroots come and go etc. Also, rpm requires access to the "low-level"
digests-in-progress because it calculates multiple things on a single read.
At this point the change is mostly invisible in normal daily use.
Not really, because it makes some packages uninstallable.
Not uninstallable. You can use --nosignature, or resign such packages
with something stronger. Which one is the better course depends on the
situation of course.
- 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.
- Panu -
_______________________________________________
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
