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