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

Re: Help! REPORT fail & SSL error... UPDATE

From: Samay <getafix123_at_hotmail.com>
Date: 2006-09-28 04:56:11 CEST

it may be worthwhile to try a fresh client with SVN 1.3.x Neon 0.25.x one
and see if error persists. My guess is, its the same error that has been
haunting me for past few days (search for thread "Possible bug in win32-
1.4.0 when accessing repository via https", just a different symptom! Our
only way out was downgrade SVN clients to 1.3.x except 1.4.x TSVN.

BTW, Authz is for AUthorization.

cheers

Shirish

----- Original Message -----
From: "Justin" <justin@hush.cc>
To: <users@subversion.tigris.org>
Cc: "Samay" <getafix123@hotmail.com>
Sent: Thursday, September 28, 2006 12:48 PM
Subject: Re: Help! REPORT fail & SSL error... UPDATE

> Hi Samay,
>
> Client-side, it's nothing odd. The server is serving repositories via
> HTTPS over Apache2 - in fact, that's all Apache2 is doing, so the setup
> is very straightforward. Client-side, we're using bith built and binary
> installs of SubVersion, on OS X and Windows. Authentication is via
> Apache2 - I forget what that method is called (authz?) - it's the method
> recommended in the online SVN book though.
>
> And it's always worked! Until now. A few days ago I had a dev install
> 1.4.0 without my knowledge - and now, problems. Server and clients were
> always 1.3.latest-before-1.4.0. Apache/SSL logs give the errors that are
> consistent with this SVN error - "cannot write base64 data" or something
> (sorry I'm at home now, I'll e-mail the exact messages tomorrow morning).
>
> Thanks, I appreciate it. Might anyone have a SubVersion developer's e-
> mail? This seems like a problem that pops up once in a while with NO
> solution anywhere online... =\ but it's been reported a bunch of
> times before!
>
> *justin
>
>
> On Sep 27, 2006, at 9:40 PM, Samay wrote:
>
>> so its may not be a server side issue then ... could you please describe
>> your client side environment & ur authentication schema on the server
>> side? is it "Kerberos/SSPI" based, if yes, it probably will not work
>> with 1.4.x SVN client. It seems to be royally broken!
>>
>>
>> ----- Original Message ----- From: "Justin" <justin@hush.cc>
>> To: <users@subversion.tigris.org>
>> Cc: "Samay" <getafix123@hotmail.com>
>> Sent: Thursday, September 28, 2006 8:04 AM
>> Subject: Re: Help! REPORT fail & SSL error... UPDATE
>>
>>
>>> Hi Samay,
>>>
>>> THAT works perfectly - no errors at all.
>>>
>>> On a whim, I recreated the ssl certificate - nothing has changed at
>>> all, so it's basically the same certificate that was already in place.
>>> That didn't alleviate the issue. Now, 1.4.0's release notes don't say
>>> a thing about changes to the way certificates are handled, so I think
>>> I can rule out problems with the certificates.
>>>
>>> Looks like I'll be here a _while_ so I greatly appreciate any info
>>> that you listers have on this. Thanks!
>>>
>>> *justin
>>>
>>>
>>> On Sep 27, 2006, at 5:51 PM, Samay wrote:
>>>
>>>> are u able to access https://ip.ad.dr.ess/pathtorepo/ through your
>>>> web browser ... whats the error there? then try https://
>>>> ip.ad.dr.ess/somelocal.file/ via ur web browser? do both work?
>>>>
>>>>
>>>> ----- Original Message ----- From: "Justin" <justin@hush.cc>
>>>> To: <users@subversion.tigris.org>
>>>> Cc: "Garrett Rooney" <rooneg@electricjellyfish.net>
>>>> Sent: Thursday, September 28, 2006 7:31 AM
>>>> Subject: Re: Help! REPORT fail & SSL error... UPDATE
>>>>
>>>>
>>>>> Hi Garrett,
>>>>>
>>>>> Trying it locally (using https://127.0.0.1/pathToRepository) results
>>>>> in the same error message actually! I'm thinking about recreating
>>>>> the self-signed certificate in the meantime, while I wait to see if
>>>>> anyone else has some input on the issue...
>>>>>
>>>>> Thanks a ton!
>>>>>
>>>>> *justin
>>>>>
>>>>>
>>>>> On Sep 27, 2006, at 5:20 PM, Garrett Rooney wrote:
>>>>>
>>>>>> On 9/27/06, Justin <justin@hush.cc> wrote:
>>>>>>> Hey again everyone,
>>>>>>>
>>>>>>> Turns out one of our devs used SubVersion 1.4.0 on our 1.3.latest
>>>>>>> server. So, updated the server to 1.4.0 and the clients expecting
>>>>>>> things to work... while the error I'm getting is now smaller, this
>>>>>>> part of the error still exists:
>>>>>>>
>>>>>>> svn: REPORT request failed on '/svn/!svn/vcc/default'
>>>>>>> svn: REPORT of '/svn/!svn/vcc/default': Could not read response
>>>>>>> body:
>>>>>>> SSL error: decryption failed or bad record mac (https://
>>>>>>> my.ip.goes.here)
>>>>>>>
>>>>>>> I'm seriously running into a lack of information on this error,
>>>>>>> despite people reporting it. Does anyone have any ideas? = ( I'm
>>>>>>> gearing up for an all-nighter here because I have to have this
>>>>>>> working...
>>>>>>
>>>>>> If I had to guess I'd say you should start looking for something
>>>>>> between the client and the server that's causing problems. Does
>>>>>> this
>>>>>> happen if you run the command right on the server, not going over
>>>>>> the
>>>>>> network at all?
>>>>>>
>>>>>> -garrett
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 28 04:56:50 2006

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.