[Rpm-maint] Porting RPM to Sequoia PGP

[Panu Matilainen]

On 10/21/21 18:12, Justus Winter wrote:
> Hello,
> 
> 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
> time.
> 
> 3: https://github.com/rpm-software-management/rpm/issues/1306#issuecomment-751311089
> 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
> implementation.
> 
> Finally, regarding the license incompatibility [6], we're happy to
> report that we have switched to the LGPL2+ fixing this issue.
> 
> 6: https://github.com/rpm-software-management/rpm/issues/1306#issuecomment-751381721

The missing big item on this laundry-list is bootstrapping. Rpm is 
needed very early on when bootstrapping a distro and people do not want 
to deal with something like Rust in there. Gcc learning Rust would/will 
change that somewhat of course, but gcc is not the only compiler used to 
build rpm.

> 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.

The users of those pgp* functions are not many there are a handful so it 
can't be all just thrown away at once. Unfortunately.

> 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? 

Decoupling the implementation from the API would be beneficial to rpm in 
any case because
a) it'd also enable implementing support for other libraries as well (eg 
RNP which is much closer in language family) and as long as the internal 
implementation is preserved, bootstrapping with minimal dependencies.
b) doing so tends to have a positive impact on codebase
c) having someone experienced with OpenPGP do it, the resulting API may 
even make some sense...

So while I'm not at all eager to gain a Rust dependency and there'll be 
somewhat more (not less) code to maintain, but as per the plan above I 
think this sounds like a net positive for us. Always assuming somebody 
is willing to do the work that is.

> Do you have questions or remarks?  I'm happy to get the discussion
> rolling :)
As a someone who's been living under a crate when it comes to Rust... I 
can see from the Sequoia docs that FFI is used for calling from other 
languages and there's a separate C library for this. How's the API 
coverage (just curious) and more importantly, stability? And if this is 
a shared library then the question extends to ABI stability as well.

	- Panu -