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