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.
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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers