Re: Debian readline/libedit breakage

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Michael Banck <mbanck(at)debian(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, jd(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Debian readline/libedit breakage
Date: 2011-02-11 22:22:55
Message-ID: 20110211222255.GA8305@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2011-02-11 22:39:42 Re: Range Types: empty ranges
Previous Message Nathan Boley 2011-02-11 22:06:04 Re: Range Types: empty ranges