Re: PQgetssl() and alternative SSL implementations

On 08/20/2014 12:58 AM, Heikki Linnakangas wrote:
> On 08/19/2014 10:31 PM, Robert Haas wrote:
>> On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Robert's got a point though: there is always going to be somebody who
>>>> wants something we fail to expose. It's better to be able to say "well,
>>>> you can do PQgetssl and then munge it for yourself" than to have to say
>>>> "sorry, you're screwed". So if we're going to define PQgetssl as
>>>> returning NULL when you're not using OpenSSL, I don't see why we
>>>> shouldn't expose a similarly-defined PQgetXXX for each other underlying
>>>> implementation we support. There will not be that many of 'em, and
>>>> I suspect the people with very specific needs will not care about more
>>>> than one underlying library anyway.
>>>>
>>>> This does not say that we shouldn't also try to have some
>>>> library-independent functionality for interrogating certificate state
>>>> etc. Just that having an escape hatch isn't a bad thing.
>
> Yeah, wouldn't hurt I guess.
>
>>> I do agree tha thaving both would be useful. We could have something like
>>> int PQgetSSLstruct(void **sslstruct)
>>
>> I think it's likely smarter to have totally separate functions.
>> First, to make it less likely that users will try to use a pointer to
>> one type of object as a pointer to some other kind of object. And
>> second, because you might, for example, someday have an SSL
>> implementation that wants to return two pointers. May as well make
>> that kind of thing easy.
>
> The struct it returns is totally SSL-implementation specific anyway, so
> for an implementation that would like to return two structs, you could
> well define it to return a struct like:
>
> struct {
> CoolStructA *a;
> CoolStructB *b;
> } CoolSSLStruct;
>
> I don't much like adding a separate function for every SSL
> implementation, but you've got a point that it would be nice to make it
> difficult to call PQgetSSLstruct() and just assume that the returned
> struct is e.g an OpenSSL struct, while it's actually something else.
> Perhaps:
>
> int PQgetSSLstruct(void **sslstruct, char *structname)
>
> You'd call it like PQgetSSLStruct(&mystruct, "openssl"), and it checks
> that the argument matches the library actually been used, otherwise it
> returns an error. And if you need to return two structs, you'd call it
> twice: PQgetSSLStruct(&a, "cool_a") and PQgetSSLStruct(&b, "cool_b").

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.

Thoughts?

- Heikki