Re: [HACKERS] GnuTLS support

On Thu, Feb 1, 2018 at 5:08 AM, Christoph Berg <myon(at)debian(dot)org> wrote:
> Re: Peter Eisentraut 2018-01-03 <99680dba-cf63-8151-1de2-46ca93897e56(at)2ndquadrant(dot)com>
>> One scenario is that if GnuTLS goes in, it's quite plausible that the
>> PG11 packages for Debian and Ubuntu will use it by default. But if it
>> doesn't support tls-server-endpoint, then a JDBC client (assuming
>> channel binding support is added) can't connect to such a server with
>> SCRAM authentication over SSL (which we hope will be a popular
>> configuration), unless they manually disable channel binding altogether
>> using the new scramchannelbinding connection option. That would be a
>> very poor experience.
>
> GnuTLS support would mean that Debian could finally link psql against
> libreadline (instead of just LD_PRELOADing it at runtime) because
> there's not OpenSSL license conflict anymore. But I'm only going to do
> that switch if there's no visible incompatibilities for clients, and
> even any server-side GUC name changes would need a damn good
> justification because they make upgrades harder. The LD_PRELOAD hack
> in psql works, there's no pressing urgency to remove it.

Yeah. The original justification at top-of-thread for supporting
GnuTLS was licensing. I am not a lawyer and I don't have an opinion
on how much of a licensing problem there is around OpenSSL, but if
somebody things (as they evidently do, 'cuz this patch exists) that
there's a problem there and is willing to do the work to get it fixed,
I think that's great. Even the perception of a legal problem can
hinder adoption, and our goal is to get people to use PostgreSQL. Or
at least, I think that should be our goal.

I don't expect that to generate a lot of work for us because, just as
we insist that people who want obscure operating systems supported
should help by arranging for buildfarm members, so too we should
insist as part of supporting GnuTLS that someone provide buildfarm
members for it. If those buildfarm members break and don't get fixed,
then we'll have to consider removing GnuTLS support. Of course, this
arrangement doesn't guarantee that it's going to be zero work for us,
just as people who primarily work on UNIX-like systems still have to
worry somewhat about Microsoft Windows. But it keeps the effort
pretty manageable. I think that's likely to be even more true for
GnuTLS, because there's a huge amount of code that can depend on
pointer width and endian-ness, whereas it seems unlikely that anything
other than SSL patches will need to care about GnuTLS. And there's
just not that many of those. The biggest risk seems to be that new
SSL-related features someone wants to add in the future would need to
be made to work with every SSL implementation, and I think that could
indeed be an annoyance, but I don't think we'll really know how much
of an annoyance until we try it. It's not like we can't rip support
out again if it proves to be a huge problem (in contrast to a feature
like multixacts or partitioning, which you can't remove without
breaking upgrades).

Also, I have to admit that my experiences with OpenSSL have been
mostly negative. The basic stuff works and is clearly documented, but
more complicated things, at least at the time I looked at it, were not
clearly documented or not documented at all, and I ended up reading
uncommented code to try to figure out how it was supposed to work. I
don't think it's a bad thing if we do our bit to contribute to a
little competition among implementations. I'm not sure that gcc was
worrying too much about their error message quality until llvm came
along, but I bet they're thinking about it now.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company