On 10/13/22 08:14, Neal Gompa wrote: > On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen <pmatilai@xxxxxxxxxx> 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. >> > > Huh, I'd forgotten about RNP. It seems it now has an OpenSSL backend > and at least the verification API (which is what RPM would use) seems > to be getting love lately. Insofar as quirks and gotchas, I'm not a > great judge of that at the moment, but I don't think it could be worse > than what we have with GnuPG. > > The missing "digest-in-progress" thing is an issue, I guess. Have we > raised the issue with them about it? > >> 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. >> > > Eck. What about the x509 based stuff we were talking about last year? > All the crypto backends RPM supports now support that stuff out of the > box. > > Embedded x509 signatures (certs) to replace GPG signatures could work > as an alternative. OpenPGP is not great, but X.509 is an absolute disaster in comparison. -- 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
