Re: [Nmh-workers] Starting the final call for features for 1.7

[Tom Lane]

Ken Hornstein <address@hidden> 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