Re: PQgetssl() and alternative SSL implementations - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: PQgetssl() and alternative SSL implementations
Date
Msg-id CABUevEzfxyOqWsWiVH6=hMfWx--sgCyqzR=2EvLQCwz==XuSZQ@mail.gmail.com
Whole thread Raw
In response to Re: PQgetssl() and alternative SSL implementations  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Aug 19, 2014 at 5:05 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
>> On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
>> > At first blush, I'd say a whole bunch..  Off the top of my head I can
>> > think of:
>
> [...]
>
>> I'm not really sure we need all that. We're not building a general ssl
>> library abstraction here.
>
> Really?  I'm pretty sure that's exactly what we're doing.  What I was
> wondering is which one we should be modeling off of.
>
> One thought I had was to look at what Apache's mod_ssl provides, which
> can be seen here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
>
> I know that I've used quite a few of those.
>
> Telling users they simply can't have this information isn't acceptable.
> I'm not a huge fan of just passing back all of the certificates and
> making the user extract out the information themselves, but if it comes
> down to it then that's at least better than removing any ability to get
> at that information.

Yeah, being able to provide most of them easily accessible is a good
thing. Otherwise, we just move the burden to deparse them to the
client which will then have to know which SSL library it's built
against, so every single client that wants to do something useful with
the cert would have to know about multiple implementations.

I think starting from the apache list is a very good idea.

We should then expose the same set of data at least through the
sslinfo server module.


>> What I'm wondering is whether we should differentiate 'standard'
>> attributes that we require from ones that a library can supply
>> optionally. If we don't we'll have difficulty enlarging the 'standard'
>> set over time.
>
> If we end up not being able to provide everything for all of the
> libraries we support then perhaps we can document which are available
> from all of them, but I'd hope the list of "only in X" is pretty small.

+1. I bet the most common ones will be in all of them, because
frankly, it's functionality you just need to use SSL properly.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Next
From: Stephen Frost
Date:
Subject: Re: PQgetssl() and alternative SSL implementations