I think we are ready to move forward with this. Please supply an
updated patch ready for application. Thanks.

---------------------------------------------------------------------------

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> This patch does the following:
>
> - Provide GnuTLS support beside OpenSSL in both the frontend and
> backend. Which is used is decided by the configure options
> --with-openssl and --with-gnutls. They are mutually exclusive.
>
> - When psql starts up the message has been altered to include details
> about the library. For example either of:
>
> SSL connection established: GnuTLS (version 1.0.16), encryption DHE_RSA_AES_256_CBC_SHA
> SSL connection established: OpenSSL (version OpenSSL 0.9.7e 25 Oct 2004), encryption DHE-RSA-AES256-SHA
>
> - psql is now SSL library agnostic. It can display the above info
> whether or not the SSL library was available at compile time. All
> that matters is what the libpq library was compiled against.
>
> - Provides a new function in libpq called PQgettlsinfo(). This returns
> a resultset containing the most useful details of the SSL connection,
> if any.
>
> - A new command has been added to psql, \ssl, which displays all the
> information available via PQgettlsinfo().
>
> - Provides a new function in libpq called PQsetPassthrough(). Once this
> function has been called on an idle connection, its state changes to
> CONNECTION_PASSTHROUGH. The usual query functions PQsend*, PQexec*,
> PQconsumeinput and others are blocked. All further communication must
> be by the user via the send/receive functions given. The only way to
> undo this is via PQreset or PQfinish.
>
> Backward compatability issues:
>
> - Applications using libpq to establish the connection and then
> reading/writing the socket directly may have unexpected results if
> the client is compiled against GnuTLS. The prior versions of libpq
> provided no way of identifying the SSL library is use. However, they
> will *not* crash.
>
> These applications have two options. They can use the new
> PQgettlsinfo() to determine which library libpq is using. They can
> then elect to disable SSL support via the sslmode option to avoid the
> issue. Alternately, they can use the new PQsetPassthough() function
> to retreive the necessary information to communicate directly.
>
> In the latter case, the application does not need to check the
> library in use, libpq will work transparently for all possibilities.
>
> Documentation will be provided assuming the above is considered
> satisfactory for inclusion without major changes.
>
> The attached diff does not include the diff of "configure" because I'm
> evidently running a different version and result was 200KB of useless
> stuff. The full patch is available here:
>
> http://svana.org/kleptog/temp/gnutls.patch
>
> Just running autoconf on the local machine should also work.
>
> Have a nice day,
> --
> Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> > From each according to his ability. To each according to his ability to litigate.

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think we are ready to move forward with this. Please supply an
> updated patch ready for application. Thanks.

I'm still not very happy with the size/invasiveness of that patch.

FWIW, Red Hat's legal department thinks that the FSF has "overreached"
in claiming that the GPL is incompatible with OpenSSL's license. Which
is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which
there are quite a few ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I think we are ready to move forward with this. Please supply an
> > updated patch ready for application. Thanks.
>
> I'm still not very happy with the size/invasiveness of that patch.

Nor am I.

> FWIW, Red Hat's legal department thinks that the FSF has "overreached"
> in claiming that the GPL is incompatible with OpenSSL's license. Which
> is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which
> there are quite a few ...

OK. Let's shelve the idea. I will add a TODO item.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Mon, May 29, 2006 at 11:21:16PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I think we are ready to move forward with this. Please supply an
> > updated patch ready for application. Thanks.
>
> I'm still not very happy with the size/invasiveness of that patch.

I think the size is unavoidable due to the amount of code being copied
between files. As an example I've created a version of the patch which
contains the minimal number of changes required for GnuTLS support.
That weighs in at 48KB. It does it by putting everything required into
one file and using #ifdefs to determine which code to compile.

Note: it's just an example, I wouldn't suggest adding it. For starters,
the #ifdef forest is a text-book example of how not to do things.
However, any increase in modularisation is going to increase the size
of the patch due to the moving around of code. If you have any
suggestions about the trade-off between modularity and patch size, I'd
like to hear them.

At the end of the day, what really needs to happen is that a position
needs to be taken:

1. No, never support anything other than OpenSSL
2. Yes, support GnuTLS but not in this form
3. Yes, accept patch as is (with updates for CVS drift)

Once a decision has been made, whatever it is, we can move forward. The
other features of the original patch can be added later if needed.

> FWIW, Red Hat's legal department thinks that the FSF has "overreached"
> in claiming that the GPL is incompatible with OpenSSL's license. Which
> is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which
> there are quite a few ...

It is absolutly true that being a limited liability company and having
money to pay lawyers helps with legal questions.

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEfCYSIB7bNG8LQkwRAv79AKCBhSGOZfSC9A3xku7uaP el3NfbMgCgkX6d
BgI21Ou7Irky+Dsd7UIi8Ok=
=qCmE
-----END PGP SIGNATURE-----

Forgot the patch...

On Tue, May 30, 2006 at 01:01:38PM +0200, Martijn van Oosterhout wrote:

<snip>
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEfCZ1IB7bNG8LQkwRAmtsAJ4hTDyRdrZMCN4D5PLKMf OMECmjswCff0En
Qbq3f9KdC7QW/sa9EZuOkao=
=jj+m
-----END PGP SIGNATURE-----

Tom Lane wrote:
> FWIW, Red Hat's legal department thinks that the FSF has "overreached"
> in claiming that the GPL is incompatible with OpenSSL's license. Which
> is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which
> there are quite a few ...
>
>
I'm quite happy if we hang onto Red Hat's coat tails on this one.

Do we use any GPL libraries other than libreadline? It would be nice to
be able to get out of this game altogether - getting libedit up to
scratch and portable would be very nice, and I know for a fact that
commercial postgres vendors would welcome such a development.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Andrew Dunstan wrote:
> Tom Lane wrote:
> > FWIW, Red Hat's legal department thinks that the FSF has "overreached"
> > in claiming that the GPL is incompatible with OpenSSL's license. Which
> > is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which
> > there are quite a few ...
> >
> >
> I'm quite happy if we hang onto Red Hat's coat tails on this one.
>
> Do we use any GPL libraries other than libreadline? It would be nice to
> be able to get out of this game altogether - getting libedit up to
> scratch and portable would be very nice, and I know for a fact that
> commercial postgres vendors would welcome such a development.

Agreed, but FYI GnuTLS is LGPL, not GPL.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Am Dienstag, 30. Mai 2006 05:21 schrieb Tom Lane:
> FWIW, Red Hat's legal department thinks that the FSF has "overreached"
> in claiming that the GPL is incompatible with OpenSSL's license. Which
> is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which
> there are quite a few ...

Here is some feedback from debian-legal about this:

"""
Based on this little snippet, it is unclear to me exactly what Red
Hat's legal department has said. Are they saying that the OpenSSL
license is not incompatible with the GPL? The advertising clause
seems like a clear incompatiblity.

Or are they saying that the GPL does not actually restrict people from
linking in libraries and distributing the result? That reading is
contradicted by a plain reading of the GPL.

What is most likely is that Red Hat's legal department has decided the
risk of suffering damages from distributing GPL'd programs linked with
OpenSSL is sufficiently low that they do not have to worry about it.
Debian tends to be much more conservative in this regard, partly
because the risk is borne by third parties (e.g. mirror operators and
CD vendors).
"""

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly