Re: [HACKERS] GnuTLS support

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andreas Karlsson <andreas(at)proxel(dot)se>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] GnuTLS support
Date: 2018-01-26 00:56:52
Message-ID: 20180126005652.GB17847@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 19, 2018 at 01:55:30PM -0500, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 10:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Also, this isn't really a good argument against using uniform names
>> for parameters that every implementation is certain to have, like
>> ssl_key_file.
>
> Even then, it's not that hard to imagine minor variations between what
> different implementations will accept. The most obvious difference is
> probably that they might expect different file formats, but it's also
> possible that a Windows-specific implementation might allow omitting
> the file extension while some other implementation does not, for
> example. I agree that it would probably be fairly low-risk to use one
> parameter for the key file for every implementation, but I suggest
> that it would be cleaner and less prone to confusion if we enforce a
> full separation of parameters. That also spares us having to make a
> judgement call about which parameters have semantics close enough that
> we need not separate them.

Having to debate about the most correct default values for one common
parameter depending on N SSL implemententations will likely prove at the
end that the most correct answer is just to split all parameters from
the start. Some implementations are platform-specific, the format file
is one thing that matters. There are also other things like ssl_ciphers
which could depend on what kind of cipher types an SSL implementation is
able to support... Another thing is that we cannot be 100% sure that one
parameter can be set to say GUC_SIGHUP for an SSL implementation and
needs to have other modes with another implementations. Of course this
can be solved if some ifdefs, but splitting brings clarity.

At the end, I agree with the position of Robert to split everything and
rename the existing ssl_* parameters to openssl_* if v11 gains a new SSL
implementation.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Edmund Horner 2018-01-26 01:09:40 Re: PATCH: psql tab completion for SELECT
Previous Message Bruce Momjian 2018-01-26 00:55:46 Re: AS OF queries