I'd like to propose to replace RPM's built-in PGP support with Sequoia.
Sequoia is an OpenPGP implementation written in Rust.  We have released
Sequoia 1.5 earlier this week, which is the first version released under
the LGPL2+.

Our low-level crate, sequoia-openpgp, features an unopinionated
interface that offers mechanisms without imposing policy upon the
downstream user.  Despite its low-level nature, our experience is that
integration code is typically smaller than code interfacing with
e.g. GPGME, which is supposed to be a high-level interface.

I have dug around in the bug tracker, and I think I have identified some
areas of concern with respect to RPM's OpenPGP support: Correctness,
portability, and license compatibility.

First, I think replacing RPM's point solution with a general purpose
implementation will improve correctness.  Robust signature verification
requires canonicalization of the issuing certificate, which is tricky
[0], [1], [2].  Further, RPM shouldn't be burdened with maintaining
their own point solution, which will require constant maintenance to
keep up with evolving standards and algorithms.

0: https://access.redhat.com/security/cve/cve-2021-3521
1: https://github.com/rpm-software-management/rpm/issues/1598
2: https://github.com/rpm-software-management/rpm/issues/1306

Second, Rust has been criticized for being not too portable [3].  While
there is some truth to that, at least today, there is ongoing work to
add a GCC backend to the Rust compiler [4], and to write a Rust frontend
for GCC [5].  The former work will likely address the issue short-term
to mid-term, while the latter will imho be a mid-term to long-term
solution.  In any case, the situation is only going to improve over

4: https://github.com/rust-lang/rustc_codegen_gcc
5: https://github.com/Rust-GCC/gccrs

For RPM, I'd suggest to keep the current implementation as a fallback
for platforms that cannot or prefer not to use a Rust-based PGP

Finally, regarding the license incompatibility [6], we're happy to
report that we have switched to the LGPL2+ fixing this issue.


I have also skimmed RPM's code.  From what I can tell, the relevant code
is in rpmio/{rpmpgp,rpmkeyring,digest}*, the public API uses the "rpm"
prefix, "pgp"-prefixed functions and types are hardly used outside of
the PGP implementation.

Looking at the task for roughly an hour or so (so, take it with a grain
of salt...), my strategy would be to decouple the current implementation
by clearly defining the public API, then provide a drop-in replacement
for that API that can be enabled at compile-time.

Does that sound reasonable?  Do you have questions or remarks?  I'm
happy to get the discussion rolling :)


Attachment: signature.asc
Description: PGP signature

Rpm-maint mailing list

Reply via email to