[Rpm-maint] Porting RPM to Sequoia PGP

[Justus Winter]

Panu Matilainen <pmatilai at redhat.com> writes:

> 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 :)

Yeah, I can see that now :)

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

Yes.  This is the point solution for the pEp engine, which is our 

> Just kinda worried about this requirement to sync with an external 
> project in a language none of us knows anything about.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 519 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20211101/5f551144/attachment.asc>