Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 1/17/18 12:39, Tom Lane wrote:
>> I don't know too much about the internals here, so looking at your
>> list, I wonder whether "ssl_dh_params_file" ought to be treated as
>> implementation-specific too. The other four files seem essential
>> to any feature-complete implementation, but is that one?
> The proposed GnuTLS patch does make use of ssl_dh_params_file.
Right, but what happens if say macTLS doesn't?
There are basically two approaches we can take here:
1. All the relevant parameters are named "ssl_something", and we have
to flag in the documentation any that are supported only by some
implementations.
2. Parameters that might be supported only by some implementations
are named with implementation-specific names, and we have to accept
that there might sometimes be both "foossl_xyz" and "barssl_xyz".
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.
regards, tom lane
