Re: Practical impediment to supporting multiple SSL libraries
От | Magnus Hagander |
---|---|
Тема | Re: Practical impediment to supporting multiple SSL libraries |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCEA352A0@algol.sollentuna.se обсуждение исходный текст |
Ответ на | Practical impediment to supporting multiple SSL libraries (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Practical impediment to supporting multiple SSL libraries
Re: Practical impediment to supporting multiple SSL libraries |
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: