Thread: [PATCH] Add support for GnuTLS
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
This is a pretty massive patch, but I understand the license concerns. Is this what we want to do? FYI, yesterday's SSL CRL additions need to be added to this patch. --------------------------------------------------------------------------- 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. +
On Sat, May 06, 2006 at 01:11:26PM -0400, Bruce Momjian wrote: > > This is a pretty massive patch, but I understand the license concerns. > Is this what we want to do? More than half the patch is simply moving the OpenSSL related stuff from fe/be-secure.c to fe/be-secure-openssl.c. If you create the -openssl versions first you can more easily see that the changes are in fact quite minor. Unfortunatly diff can't represent the change "copy N lines from file A to file B" very efficiently. If you like I can split it into two patches, one patch splits the openssl stuff out of the main files and a second which adds gnutls support. > FYI, yesterday's SSL CRL additions need to be added to this patch. I saw them. I've already added them to my local version, including the corresponding changes for GnuTLS. I was going to wait a few days before sending a new version, in case any more changes came down the line. 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
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Sat, May 06, 2006 at 01:11:26PM -0400, Bruce Momjian wrote: > > > > This is a pretty massive patch, but I understand the license concerns. > > Is this what we want to do? > > More than half the patch is simply moving the OpenSSL related stuff > from fe/be-secure.c to fe/be-secure-openssl.c. If you create the > -openssl versions first you can more easily see that the changes are in > fact quite minor. Unfortunatly diff can't represent the change "copy N > lines from file A to file B" very efficiently. > > If you like I can split it into two patches, one patch splits the openssl > stuff out of the main files and a second which adds gnutls support. Yes, I understood that, but we now have duplicate files for secure connections, meaning we have double maintenance in some cases. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sat, May 06, 2006 at 02:47:33PM -0400, Bruce Momjian wrote: > Martijn van Oosterhout wrote: > > If you like I can split it into two patches, one patch splits the openssl > > stuff out of the main files and a second which adds gnutls support. > > Yes, I understood that, but we now have duplicate files for secure > connections, meaning we have double maintenance in some cases. Hmm, I see your point. I guess that's an unavoidable side-effect of the process :(. However, judging from the CVS logs, these have not been files with a high change rate. I think it's worth it but I can imagine other people see that differently. There is not a lot of code can be shared. What can be already is eg. prepare_for_client_read and client_read_ended, the names of the files used, EPIPE handling, etc. 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
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sat, May 06, 2006 at 02:47:33PM -0400, Bruce Momjian wrote:
> > Martijn van Oosterhout wrote:
> > > If you like I can split it into two patches, one patch splits the openssl
> > > stuff out of the main files and a second which adds gnutls support.
> >
> > Yes, I understood that, but we now have duplicate files for secure
> > connections, meaning we have double maintenance in some cases.
>
> Hmm, I see your point. I guess that's an unavoidable side-effect of the
> process :(. However, judging from the CVS logs, these have not been files
> with a high change rate. I think it's worth it but I can imagine other
> people see that differently.
>
> There is not a lot of code can be shared. What can be already is eg.
> prepare_for_client_read and client_read_ended, the names of the files
> used, EPIPE handling, etc.
The only other case I can think of where we support multiple libraries
for licensing reasons is readline/libedit, but in that case libedit has
the same API as readline, so we don't require much code duplication,
must some configure magic.
I see the problem with the OpenSSL license:
http://www.gnome.org/~markmc/openssl-and-the-gpl.html
Of course, we are trading a BSD license with advertizing clause with an
LGPL license. I guess it makes sense.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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. +
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
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. +
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.
Attachment
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.
Attachment
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
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. +
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/