On 10/13/22 04:23, Panu Matilainen wrote: > On 10/13/22 10:53, Neal Gompa wrote: >> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: >>> >>> 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. >>> >> >> The real problem is that all other OpenPGP implementations died out >> because of GnuPG. And then GnuPG made the choice to force an >> inter-process model. >> >> At work, I deal with this on Debian systems, which do indeed use GnuPG >> for this. It creates a lot of problems, especially for building images >> and dealing with chroots, which is why in the context of RPM PGP >> upstream, I never pushed to consider it. >> >> The most serious problems with PackageKit memory leaks and hangs are >> actually caused by GnuPG, since DNF uses it for some GPG stuff because >> there's no API for using RPM's PGP capabilities. There's no fix unless >> the RPM and DNF teams agree on an API and build it out so that libdnf >> and librepo no longer need to use GnuPG through gpgme anymore. >> >> This is also the underlying reason why Red Hat has resisted >> implementing signed repository metadata and enforcing it by default. >> Of course this is a bit of a catch-22 as well, as there's no >> motivation to find a solution because neither Fedora nor RHEL offer >> signed repository metadata despite repeated calls for it over the past >> decade. >> >> Now, don't get me wrong: I'm personally extremely unhappy about having >> to depend on the Sequoia stack for RPM PGP. I have a strong distaste >> for the Rust community ecosystem these days, and I don't love the idea >> of having to have LLVM in the core bootstrap chain (hopefully gcc-rs >> will be in place soon enough!). But we literally don't have any other >> options. GnuPG/GPGME is out of the question for the reasons Panu and I >> stated, and NeoPG died several years ago. There are no C/C++ libraries >> for OpenPGP verification. > > There's RNP (in C++, used by Thunderbird at least), but alas that > doesn't expose the digest-in-progress either. So at least in it's > current form, it's not an option for rpm. Also, the API appears to have > all manner of quirks and gotchas that aren't welcome in a > security-critical piece. > > As for bootstrap, there will always (have to) be a way to build rpm > without depending on Rust. Even if that meant no signature verification > support in such a configuration. RPM could keep its own internal parser for bootstrap only. Bootstrap does not need support for revocation, etc. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
