From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Shulgin <ash(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inconsistency in libpq connection parameters, and extension thereof |
Date: | 2012-06-06 20:08:26 |
Message-ID: | CABUevEzrLEJhSPuH45YR=S62k25Fmp8_hz_SXiM+cZhQNhVO_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 6, 2012 at 6:58 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> On Wed, Jun 6, 2012 at 1:09 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Wed, Jun 6, 2012 at 4:38 AM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
>>> On Tue, Jun 5, 2012 at 6:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Daniel Farina <daniel(at)heroku(dot)com> writes:
>>> If that is the case, is there a convention we can use to separate the
>>> parts of the connection string (in both representations) into the
>>> parts sent to the server and the part that the client needs? We
>>> already abuse this a little bit because URI syntax (in general, not
>>> just our rendition of it) leaves little room for extension for
>>> parameters on the client side. Consider ?sslmode=require.
>>>
>>> In both representations, the net effect of a typo would be that
>>> instead of magically reading some properties on the client side,
>>> they'd be sent to the server. How often is this going to be so wrong
>>> that one cannot send a response from the server indicating to the user
>>> their error? On casual inspection it doesn't seem like prohibitively
>>> often, but I haven't mulled over that for very long.
>>
>> I think that's an excellent example of this being a bad idea. If you
>> mis-spell sslmode=require, that should absolutely result in an error
>> on the client side. Otherwise, you might end up sending your password
>> (or other details that are not as sensitive, but still sensitive) over
>> an unencrypted connection. If you wait for the error from the server,
>> it's too late.
>
> That is an excellent point. Is there enough time in the day to gripe
> about how sslmode=require is not the default?
Well, you'll get me first in line to back that the current default is stupid.
But I'm not sure sslmode=require is a proper default either. Because
then the connection will fail completely to the vast majority of
servers, which simply don't have SSL support.
> Well, this seems pretty obviated by the prefix-naming convention, but
> it's an iron clad example of how the older idea was a bad one.
Yeah, a prefix based solution would fix this, since we can keep throwing errors.
However, not throwing errors on the URL syntax should be considered a
bug, I think.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2012-06-06 20:09:46 | Re: Btree or not btree? That is the question |
Previous Message | Magnus Hagander | 2012-06-06 20:05:21 | Re: pg_receivexlog and feedback message |