From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: PQgetssl() and alternative SSL implementations |
Date: | 2014-08-19 16:29:50 |
Message-ID: | 53F37B7E.30300@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/19/2014 06:52 PM, Stephen Frost wrote:
> * Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
>> No. We should build something that's suitable for postgres, not
>> something general. We'll fail otherwise. For anything fancy the user has
>> to look at the certificate themselves. We should make it easy to get at
>> the whole certificate chain in a consistent manner.
>
> I don't buy this argument at all.
>
>>> Telling users they simply can't have this information isn't
>>> acceptable.
>>
>> Meh. Why? Most of that isn't something a normal libpq user is going to
>> need.
>
> I'm not interested in SSL support for users who don't use or care about
> SSL (which would be 'normal libpq users', really). I've *long* been
> frustrated by our poor support of SSL and at how painful it is to get
> proper SSL working- and it's been a real problem getting PG to pass the
> security compliance requirements because of that poor support. Let's
> stop the rhetoric that PG doesn't need anything but the most basic
> SSL/auditing/security capabilities.
I think you just packed up the goalposts for a one-way trip to Mars, but
I wonder: What would you consider "proper SSL support"? What exactly are
we missing?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-08-19 16:40:19 | Re: PQgetssl() and alternative SSL implementations |
Previous Message | Tom Lane | 2014-08-19 16:25:20 | Re: PQgetssl() and alternative SSL implementations |