Re: PQgetssl() and alternative SSL implementations
От | Stephen Frost |
---|---|
Тема | Re: PQgetssl() and alternative SSL implementations |
Дата | |
Msg-id | 20150128165847.GY3854@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: PQgetssl() and alternative SSL implementations (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PQgetssl() and alternative SSL implementations
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: PQgetssl() and alternative SSL implementations (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
* Robert Haas (robertmhaas@gmail.com) wrote: > On Wed, Jan 28, 2015 at 10:13 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: > > Here's a patch to implement the above scheme. It adds four functions to > > libpq, to interrogate the SSL status: > > > > int PQsslInUse(const PGconn *conn) > > Returns true (1) if the connection uses SSL, false (0) if not. > > > > const char *PQsslAttribute(const PGconn *conn, const char *attribute_name) > > Returns a piece of information. The list of attributes depends on the > > implementation, but there are a few that are expected to be supported by all > > of them. See docs for details. > > > > const char **PQsslAttributes(const PGconn *conn); > > Return an array of SSL attribute names available. > > > > void *PQsslStruct(const PGconn *conn, const char *struct_name) > > Return a pointer to an SSL-implementation specific object describing the > > connection. PQsslStruct(conn, "OpenSSL SSL") is equivalent to > > PQgetssl(conn). > > > > I think this is expandable enough, because you can easily add attributes > > later on, and different implementations can support different attributes. It > > contains the escape hatch for applications that need to do more, and have > > intimate knowledge of OpenSSL structs. It's also pretty easy to use. > > I like it! > > Although I think "OpenSSL SSL" is a little bit duplicatively > redundant. Why not just "OpenSSL"? I wondered also, but figured it was probably because it's OpenSSL's "ssl" structure, which then made sense. What bothers me about this is that it punts SSL work to the application and requires that they be coded to work with both OpenSSL and whatever else we implement (eg: GnuTLS) to do anything but the most simple checks. That's a problem because people are *not* going to want to #include both OpenSSL and GnuTLS headers into their applications because they don't know which PG will be compiled with.. Not to mention that it'd be darn awkward to do so. My hope is that Heikki's attribute approach will be extended quite a bit in the near future (to hopefully avoid too many apps having to deal with the complexity of supporting multiple major PG versions where the older ones don't have the necessary attributes..), but I'm not sure that this will actually make it much easier to support GnuTLS, nor am I sure that anyone is going to actually go through that effort.. And if we don't then we really aren't making an improvement here since it'll still all be OpenSSL-centric. Thanks, Stephen
В списке pgsql-hackers по дате отправления: