Re: Supporting Windows SChannel as OpenSSL replacement - Mailing list pgsql-hackers

On Mon, Jun 09, 2014 at 03:35:23PM +0200, Magnus Hagander wrote:
> On Mon, Jun 9, 2014 at 3:19 PM, Andreas Karlsson <andreas@proxel.se> wrote:
>
> > On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:

> > There was a patch set for this from Martijn van Oosterhout which was quite
> > complete.
> >
> > http://www.postgresql.org/message-id/20060504134807.GK4752@svana.org

Wow, blast from the past.

> A lot has, unfortunately, changed since 2006. It might be a good
> startingpoint. But also actively starting from the point of "let's try to
> support multiple libraries" rather than "let's try to support gnutls" is
> probably also important.

The patch did provide an API. The idea was that there were a number of
functions which would need to be defined to support an SSL library.
Each library would then have a wrapper which wrapped the library and
based on the results of configure it compiled the right file into the
backend.

These functions were:

extern void pgtls_initialize(void);
extern void pgtls_destroy(void);
extern int pgtls_open_server(Port *);
extern void pgtls_close(Port *);
extern ssize_t pgtls_read(Port *port, void *ptr, size_t len);
extern ssize_t pgtls_write(Port *port, void *ptr, size_t len);

Which should be easy enough to support for any library. These days
you'd need to add support for verifying certificates, but I don't think
that that would be difficult (unless the actual certificate formats are
different).

No switching after compile time, that would just lead to useless
overhead.

> At some point we should design a new API, so that we can deprecate the old
> one. Even if we don't hve the code ready, we need to get rid of PQgetssl(),
> and replace it with something else. I'm thinking probably a functoin that
> returns both a void pointer and an enum that tells you which library is
> actually in use. And a boolean just saying "ssl on/off", because that's
> what a lot of clients are interested in and they don't care aobut more than
> that.
>
> Obviously, we also have to do something about PQinitOpenSSL().

Yeah, I think this was one of the more controversial parts. Support in
the backend was primarily moving code around and renaming functions,
fairly straightforward.  Even error handling was not so hard (I found
the gnutls handling of errors much easier than openssl).

One tricky part is that programs like to use libpq for the
authentication, and then they hijack the connection using PGgetssl().

The way I dealt with this is defining a new state "passthrough" where
the caller would get a few function pointers to read/write/check the
connection.  Then the callers would not need to know what library libpq
was compiled with.  And libpq would know the connection was hijacked
and refuse to act anymore.  I don't think everyone was pleased with
this, but no real alternative was presented (other than requiring
people hijacking the connection to do the hard work).

For information about which library was in use there was PQgettlsinfo()
which returned a PGresult with information about the library and
connection.  I beleive since then new functions have been added to
libpq to retrive info about certificates, so that might need a rethink
also.

Basically, I think these last two points are the hard parts to get
agreement (assuming there's agreement to do anything at all about the
problem) and without nailing those down first whoever picks this up
will be in for a lot of work.