The same problem has just manifested when using ubuntu lucid either due to a
package update or possibly changes on the server side. I now get the
following error when attempting an svn update (svn info works fine).
SSL handshake failed: SSL error: A TLS warning alert has been received.
I tried using the LD_PRELOAD=/usr/lib/libneon.so.27 before the command but
this resulted in the error message:
SSL handshake failed: SSL error code -1/1/336032856
The difference between these being that the first is using a version of
libneon build against gnutls whereas the second uses openssl.
It seems the error in the first case is down to a problem with libneon which
according to the changelog has been fixed in version 0.29-5 (0.29-1 is the
current version for lucid). By building my own libneon (using
-with-ssl=gnutls to specift gnutls rather than openssl) and subversion has
worked. Guess libneon package should be updated to version >= 0.29-5.
Nico Kadel-Garcia-2 wrote:
> On Mon, Sep 6, 2010 at 5:40 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>> -----Original Message-----
>>> From: Gero [mailto:gero_at_ieee.org]
>>> Sent: maandag 6 september 2010 11:37
>>> To: users_at_subversion.apache.org
>>> Subject: Re: SSL handshake failed: SSL error: A TLS warning alert has
>>> On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote:
>>> On Wed, Aug 11, 2010 at 10:24 AM, Gero <gero_at_ieee.org> wrote:
>>> > > Hi,
>>> > >
>>> > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no
>>> longer access
>>> > > an SVN repository:
>>> > >
>>> > > $ svn update
>>> > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL
>>> > > failed: SSL error: A TLS warning alert has been received.
>>> > > (https://example.com)
>>> > But 'svn info 'https://example.com/path/to/svn/trunk works? What
>>> > doing a clean checkout to a new location?
>>> 'svn info' with no arguments works and shows info about the repository
>>> in question. 'svn info <repo>', however, does not work, with the same
>>> error message as above. A clean checkout doesn't work either.
>>> There is an Ubuntu bug report about Subversion not playing with the
>>> latest libneon nor libneon-gnutls. Apparently, libneon now reports more
>>> SSL problems that Subversion should ignore, but doesn't.
>> Subversion uses neon and neon uses your SSL library. Subversion doesn't
>> the ssl library directly.
>> So this should be fixed either in Neon or (to restore compatibility with
>> older version) in the SSL library.
> Really? Why do you think this?
> For RHEL 5, the RPMforge packages actually have to include
> compatibility versions of python, neon, and swig. Component drift for
> the 4 major and several variant methods of accessing a Subversion
> repository is a demonstrable issue: between local file access,
> svnserve, HTTP, and the minor variants of HTTPS and ssh+svn, you have
> a potential for a lot of subtle version skew in components themselves
> and especially in the interfaces to those components.
> It's already awkward with enterprise operating systems, which are very
> reluctant to upgrade system components. (See the RHEL 5 comment, and I
> went through this with SCO OpenServer 5 myself.) It seems
> unsurprising that Ubuntu, that tends to be leading edge, is
> encountering version skew issues from the other side.
View this message in context: http://old.nabble.com/SSL-handshake-failed%3A-SSL-error%3A-A-TLS-warning-alert-has-been-received.-tp29409554p32249793.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Received on 2011-08-12 14:33:33 CEST