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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PQgetssl() and alternative SSL implementations
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PQgetssl() and alternative SSL implementations