> On 16 Dec 2020, at 17:26, Stephen Frost <sfr...@snowman.net> wrote: > > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: >> On Tue, Dec 15, 2020 at 02:09:09PM -0500, Stephen Frost wrote: >>> Yeah, looking at what's been done there seems like the right approach to >>> me as well, ideally we'd have one set of APIs that'll support all these >>> use cases (not unlike what curl does..). >> >> Ooh... This is interesting. What did curl do wrong here? It is >> always good to hear from such past experiences. > > Not sure that came across very well- curl did something right in terms > of their vTLS layer which allows for building curl with a number of > different SSL/TLS libraries without the core code having to know about > all the differences.
The vtls layer in libcurl is actually quite similar to what we have in libpq with be-secure.c and be-secure-*.c for TLS and with what Michael has been doing lately with cryptohash. In vtls library contexts are abstracted to the core code, with implementations supplying a struct with a set of function pointers implementing functionality (this difference is due to libcurl supporting multiple TLS libraries compiled at the same time, something postgres IMO shouldn't do). We do give implementations a bit more leeway with how feature complete they must be, mainly due to the wide variety of libraries supported (from OpenSSL to IBM GSKit and most ones in between). While basic it has served us quite well and we have had first time contributors successfully come with a new TLS library as a patch. What we have so far in the tree (an abstract *reasonably generic* API hiding all library context interactions) makes implementing support for a new TLS library less daunting as no core code needs to be touched really. Having kicked the tyres on this a fair bit I really think we should maintain that separation, it's complicated enough as it is given just how much code needs to be written. cheers ./daniel