Ken Hornstein <[email protected]> writes: >> Idly, http://www.libressl.org/ is one alternative, aiming to improve the code >> quality amongst other things. It includes a new libtls "designed to >> make it easier to write foolproof applications" as well as "libssl: a >> TLS library, backwards-compatible with OpenSSL".
> Well, I can tell you that's how _I_ want to spend my free time: porting > our code to OTHER TLS IMPLEMENTATIONS! :-) It's worse than that: people will expect you to operate with either one, but LibreSSL's "backwards compatible" wrapper is only mostly so. Postgres had to give up depending on OPENSSL_VERSION_NUMBER to make it work: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5c6df67e0c961f68e73e7c1e6312211ed59da00a Somebody will need to test against old openssl, new openssl, *and* libressl before you can be confident that you won't be getting complaints around this area. (No, I'm not volunteering.) > In seriousness ... this is a tough one. I have zero love for the OpenSSL > API (I wish someone would sit down and write how they expect memory > management to work), but as far as I can tell it is by far the most > popular TLS implementation out there; you're guaranteed to find either > it shipped with the operating system or an available package of it. Yeah, exactly --- you will find *some* flavor of that API on just about any platform. Walking away is not a feasible option, despite the fragmentation :-( regards, tom lane _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
