On Wed, Apr 12, 2006 at 05:00:17PM -0400, Tom Lane wrote:
> > Issuer (name and certificate), validity dates, basic constraints, key
> > usage, posslby fingerprint.
>
> I think that way madness lies --- do we really want to commit to
> re-inventing an SSL API that will cover anything someone might want
> to do with either underlying library?
Indeed. There's also the issue that the underlying system may not be
using what you think it is. e.g. GnuTLS can authenticate on PGP keys
rather than x509 certificates. There's still the mystery regarding
libpq extracting peer DN and CN but passing it to the user.
> An idea that just occurred to me is to define PQgetssl as "return SSL*
> if we are using OpenSSL for this connection; else return NULL". Then
> add a parallel routine (maybe PQgetgnussl?) defined as returning the
> equivalent GnuTLS handle, only if we are using GnuTLS for this
> connection. (Presumably, in any one build of libpq, one of the pair of
> routines would be an always-returns-null stub.)
Alternatively, create a new function PQgetsslinfo() that returns both
the library name and a (void) pointer. In any case the old interface
can never return anything other than a pointer for OpenSSL.
> I'd still want to adopt Martijn's idea of declaring both of 'em as
> returning void *, to avoid depending on other packages' include files.
Ack, at least we can get that out of the way. It doesn't change
anything from the user's point of view, other than they know for sure
what the signiture is.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
