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