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

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Bruce Momjian wrote:
>>> The only other approach would be to add an sslverify value of
>>> 'try' that tries only if root.crt exists.
>
>> Doesn't "try" make the whole check pretty pointless, and you can just
>> set it to "none" then?
>
> Not at all. What it means is that you control whether to make the check
> by putting the file there (or not). Which you have to do anyway, if you
> want to make the check.

Which means that every time I connect, I need to first to make sure that
the file is there, and that the proper user has permissions to read the
file, *before* I connect.

> All that the current definition of the setting
> is accomplishing is forcing people to fool with their environment
variables,
> which is a pain in the neck to varying degrees depending on platform.

That, or un-breaking their environment.

>> Inventing a switch that makes it more or less impossible to figure out
>> if you are going to be secure or not makes no sense. When dealing with
>> security, maybe is the same as no, and you have to *know*.
>
> I am of the opinion that sslverify should have these values:
>
> off = never verify
> on = verify if root.crt is present (default behavior)
> force = verify, failing if root.crt is not present
>
> and the people who actually want to be "sure they're secure" can set the
> "force" value in their environment.

Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
something like "maybe" or "external" or "file". I'd find it very bad if
you can say "sslverify=on" and then *not* end up getting it because of
some external factor. That needs to be clear in the naming of the value
if we go down that path.

Plus you somehow need to overload it with the cn vs certificate only
part. The ability to not do full hostname verification has been
specifically asked for.

> This is not measurably different in effect from the fact that we have
> sslmode defaulting to "prefer" rather than "require". If you want to be
> "sure you're secure" you need the latter setting, but I don't believe
> there is even remotely a consensus for making that the default.

That's a whole mess in itself, really. Originally, we had SSL on or off.
If you set it to on, it required SSL. If you set it to off, it wouldn't
use SSL.

"sslmode=prefer" honestly makes no sense - if I don't care if it ends up
encrypted or not (which it means), then why not just run with SSL off
and not have to deal with the overhead?

> BTW, what in the world prompted us to use "cn" as an allowed value for
> sslverify? It looks for all the world like a typo for "on".

Eh, what would you call it? It enables verification of the cn field in
the certificate. Another option I considered was "full", but someone
said that was bad - can't recall if that was on-list or off ATM.

//Magnus