SEO

> > There is a more serious issue here though: if we allow more
> than one
> > SSL library, what exactly can an application safely do with the
> > returned pointer? It strikes me as very dangerous for the app to
> > assume it knows which SSL library is underneath libpq. It's not at
> > all hard to imagine an app getting an OpenSSL struct pointer and
> > trying to pass it to GnuTLS or vice versa. To the extent
> that there
> > are apps out there that depend on doing something with this
> function,
> > I think that even contemplating supporting multiple SSL
> libraries is a threat.
>
> The only real way to a solution is to work out why people
> want the pointer. So far I've found two reasons:
>
> - People want to hijack the connection after libpq has set it
> up to do their own processing.
>
> - People want to examine the certificates more closely.
>
> The first would be easily handled by providing a formal
> interface for libpq to hijack the connection with, providing
> read/write and maybe a few others. The latter is tricker.
> You're invariably going to run into the problem where the app
> uses one lib and libpq the other.
>
> Other than DN and CN, what else would people want?

Issuer (name and certificate), validity dates, basic constraints, key
usage, posslby fingerprint.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Wed, Apr 12, 2006 at 08:14:58PM +0200, Magnus Hagander wrote:
> > Other than DN and CN, what else would people want?
>
> Issuer (name and certificate), validity dates, basic constraints, key
> usage, posslby fingerprint.

GnuTLS handles this with just one function:

gnutls_x509_crt_get_dn_by_oid( cert, oid, index, raw, &data, &length )

And a whole pile of #defines

#define GNUTLS_OID_X520_COUNTRY_NAME "2.5.4.6"
#define GNUTLS_OID_X520_ORGANIZATION_NAME "2.5.4.10"
#define GNUTLS_OID_X520_ORGANIZATIONAL_UNIT_NAME "2.5.4.11"

etc...

Which is nice because then end users can code in the attributes they
want and we don't have to deal with the endless variations. I don't
however know enough to know if this (with a function to get OIDs by
index) is sufficient to extract all the information from the
certificate.

Presumably OpenSSL can do this too...
--
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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEPVFAIB7bNG8LQkwRAi6uAJsE95RFn+4yuF7OSeZ6ew jGxeaq+ACeJiXr
/h6MxfEHacjK/Ko5HdRCf8k=
=BWjo
-----END PGP SIGNATURE-----

"Magnus Hagander" <mha@sollentuna.net> writes:
>> Other than DN and CN, what else would people want?

> 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? Moreover, this does not fix
the problem: an existing app that thinks it can pass the returned
pointer to an OpenSSL routine will still crash the moment a GnuTLS
version of libpq is put under it. Case in point: psql, as currently
coded.

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.)

The advantage of this is that an app knows what it'll get, and an app
that's only familiar with one of the two SSL libraries will not be
given a pointer it can't use.

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEPfUFIB7bNG8LQkwRAlOsAJ44D8AynAQIlvpSwLw1qd dRwCuVlQCeNXvI
ydeA54oV9LE9WTWygrK3Hyo=
=E0aW
-----END PGP SIGNATURE-----