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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, Martin Pitt <mpitt(at)debian(dot)org>
Subject: Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt
Date: 2009-04-24 14:11:10
Message-ID: 49F1C87E.30401@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Magnus Hagander wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>>> Tom Lane wrote:
>>>>> Having a connection that
>>>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>>>> is just plain NOT acceptable.
>>>>>
>>>>> I think the patch would be fine if we simply keep the default where
>>>>> it is, however. Is there some point I am missing that compels
>>>>> selection of a less-secure default?
>>>> The current default *makes no sense*. Ever. Not just as a default.
>>> I categorically reject that thinking. Encrypted connections are useful
>>> even without authentication. Your argument ignores the real fact that
>>> eavesdropping is easier than man-in-the-middle attacks. Even if there
>>> weren't any significant difference, what is the gain from switching to
>>> unencrypted in cases where we previously used encryption? There is
>>> none.
>> Did you read the thread? That's not the argument that makes it make no
>> sense.
>>
>> Yes, encrypted connections are useful without authentication. But they
>> are quite useless unless you can determine if you have encryption *at
>> all* before you start sending sensitive data.
>>
>>
>>>> However, I can see us having "allow" instead of "disable" as the
>>>> default. That is the most forgiving of all settings - it will work with
>>>> whatever you had configured before.
>>> And it still moves us to "less secure than 8.3 by default", because
>>> configurations that formerly used encrypted connections might now use
>>> unencrypted ones. It's not acceptable.
>> Fine. I'll leave the default as it is then, and document that the
>> default we've chosen means "I don't care if I get security or not, but
>> if possible, I'd like to pay the encryption overhead".
>>
>
> I have applied a patch that does this.
>
> There are some further documentation updates required, I'll keep working
> on those.

I've committed another set of docs, which I think means I'm done.
Comments are welcome.

//Magnus

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-04-24 14:28:10 Re: BUG #4779: LIMIT/OFFSET behavior change (possibly related to Top-n)
Previous Message Kevin Field 2009-04-24 14:09:53 Re: BUG #4763: postgres service unstable, even during install