[Rpm-maint] Porting RPM to Sequoia PGP

[Panu Matilainen]

On 10/25/21 18:06, Justus Winter wrote:
> Panu Matilainen <pmatilai at redhat.com> writes:
>>> 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.
> 
> Sure, I didn't meant to throw them out, but just review the call sites
> and maybe make it part of the public API.

Yup, understood. *I* would like to throw them out though :)

> 
>>> 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.
> 
> Great.  I'll give it a try and will likely come back with questions in
> the process.
> 
>>> 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.
> 
> That is a good question.  When we started with Sequoia, we imagined
> having a general-purpose C API.  We started to build one, driven by the
> needs of our companies C library.  However, it became increasingly clear
> that a) this is a lot of work, b) the general-purpose interface was
> quite brittle, and most importantly c) it resulted in a lot of code on
> the consumer side that would have been much more concise and robust if
> it would have been written in Rust using the native interface.
> 
> Hence, our new strategy is to create point solutions in Rust that expose
> the exact handful of functions that a project requires.  We have done
> that for our companies library, and it has greatly improved the quality
> of the code.  You can see examples of such point solutions here:
> 
> https://gitlab.com/teythoon/sequoia-nlnet-encrypt-confirmation
> https://gitlab.com/wiktor/anonaddy-sequoia
> 
> For RPM, this point solution would implement the public functions from
> rpmio/{rpmpgp,rpmkeyring,digest}*.  This API is internal to RPM, so any
> changes to the C side would also be made to the Rust side.  Hopefully,
> the interface will be small and changes seldom.

So... what does this mean in practical terms? Somebody maintains this 
piece of Rust code externally somewhere? And a versioned shared library 
+ header file is what you get when it's built? Do you have an example of 
such a point solution for a C/C++ project?

Just kinda worried about this requirement to sync with an external 
project in a language none of us knows anything about.

	- Panu -

> Sequoia's API is fixed during the 1.x release cycle.  We released 1.0 in
> December 2020 after spending a year writing documentation for the
> interface and honing it.  We're happy to report that no major issues
> have popped up so far.  We're collecting interface warts in our bug
> tracker, but even if we eventually go to 2.0 to be able to fix the
> issues (thus breaking the API), I think most of the downstream code will
> continue to work as-is, at worst requiring small fixes.
> 
> 2.0 API bugs: https://gitlab.com/sequoia-pgp/sequoia/-/milestones/3
> 
> Justus
>