[Rpm-maint] [rpm-software-management/rpm] OpenPGP Backend based on Sequoia (Issue #1978)

[nwalfield]

Based on #1935, I've created an experimental OpenPGP backend based on [Sequoia](https://sequoia-pgp.org/).

Sequoia is released under the terms of the [LGPL2+](https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/LICENSE.txt). [Sequoia is in Fedora](https://packages.fedoraproject.org/pkgs/rust-sequoia-openpgp/rust-sequoia-openpgp-devel/). Sequoia's default cryptographic backend is [Nettle](http://www.lysator.liu.se/~nisse/nettle/), which is one of the cryptographic libraries that RHEL supports.

For this port, I took the following approach: reimplement the existing OpenPGP interface in terms of Sequoia using [a Rust shim](https://gitlab.com/sequoia-pgp/rpm-sequoia). To make life easier, I made pgpDigParams opaque to rpm. To accomplish this, I had to add [a few accessor functions](https://github.com/nwalfield/rpm/blob/cae94d7/include/rpm/rpmpgp.h#L1122-L1209).

The port takes advantage of Sequoia's machinery to canonicalize OpenPGP certificates. This is extremely complicated and accounts for nearly a fifth of Sequoia's code. The port is also [careful to check the validity of signatures](https://gitlab.com/sequoia-pgp/rpm-sequoia/-/blob/main/src/lib.rs#L431).

Currently, the port is using Sequoia's [null policy](https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.NullPolicy.html), which is not advisable. But, Sequoia's [Standard Policy](https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html) is stricter than what rpm currently appears to implement. If you decide that Sequoia is a reasonable way to go, we should discuss the right approach.

The code passes all tests except test 266. Test 266 checks that a certificate with a subkey that has no binding signature is rejected. (In particular, rpmchecksig.c:doImport calls rpmts.c:rpmtsImportPubkey, which calls rpmkeyring.c:rpmPubkeyNew, which calls rpmpgp.c:pgpPrtParams, which fails if a subkey is missing a binding signature.) This behavior of rejecting a certificate if there is an invalid component does not match the behavior of other OpenPGP implementations that I'm familiar with. Instead, invalid components are normally just ignored. This enables a degree of future compatibility.

I've written up [build instructions](https://gitlab.com/sequoia-pgp/rpm-sequoia#building) to try the port.

After spending some time looking at the code, I've come to the conclusion that the current API is not ideal. One thing that I don't like is that the pgpDigGetParams can encapsulate either a certificate, a subkey, or a signature. I'd advise to switch to a new API, however, this might not be so easy given that the OpenPGP functionality is part of librpm's public API. An alternative approach is to add a second API, use it, recommend its use, and deprecate the existing API.

I look forward to your feedback.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1978
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/1978 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220328/39ea5c8e/attachment.html>