Ken Hornstein <kenh(_at_)pobox(_dot_)com> 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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers