[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] cleanup the neon socket when closing the ra_session

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-07-09 22:42:19 CEST

On 7/9/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Mark Phippard wrote:
> > On 7/9/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> >> > Really, my best advice is "don't use OpenSSL in threaded application" -
> >> > see also neon's GnuTLS support.
> >>
> >> Well, I can't do that. The users of TortoiseSVN would get really mad if
> >> I would stop using OpenSSL. And yes, TortoiseSVN is threaded, in fact
> >> all networking is done on a separate thread.
> >
> > If GnuTLS supports threading better, then why not consider it? I
> > doubt you have any need to support SSL v2.0 and GnuTLS seems to
> > support the newer protocols much better:
> >
> > http://www.gnu.org/software/gnutls/comparison.html
> Well, sure I could try and use GnuTLS instead of OpenSSL. But the
> Windows binaries of Subversion are built with OpenSSL, and that means
> the apache module is too. Which means users *can* use SSLv2.0. It would
> be a regression if TSVN would suddenly not connect to a https based
> repository anymore which it would previously.

The version of SSL used by an Apache http server is not in any way
dictated by how Subversion was built.

Granted, I assume most Apache SSL servers are using OpenSSL, so I am
not arguing with that. I think you are potentially making up a
non-existing problem here. You could just as easily say you have
users that want to use the latest versions of TLS protocol and cannot
because you chose to use OpenSSL. Over time, the latter scenario is
more likely than yours of wanting to use that ancient SSL version.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 9 22:41:54 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.