SEO

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. +

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

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.

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

iD8DBQFEXOxFIB7bNG8LQkwRAocVAJ9DS4kivI7L+8lsXpzyOh H31v9UmACZAR+b
897b/RUdPQ31Z1iRM/BlGA4=
=+tIq
-----END PGP SIGNATURE-----

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. +

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

http://archives.postgresql.org

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.

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

iD8DBQFEXPc5IB7bNG8LQkwRAtIpAJ9o5xHlK/ZUdhzGaqCGPzf8XKJQkQCfZPVh
I/Fl6IKgWvVaTOGPj2n3fdI=
=Cl5f
-----END PGP SIGNATURE-----

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. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings