Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What I don't want to end up with is an unholy mixture of both approaches.
>> Therefore, if we are going to use method #2, we must be certain that
>> the basic "ssl_" parameters are supported by every implementation,
>> to the point where we'd reject an implementation that didn't have one.
>> I can see that we'd reject an implementation lacking CRL support
>> for instance, but I'm less clear that lack of configurable DH parameters
>> should be a disqualifying feature omission. I'm prepared to be educated
>> either way, but that's the core question here.
> So in this particular case, does it mean that to do #2, we sould actually
> have an openssl_dh_params_file and a gnutls_dh_params_file, but only one at
> any given time?
That's where I think we end up if we don't want to assume that every
implementation has dh_params_file support.
> Thinking on that there is also the case of file formats. What if one
> provider takes a cert file, but not in the same format -- should that still
> be ssl_cert_file, or should it be a different parameter name? Given that
> you can't use it to point to the same file.
Meh --- as long as any given build supports only one SSL implementation,
I think insisting on that would be overly pedantic. Seems like as long
as what you put into the config file is the same, it's okay to consider
a given parameter to be shared by two different implementations.
Although these corner cases are starting to make me feel like changing
my original vote. Maybe we should forget the prefixes, in particular
renaming gnutls_priorities to ssl_priorities, and just accept the need
to document some parameters as only relevant to some implementations.
That certainly requires less betting on our ability to predict the
future.
regards, tom lane