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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
