On Thu, Oct 13, 2022 at 11:38 AM Demi Marie Obenour <demiobenour@xxxxxxxxx> wrote: > > 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. But there are more implementations of the latter. I'll take that. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
