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.
If there was *any other choice*, we would have taken it. Even
splitting out RPM's internal OpenPGP code into its own project for
someone to rework and upgrade would be an option if someone actually
wanted to. The reality is that nobody wants to work on that.
Yep. In case there's any doubt, I too would've much, MUCH, VERY MUCH
preferred a C (or even C++) library but in the ~15 years I've been on
the lookout, no viable and credible candidates have appeared.
Rpm will remain open to alternative backends, should such a thing
emerge, but I'm not holding my breath.
- Panu -
So here we are, in a subpar situation created by bad tools because
nobody cares enough about security anyway.
--
真実はいつも一つ！/ 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
_______________________________________________
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
