On Fri, Feb 11, 2011 at 5:22 PM, Martijn van Oosterhout
<kleptog@svana.org> wrote:
> On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote:
>> Note that the past discussion was on the difficulty of matching the
>> existing OpenSSL API using GnuTLS, which is apparently difficult to do.
>> I wasn't trying to suggest there were issues specificially with GnuTLS's
>> code quality. It's more that the APIs are just different enough that
>> it's not trivial to do a swap--which is surprising given how many people
>> have seemingly needed to do exactly this conversion. You'd think
>> there'd be a simple "OpenSSL-like" interface available for GnuTLS by now
>> or something.
>
> I spent some time a while back making PostgreSQL work with GnuTLS. The
> actual SSL bit is trivial. The GnuTLS interface actually made sense
> whereas the OpenSSL one is opaque (at least, I've never seen any
> structure in it). The GnuTLS interface was designed in the modern era
> and it shows.
>
> The problems are primarily that psql exposes in various ways that it
> uses OpenSSL and does it in ways that are hard to support backward
> compatably. So for GnuTLS support you need to handle all those bits
> too.
>
> For example, the patch as presented introduced a passthrough mode that
> allowed applications to read/write over the SSL connection without
> actually knowing the underlying library. It had to fix psql to use this
> info. It had to provide ways for applications to determine the info
> they needed about the SSL, since it wouldn't beable to just grab the
> OpenSSL handle.
>
> All this made the patch large, which caused it to be rejected. I found
> that odd since the bulk of the patch was the renaming of two files,
> which makes for huge diffs while the changes where minimal. I beleive
> git is smarter about renames which means the diff may magically become
> much smaller just by using git, yay!
>
> Supporting GnuTLS for that backend was just icing, but trivial once the
> frontend was done. It can be left out.
We should probably revisit this for 9.2.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company