| 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: | Whole Thread | Raw Message | 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 |