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 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 :) Justus
signature.asc
Description: PGP signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
