Yes, it’s quite the beast. To be clear, at this stage feedback on fundamental design is where this is at. Hopefully I’ll get some time in the near future to finish off some of the TODOs left laying around, add in OpenSSL support and generally come up with a method for testing this. There’s also a total lack of documentation update in this patch too.
Testing is non-trivial as some kind of soft PKCS#11 driver will be necessary and to make that part of the CI, perhaps it will need implementing also. I’m very hopeful that people have some good ideas here to avoid me having to generate them myself. Thanks, Chris. > On 10 Apr 2025, at 08:33, William Lallemand <wlallem...@haproxy.com> wrote: > > On Tue, Apr 08, 2025 at 05:09:23PM +0100, Christopher Staite wrote: >> Hi, >> >> Please see attached an early draft PKCS#11 module for consideration. I’ve >> tested this with the Google CloudHSM >> PKCS#11 module and it functions as one would expect. The key management is >> identical to that of using the latchset >> PKCS#11 provider/engine for OpenSSL >> (https://github.com/haproxy/wiki/wiki/OpenSSL-Providers-in-HAProxy#pkcs11-provider). >> >> Currently the patch has holes within it (mostly testing). But should be >> good for early feedback on the design and >> whether this is something that would be appropriate to merge in to HAProxy. >> >> The implementation currently only functions with BoringSSL and AWS-LC and is >> behind the build option USE_PKCS11=1. >> >> It would be fairly easy to extend the implementation to call the functions >> within OpenSSL to register a >> provider/engine and provide a unified interface. I’m not entirely sure, but >> I believe that the latchset >> implementation is blocking and therefore will stall the HAProxy event >> threads. >> >> Thanks, Chris. >> > > Hello Chistopher, > > Thanks for your contribution, this will take some time to review and test. > I'm currently busy with finishing things for > the 3.2 release and I'll come back to you after that. > > Regards, > > -- > William Lallemand
