From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: controlling the location of server-side SSL files |
Date: | 2012-02-29 19:20:30 |
Message-ID: | 5162.1330543230@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
>> Yes, ignoring a missing file in a security context is definitely not good.
>> It should throw an error.
>>
>> We have a few bad defaults from the old days around SSL for this, but if it
>> requires breaking backwards compatibility to get it right, I think we
>> should still do it.
> Btw., should we also consider making similar changes on the libpq side?
I think that breaking compatibility of libpq's behavior is a whole lot
harder sell than changing things in a way that only affects what people
have to put into postgresql.conf. We've always treated the latter as
something that can change across major versions.
In particular, I observe that we get pushback anytime we break something
in a way that makes SSL config files be required on the client side;
see bug #6302 for most recent example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2012-02-29 19:25:57 | Re: controlling the location of server-side SSL files |
Previous Message | Alvaro Herrera | 2012-02-29 19:18:44 | Re: 16-bit page checksums for 9.2 |