On 2014-08-19 11:52:37 -0400, Stephen Frost wrote:
> * Andres Freund (andres@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.
Aha.
> > > 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
attributes.
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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
