[Rpm-maint] Porting RPM to Sequoia PGP

[Justus Winter]

Justus Winter <justus at sequoia-pgp.org> writes:

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

My apologies...

Yes.  This is the point solution for the pEp engine, which is our
companies high-level key management library:

https://gitea.pep.foundation/neal/pEpEngineSequoiaBackend/src/branch/main

It builds a shared library that is linked to the main library.

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

I understand.

Justus
-------------- 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/9beb11eb/attachment-0001.asc>