Panu Matilainen <pmati...@redhat.com> writes: > 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.
Indeed. The question here for me is whether RPM needs signature
verification in the bootstrap setting at all. Because I could imagine
bootstrapping as a two-step process, where first all the source RPMs are
verified by the host system's RPM, and the "bootstrap RPM" just skips
over the verification process. But, I don't know how bootstrapping is
done in the RPM world.
>> 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.
>> 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.
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
signature.asc
Description: PGP signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
