Hi,
I observe a very annoying bug using TortoiseSVN or SVN command line
client on up to date Windows XP SP3. It seems to be a bug in the ssl
negociation process on Windows side. When connecting to my server for
update, commit or anything else, the TortoiseProc (or svn.exe) hang in
about one case out of two during the connecting phase. I need to
ctrl-alt-supp, select the process and kill it to stop it. We are using
the same server for one year with no problem with svn client on
GNU/Linux.
After a couple of days tracking the bug (I first thought of a
configuration problem on server side), I concluded that only Windows SP3
is affected (I tested three different computers). On Windows SP2 or
Vista, I can't reproduce the bug.
When using serf instead of neon, the certificat
On server side, Apache 2.2.3 (Debian Etch) or 2.2.8 (Ubuntu Hardy) has
been tested.
I also tested four types of certificates : from Godaddy, RapidSSL,
Cacert.org and from a local CA generated by openssl (CA.pl script from
openssl). The problem occurs only when using a valid certificate, certified by a trusted CA.
Here is the recipe :
On Debian or Ubuntu :
1. install apache2 and libapache2-svn
2. a2enmod ssl
3. edit /etc/apache2/sites-available/default and past the default conf
joined to this mail
4. place valid certificate and key on /etc/apache2/cert.crt
and /etc/apache2/cert.key (it must naturally be valid for what's on
ServerName in the apache conf)
5. mkdir /var/svn (or what you provided for SVNParentPath)
6. cd /var/svn
7. svnadmin create test
8. chown -R www-data:www-data /var/svn
At this point, https://<ServerName>/test point to a working svn
repository. It a typical configuration.
On Windows SP3 :
1. Add the CA certificate that signed the certificat you used for Apache
if needed (Settings, Internet Options, Content, Certificates, Trusted
root certificates, Import)
2. At this point, accessing https://>ServerName>/test with IE must be
possible without any SSL alert. If it is not the case, ensure that the CA
certificate is present in Trusted root certificates of windows)
3. With TortoiseSVN, checkout the repository.
4. Loop updating the repository and after two or three attempts, the
process hang.
Here are some logs of what append :
Apache debug log :
see apache.log
libneon debug log :
C:\Documents and Settings\Pierre\Bureau\test>svn up
Running pre_send hooks
compress: Initialization.
Sending request headers:
OPTIONS /test HTTP/1.1
Host: x41.local.lan
User-Agent: SVN/1.5.1 (r32289) neon/0.28.2
Keep-Alive:
Connection: TE, Keep-Alive
TE: trailers
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Accept-Encoding: gzip
Sending request-line and headers:
Doing DNS lookup on x41.local.lan...
Connecting to 10.0.2.2
One more thing : repositories from googlecode work great with https
access. I don't know what version of Apache and mod_ssl they are using.
My server configuration is straightforward. I think that a lot of subversion users are using the same.
Is there something that I can do to disable the SSL validation process as a temporary solution ?
I tested to set ssl-trust-default-ca to no but it has no effect.
Are there any svn repositories that are public accessible through https so that I can do more tests?
Thanks
Pierre Paysant-Le Roux
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1062846
Received on 2009-01-28 14:36:37 CET