* 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
signature.asc
Description: Digital signature
