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

Re: SSL handshake failed: SSL error: A TLS warning alert has been received.

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Mon, 6 Sep 2010 23:20:49 -0400

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 been
>> received.
>>
>> 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
>> handshake
>>  > > 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 about
>>  > 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 use
> the ssl library directly.
>
> So this should be fixed either in Neon or (to restore compatibility with the
> older version) in the SSL library.
>
>        Bert

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.
Received on 2010-09-07 05:21:41 CEST

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

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