On Fri, 2022-10-14 at 10:14 +0300, Panu Matilainen wrote: > On 10/13/22 15: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? > > No, because beneath the surface it didn't seem all that appetizing > afterall. See > https://sequoia-pgp.org/blog/2021/05/06/202105-thunderbird-rnp-and-the-importance-of-a-good-api/ > for an example (even bearing in mind that a blog post from a competitor > may be necessarily a little opionated), but its reputation/security > record doesn't seem that great. > > It's something to keep an eye on of course, it would be good to have > alternatives available. > > > > > > 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. > > x509 seems to be loathed even more than PGP, so it doesn't seem that > appetizing either. > > If someone with known crypto-clue would send patches they would be > looked at, *I* have no prejudice about x509 because I also have no clue > about it. Ditto for Signify, which often gets brought up in these > discussions. > > And yet, that all is largely irrelevant for the subject at hand: no > matter what, rpm will need OpenPGP support for years to come because > existing content will need to remain usable for a long, long time. Just to throw a little fire in here :-D We are starting to look at what it means to sign content with PQC algorithms. One of the factors (not the only one) is the recent CNSA 2.0 recommendations: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF One of the possible impediments, besides finding a decent implementation, zeroing in on the algorithm(s) to select and support, and a gazillion other small but critical details, is the format. At this time, as far as I know, there is no OpenPGP work of any kind on supporting PQC algorithms. Furthermore the way we use signatures in RPM really has no resemblance to the scenarios OpenPGP was built for. So we should consider whether moving to PQC will also mean moving off OpenPGP as our signature format and into something simpler. Panu, I will try to engage the RPM team once we have a settle a little more on the cryptography part. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
