Peter Eisentraut <peter.eisentr...@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