On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > This looks to me like re-fighting the last war. Such a GUC has zero value > *unless* some situation exactly like the POODLE bug comes up again, and > the odds of that are not high.
I think it's pretty common for flaws to be discovered in particular protocols - usually, but not always, the oldest ones. The cost of adding a new GUC seems pretty small tom me compared to the appealing potential for users to secure their installation by changing a configuration setting rather than, say, having to wait for new packages to be available to install. > Moreover, the GUC could easily be misused to decrease rather than increase > one's security, if it's carelessly set. Remember that we only recently > fixed bugs that prevented use of the latest TLS version. If we have a > setting like this, I fully anticipate that people will set it to "only use > TLS 1.2" and then forget that they ever did that; years from now they'll > still be using 1.2 when it's deprecated. checkpoint_segments can easily be misused to decrease rather than increase performance, and autovacuum_naptime can easily be misused to destroy rather than improve autovacuum behavior. If we only added GUCs that couldn't be used to make things worse, we'd have no GUCs. The bottom line for me is that OpenSSL has (a) a seemingly never-ending supply of serious security flaws and (b) an exposed knob intended to help users of OpenSSL mitigate the effects of those flaws. Exposing that knob to our users seems like a good plan; supporting alternate SSL implementations might be an even better one, not that the two are mutually exclusive. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
