Re: [PATCHES] [PATCH] Add support for GnuTLS
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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 EnterpriseDBhttp://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
Re: [PATCHES] [PATCH] Add support for GnuTLS
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
Re: [PATCHES] [PATCH] Add support for GnuTLS
Forgot the patch... On Tue, May 30, 2006 at 01:01:38PM +0200, Martijn van Oosterhout wrote: -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. Index: configure Index: configure.in === RCS file: /projects/cvsroot/pgsql/configure.in,v retrieving revision 1.464 diff -c -r1.464 configure.in *** configure.in29 Apr 2006 20:47:29 - 1.464 --- configure.in30 May 2006 10:51:30 - *** *** 489,498 # AC_MSG_CHECKING([whether to build with OpenSSL support]) PGAC_ARG_BOOL(with, openssl, no, [ --with-openssl build with OpenSSL support], ! [AC_DEFINE([USE_SSL], 1, [Define to build with (Open)SSL support. (--with-openssl)])]) AC_MSG_RESULT([$with_openssl]) AC_SUBST(with_openssl) # # Prefer libedit --- 489,515 # AC_MSG_CHECKING([whether to build with OpenSSL support]) PGAC_ARG_BOOL(with, openssl, no, [ --with-openssl build with OpenSSL support], ! [AC_DEFINE([USE_SSL_OPENSSL], 1, [Define to build with (Open)SSL support. (--with-openssl)])]) AC_MSG_RESULT([$with_openssl]) AC_SUBST(with_openssl) + # + # GnuTLS + # + AC_MSG_CHECKING([whether to build with GnuTLS support]) + PGAC_ARG_BOOL(with, gnutls, no, [ --with-gnutls build with GnuTLS support], + [AC_DEFINE([USE_SSL_GNUTLS], 1, [Define to build with GnuTLS (SSL) support. (--with-gnutls)])]) + AC_MSG_RESULT([$with_gnutls]) + AC_SUBST(with_gnutls) + + if test "$with_openssl" = yes -o "$with_gnutls" = yes ; then + AC_DEFINE([USE_SSL], 1, [Define to build with SSL support (select either OpenSSL or GnuTLS)]) + fi + + if test "$with_openssl" = yes -a "$with_gnutls" = yes ; then + AC_MSG_ERROR([ + *** Cannot select both OpenSSL and GnuTLS.]) + fi # # Prefer libedit *** *** 692,697 --- 709,720 fi fi + if test "$with_gnutls" = yes ; then + AC_CHECK_LIB(gnutls, gnutls_init, [], [AC_MSG_ERROR([library 'gnutls' is required for GnuTLS])]) + # Technically we only need this with --enable-thread-safety + AC_CHECK_LIB(gcrypt, gcry_control, [], [AC_MSG_ERROR([library 'gcrypt' is required for GnuTLS])]) + fi + if test "$with_pam" = yes ; then AC_CHECK_LIB(pam,pam_start, [], [AC_MSG_ERROR([library 'pam' is required for PAM])]) fi *** *** 774,779 --- 797,807 AC_CHECK_HEADER(openssl/err.h, [], [AC_MSG_ERROR([header file is required for OpenSSL])]) fi + if test "$with_gnutls" = yes ; then + AC_CHECK_HEADER(gnutls/gnutls.h, [], [AC_MSG_ERROR([header file is required for GnuTLS])]) + AC_CHECK_HEADER(gcrypt.h,[], [AC_MSG_ERROR([header file is required for GnuTLS])]) + fi + if test "$with_pam" = yes ; then AC_CHECK_HEADERS(security/pam_appl.h, [], [AC_CHECK_HEADERS(pam/pam_appl.h, [], Index: src/backend/libpq/be-secure.c === RCS file: /projects/cvsroot/pgsql/src/backend/libpq/be-secure.c,v retrieving revision 1.70 diff -c -r1.70 be-secure.c *** src/backend/libpq/be-secure.c 12 May 2006 22:44:36 - 1.70 --- src/backend/libpq/be-secure.c 30 May 2006 10:51:32 - *** *** 89,99 #include #endif ! #ifdef USE_SSL #include #include #endif #include "libpq/libpq.h" #include "miscadmin.h" #include "tcop/tcopprot.h" --- 89,108 #include #endif ! #ifdef USE_SSL_OPENSSL #include #include #endif + #ifdef USE_SSL_GNUTLS + #include + #include + + /* If thread safety ever becomes an issue for the backend, we will need to + * include this. See the frontend code in libpq. */ + /* #include */ + #endif + #include "libpq/libpq.h" #include "miscadmin.h" #include "tcop/tcopprot.h" *** *** 106,132 #define SERVER_CERT_FILE "server.crt" #define SERVER_PRIVATE_KEY_FILE "server.key" - static DH *load_dh_file(int keylength); - static DH *load_dh_buffer(const char *, size_t); - static DH *tmp_dh_cb(SSL *s, int is_export, int keylength); - static intverify_cb(int, X509_STORE_CTX *); - static void info_cb(const SSL *ssl, int type, int args); static void initialize_SSL(void); static void destroy_SSL(void); static intopen_server_SSL(Port *); static void close_SSL(Port *); - static const char *SSLerrmessage(void); - #endif - - #ifdef USE_SSL /* *How much data can be sent across a secure connection *(total in both directions) before we require renegotiation. */ #define RENEGOTIATION_LIMIT (512 * 1024 * 1024) static SSL_CTX *SSL_context = NULL; #endif /* */ /* Hardcoded values
Re: [PATCHES] [PATCH] Add support for GnuTLS
On Mon, May 29, 2006 at 11:21:16PM -0400, Tom Lane wrote: > Bruce Momjian 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 http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] [PATCH] Add support for GnuTLS
Tom Lane wrote: > Bruce Momjian 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 EnterpriseDBhttp://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
Re: [PATCHES] [PATCH] Add support for GnuTLS
Bruce Momjian 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 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 EnterpriseDBhttp://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
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 EnterpriseDBhttp://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
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] [PATCH] Add support for GnuTLS
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 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 EnterpriseDBhttp://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
