Bruce Momjian wrote: > Bruce Momjian wrote: >> It would be nice if 'sslverify' mimicked 'sslmode', which has these >> values: >> >> disable >> allow >> prefer >> require >> >> I don't see how we could use 'allow', but 'disable', 'prefer', and >> 'require' seem to work for sslverify, like sslmode. > > OK, crazy idea --- we use the three-value mode for sslverify listed > above, but we have it default to the value of sslmode. So, when sslmode > is prefer (the default), sslverify is 'prefer'. When sslmode is > require, so is sslverify, and of course disable sets them both to > disable. This gives us good defaults (prefer), but auto-locks down the > system when sslmode is 'require'.
This hides what the system does pretty darn well. sslverify=prefer - what does that mean? It's far from clear. Plus, I don't understand how the "verify certificate but not hostname" fits into this, but that could be because I really don't understand what they mean :-) However, slaving the default to sslmode probably make sense. As long as sslmode is not set to require, it doesn't make that much sense to verify the certificate at all, so I can see that defaulting to "none" or "off" or whatever in that case. I still think controlling it by an external file is a bad thing, but if it's controlled by the same connection string, it makes a lot more sense. So I think +1 for different defaults based on sslmode, but -1 on the strange naming. (not to say we can't fix the naming that's there now, but this specific suggestion makes it worse) /Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
