On Thu, Feb 1, 2018 at 5:08 AM, Christoph Berg <m...@debian.org> wrote: > Re: Peter Eisentraut 2018-01-03 > <99680dba-cf63-8151-1de2-46ca93897...@2ndquadrant.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
