Hi, On 09/04/2017 04:24 PM, Bruce Momjian wrote: > On Fri, Sep 1, 2017 at 12:09:35PM -0400, Robert Haas wrote: >> I think that what this shows is that the current set of GUCs is overly >> OpenSSL-centric. We created a set of GUCs that are actually specific >> to one particular implementation but named them as if they were >> generic. My idea about this would be to actually rename the existing >> GUCs to start with "openssl" rather than "ssl", and then add new GUCs >> as needed for other SSL implementations. >> >> Depending on what we think is best, GUCs for an SSL implementation >> other than the one against which we compiled can either not exist at >> all, or can exist but be limited to a single value (e.g. "none", as we >> currently do when the compile has no SSL support at all). Also, we >> could add a read-only GUC with a name like ssl_library that exposes >> the name of the underlying SSL implementation - none, openssl, gnutls, >> or whatever. >> >> I think if we go the route of insisting that every SSL implementation >> has to use the existing GUCs, we're just trying to shove a square peg >> into a round hole, and there's no real benefit for users. If the >> string that has to be stuffed into ssl_ciphers differs based on which >> library was chosen at compile time, then you can't have a uniform >> default configuration for all libraries anyway. I think it'll be >> easier to explain and document this if there's separate documentation >> for openssl_ciphers, gnutls_ciphers, etc. rather than one giant >> documentation section that tries to explain every implementation >> separately. > > I am worried about having 3x version of TLS controls in > postgresql.conf, and only one set being active. Perhaps we need to > break out the TLS config to separate files or something. Anyway, this > needs more thought. >
Well, people won't be able to set the inactive options, just like you can't set ssl=on when you build without OpenSSL support. But perhaps we could simply not include the inactive options into the config file, no? I don't see how breaking the TLS config into separate files improves the situation - instead of dealing with GUCs in a single file you'll be dealing with the same GUCs in multiple files. No? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers