Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt

Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> One random idea is to fold both of these settings into sslmode, with
>>> the
>>> following progression:
>>>
>>> disable, allow, prefer, require, require-cert, require-cn
>>>
>>> And then set the default to "disable", because as you say "prefer"
>>> is pretty
>>> silly. And then users can explictly choose which level of SSL-ness
>>> they want.
>> This is a different way to do bruces suggestion of a different
>> default. That's possibly even clearer. So I can definitely go with
>> this, but I think two different parameters makes it more clear and is
>> better.
>>
>> And +1 for changing the default sslmode regardless of how we configure
>> ssl verification.
>
> I like Peter's idea too. Having _three_ SSL settings is overkill, and I
> like the idea of doing it with one parameter. As already pointed out,
> it makes no sense to do server certificate verification unless the
> sslmode is 'require', and having require-cert and require-cn are very
> clear.
>
> I disagree with Magnus that having two parameters is better --- I think
> there is just too much risk of misconfiguration with two parameters.

Very well. One important part of having that would be to enable it by
default when you do "require", but there are other ways to accomplish
that of course.

> I would actually call the two parameters 'verify-cert' and 'verify-cn',
> and document that they also have "require" behavior. Obviously you
> can't verify certificates unless you require SSL.

I would prefer having "verify", "verify-no-cn" and "no-verify" or
something like that. Making it the "default choice" to have verification
enabled, and very clear that you're turning something off if you're not.
And then just map require to verify. Or they could be "require-no-cn"
and "require-no-cert" perhaps?

("default choice" only for those using ssl of course - we'd still have
"disable" as the default *value* of the parameter)

//Magnus