* 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). 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. > > 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. Thanks, Stephen
Description: Digital signature