On 2014-08-19 11:52:37 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.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).

That's the majority of our users. Even those that care about ssl care
about setting it up in a safe manner, won't care about most of the

I have no problem to expand the list of attributes once we have a couple
of differing backends for the support, but having a long list of things
that need to be supported by every one just makes getting there harder.

> 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've no problem with keeping future extensions of the API in mind while
this is being designed. We just shouldn't start too big. This is about
getting a proper abstraction in place, not making pg pass security
compliance stuff. Don't mix those too much.

> > > 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.
> > 
> > I'm pretty sure that we can't build a reasonable list of the information
> > exposed by any library. Especially as we're likely going to need some
> > mapping to agree to map to the common names.
> Per Apache's documentation, mod_ssl and mod_gnutls support the same set
> of environment variables (with the same names even), so I don't buy this
> argument either.

Gnutls is quite similar from what it provides to openssl. That's not
saying much. Schannel would be more interesting from that point of view.


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to