You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andy Helten <an...@dot21rts.com> on 2004/07/27 17:57:27 UTC
Error checking out large repository -- illegal padding
I'm trying to get a large (one is ~4GB) project imported into
subversion. I am having various problems and am getting frustrated.
Anyway, I finally got all the files added and committed to the
repository (three prior attempts failed). My current problem is that
when I do a checkout using https, I get the following error (several
hundred files are successfully checked out before the error):
A raidstor/install
.
.
.
A raidstor/install/pocono/act/demo/files
A raidstor/install/pocono/act/demo/files/raidstor.smb
A raidstor/install/pocono/act/demo/files/raidstor.smb/archive
svn: REPORT request failed on '/act/raidstor/!svn/vcc/default'
svn: REPORT of '/act/raidstor/!svn/vcc/default': Could not read response
body: SSL error: illegal padding (https://localhost)
I've tried it twice and I get the exact same error in the exact same
place in the repository. I haven't tried the file:// URL, but it
doesn't really help if that works anyway, because I need https. Here
are some details on my configuration:
1) RedHat 9.0
2) Apache version:
dimension4600 {~/blah}> /usr/sbin/httpd -version
Server version: Apache/2.0.48
Server built: Dec 25 2003 11:47:50
3) Subversion version:
dimension4600 {~/blah}> svn --version
svn, version 1.0.5 (r9954)
compiled Jun 10 2004, 22:39:54
Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet
(http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
- handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' schema
Let me know if you need any additional information.
Thanks for any help,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
This technique was not part of _my_ general SSH knowledge two weeks
ago. The SVN book contains several paragraphs on configuring apache --
some of which are not SVN specific and therefore available elsewhere.
Regardless, I did not realize the book was written for sysadmin types.
I am not a sysadmin -- I am a programmer. I also find it curious that
only one individual proposed this solution that makes use of such
"general SSH knowledge".<br>
<br>
I understand the difficulty of balancing what goes into a document and
what doesn't, but consider for a moment that this approach is also the
ONLY ONE AVAILABLE TO ME (recall the illegal padding bug in SVN/SSL)!
With that in mind, consider adding something like the second paragraph
below to the "SSH authentication and authorization" section (first
paragraph is verbatim from the book):<br>
<br>
[snip]<br>
<p>What's happening here is that the Subversion client is invoking a
local <b class="command">ssh</b> process, connecting to <tt
class="literal">host.example.com</tt>, authenticating as the user <tt
class="literal">harry</tt>, then spawning a private <b class="command">svnserve</b>
process on the remote machine, running as the user <tt class="literal">harry</tt>.
The <b class="command">svnserve</b> command is being invoked in tunnel
mode (<tt class="option">-t</tt>) and all network protocol is being “<span
class="quote">tunneled</span>” over the encrypted connection by <b
class="command">ssh</b>, the tunnel-agent. <b class="command">svnserve</b>
is aware that it's running as the user <tt class="literal">harry</tt>,
and if the client performs a commit, the authenticated username will be
attributed as the author of the new revision.<br>
</p>
<p>In some cases it is not desirable to provide system accounts to
certain users that require <b>ssh </b>access to the SVN repository.
The <b>sshd</b>'s <tt>authorized_keys2</tt> configuration file
provides a method for solving this problem. First, the person
associated with username <tt>harry </tt>generates a key using <b>ssh-keygen</b>
(or <b>puttygen </b>for TortoiseSVN). The system administrator then
adds this newly generated public key to the <tt>authorized_keys2</tt>
configuration file (<tt>~harry/.ssh/authorized_keys2</tt> for example)
and associates that key with the '<b>svnserve -t</b>' command. Consult
<b>sshd </b>documentation for details on exactly how to configure <tt>authorized_keys2
</tt>to run a particular command for a user generated key. When using
keys in this way, the person being granted SVN access does not know the
password for user <tt>harry</tt>'s system account<tt></tt>, thereby
preventing shell level access for the person associated with username <tt>harry</tt>.
In other words, the user can run only the command associated with his
key in the <tt>authorized_keys2</tt> file on the server.<br>
</p>
<p>[snip]<br>
</p>
<br>
Thanks,<br>
Andy <br>
<br>
<br>
<br>
Ben Collins-Sussman wrote:<br>
<blockquote type="cite"
cite="mid1092083065.30353.9.camel@localhost.localdomain">
<pre wrap="">On Mon, 2004-08-09 at 15:18, Andy Helten wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks again Faried. And SVN folks -- please consider documenting
this approach in the book.
</pre>
</blockquote>
<pre wrap=""><!---->
This technique is a part of general SSH knowledge; most sysadmins
already know about it.
I mean you're right, it *could* be in the book, but it becomes a tricky
business to to decide where to draw the line. We don't document how to
configure apache to use SSL client or server certs either -- because
that's covered by apache docs. In that same vein, if you're using ssh
to access a repository, we assume admins have access to ssh
documentation that explains some of the more advanced ssh key-sharing
techniques.
</pre>
</blockquote>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-08-09 at 15:18, Andy Helten wrote:
> Thanks again Faried. And SVN folks -- please consider documenting
> this approach in the book.
This technique is a part of general SSH knowledge; most sysadmins
already know about it.
I mean you're right, it *could* be in the book, but it becomes a tricky
business to to decide where to draw the line. We don't document how to
configure apache to use SSL client or server certs either -- because
that's covered by apache docs. In that same vein, if you're using ssh
to access a repository, we assume admins have access to ssh
documentation that explains some of the more advanced ssh key-sharing
techniques.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
I finally got around to trying this and it works perfectly! Thank you
Faried!
Why isn't this approach documented in the book? This is a viable
alternative to HTTPS for those of us that don't want to give system
accounts to folks accessing the repository but, at the same time, want
encrypted authentication as well as encrypted repository data
transfers. In fact, this method is much easier to implement than HTTPS
if you are not that familiar with apache (like myself). If you use
TortoiseSVN, however, it takes a little more work on the client side and
requires downloading 'puttygen'. But it is possible and it works.
Also, HTTPS obviously has problems for some of us with large
repositories and/or large files (remember the illegal padding issue that
started this thread?). This SSH approach does not suffer from that
issue. So, in other words, not only is this an elegant solution for my
situation -- it is the only solution for my situation.
Thanks again Faried. And SVN folks -- please consider documenting this
approach in the book.
Andy
Faried Nawaz wrote:
>On Thu, 29 Jul 2004 19:21:19 -0500, Andy Helten
><an...@dot21rts.com> wrote:
>
>
>
>>Thanks! I will give this a try. The only step I may have a problem
>>with is locking down a user account so that it can only access ssh. Is
>>this documented somewhere for Linux?
>>
>>
>
>To restrict the commands remote users can run,
>
>- have every user generate keys using ssh-keygen
>- put their pubkeys in the svn repo account's ~/.ssh/authorized_keys2
>- place 'command="/path/to/svnserve any-args"' on each line before the key data
>
>This is described in sshd's man page.
>
>
>Faried.
>
>
>
Re: Error checking out large repository -- illegal padding
Posted by Faried Nawaz <fa...@gmail.com>.
On Thu, 29 Jul 2004 19:21:19 -0500, Andy Helten
<an...@dot21rts.com> wrote:
> Thanks! I will give this a try. The only step I may have a problem
> with is locking down a user account so that it can only access ssh. Is
> this documented somewhere for Linux?
To restrict the commands remote users can run,
- have every user generate keys using ssh-keygen
- put their pubkeys in the svn repo account's ~/.ssh/authorized_keys2
- place 'command="/path/to/svnserve any-args"' on each line before the key data
This is described in sshd's man page.
Faried.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ed MacDonald <ed...@hotmail.com>.
I'm sure there are plenty of folks on this list and elsewhere that will give
you more comprehensive advice than I, but for starters make sure the user is
*not* in the "users" group. Restricted accounts are typically put in a
group called "nobody", "nogroup" or better yet in a group of their own with
the same name. Most inetd services are set up this way so that if they
become compromised, the attacker will have only limited rights on the
system. If you configure your svnuser similarly to the way the apache user
is configured, you should be doing OK.
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
Ed MacDonald wrote:
>If encryption is the only thing holding you back from using svnserve and the
>svn:// protocol, and you are worried about security setting up a bunch of
>system accounts, you could try this.
>
>1. Create 1 system account. Lock it down so that it has can open an ssh
>shell, but nothing else.
>2. Give the account info to your users and have them set up an ssh tunnel
>for the svnserv port:
> ssh -L 3690:host.example.com:3690
>3. Set up svnserve users db as normal.
>4. Pretend svnserve is local and proceed as normal:
> svn co svn://localhost/myrepo
>
>SSH will encrypt the traffic to the server for you, and you'll be using
>svnserve for auth/auth.
>
>
>
Thanks! I will give this a try. The only step I may have a problem
with is locking down a user account so that it can only access ssh. Is
this documented somewhere for Linux?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ed MacDonald <ed...@hotmail.com>.
If encryption is the only thing holding you back from using svnserve and the
svn:// protocol, and you are worried about security setting up a bunch of
system accounts, you could try this.
1. Create 1 system account. Lock it down so that it has can open an ssh
shell, but nothing else.
2. Give the account info to your users and have them set up an ssh tunnel
for the svnserv port:
ssh -L 3690:host.example.com:3690
3. Set up svnserve users db as normal.
4. Pretend svnserve is local and proceed as normal:
svn co svn://localhost/myrepo
SSH will encrypt the traffic to the server for you, and you'll be using
svnserve for auth/auth.
----- Original Message -----
From: "Andy Helten" <an...@dot21rts.com>
To: "Ben Collins-Sussman" <su...@collab.net>
Cc: <us...@subversion.tigris.org>
Sent: Thursday, July 29, 2004 5:55 PM
Subject: Re: Error checking out large repository -- illegal padding
>
>
> Ben Collins-Sussman wrote:
>
> > Andy Helten wrote:
> >
> >>> Read chapter 6 closely... these are separate methods of using
svnserve.
> >>>
> >> I did read it, about 4 times. I guess my assumption was that the
> >> svn:// access method did not encrypt the repository _data_ (did not
> >> find this explicitly described in the book). Am I wrong here? I
> >> understand authentication is secured by CRAM-MD5, but that doesn't
> >> imply the subsequent repository transfer is secure. Is it? If not,
> >> these access methods are hardly equivalent in terms of security.
> >>
> >
> > You are correct. A client speaking svn:// to an svnserve daemon is
> > not speaking over an encrypted link. (The password never travels over
> > the network in any form... but the main repository data isn't
encrypted.)
> >
> > I never claimed the two methods were equivalent in terms of security.
> > :-) I was just pointing out that one method requires an ssh system
> > account, one does not. Encryption is a separate topic.
> >
>
> So what am I left with? Here is my situation:
> 1) An SVN/Apache/SSL bug is preventing me from checking out my
> repository using HTTPS.
> 2) I am not comfortable with the insecure transfer of the
> repository using svn://
> 3) I don't really want to create system accounts for the folks
> accessing this repository (i.e. no svn+ssh:// if it requires system
> accounts for repository users)
>
> HELP!!!!
>
> Andy
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
Ben Collins-Sussman wrote:
> Andy Helten wrote:
>
>>> Read chapter 6 closely... these are separate methods of using svnserve.
>>>
>> I did read it, about 4 times. I guess my assumption was that the
>> svn:// access method did not encrypt the repository _data_ (did not
>> find this explicitly described in the book). Am I wrong here? I
>> understand authentication is secured by CRAM-MD5, but that doesn't
>> imply the subsequent repository transfer is secure. Is it? If not,
>> these access methods are hardly equivalent in terms of security.
>>
>
> You are correct. A client speaking svn:// to an svnserve daemon is
> not speaking over an encrypted link. (The password never travels over
> the network in any form... but the main repository data isn't encrypted.)
>
> I never claimed the two methods were equivalent in terms of security.
> :-) I was just pointing out that one method requires an ssh system
> account, one does not. Encryption is a separate topic.
>
So what am I left with? Here is my situation:
1) An SVN/Apache/SSL bug is preventing me from checking out my
repository using HTTPS.
2) I am not comfortable with the insecure transfer of the
repository using svn://
3) I don't really want to create system accounts for the folks
accessing this repository (i.e. no svn+ssh:// if it requires system
accounts for repository users)
HELP!!!!
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ben Collins-Sussman <su...@collab.net>.
Andy Helten wrote:
>> Read chapter 6 closely... these are separate methods of using svnserve.
>>
> I did read it, about 4 times. I guess my assumption was that the svn://
> access method did not encrypt the repository _data_ (did not find this
> explicitly described in the book). Am I wrong here? I understand
> authentication is secured by CRAM-MD5, but that doesn't imply the
> subsequent repository transfer is secure. Is it? If not, these access
> methods are hardly equivalent in terms of security.
>
You are correct. A client speaking svn:// to an svnserve daemon is not
speaking over an encrypted link. (The password never travels over the
network in any form... but the main repository data isn't encrypted.)
I never claimed the two methods were equivalent in terms of security.
:-) I was just pointing out that one method requires an ssh system
account, one does not. Encryption is a separate topic.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ben Collins-Sussman <su...@collab.net>.
Andy Helten wrote:
>
> All of this implies (to me anyway), that user 'harry' must have a system
> account. Am I missing something?
Yes. Chapter 6 explains there are two ways of invoking svnserve:
1. running svnserve as a daemon, and using its own built-in
authentication (CRAM-MD5) and private passwd file. No need for system
accounts. This is what svn:// urls are all about.
2. having svn clients run 'ssh remotehost svnserve', then talking to the
temporary svnserve process over the ssh tunnel. Users must have ssh
(system) accounts. This is what svn+ssh:// is all about.
Read chapter 6 closely... these are separate methods of using svnserve.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
kfogel@collab.net wrote:
>Andy Helten <an...@dot21rts.com> writes:
>
>
>>>Some random-but-not-completely-random ideas:
>>>
>>> 1. Turn off http-compression in ~/.subversion/servers
>>>
>>>
>>>
>>Assuming I did this correctly (set 'http-compression = no' in the
>>'[global]' section), this made no difference -- it failed exactly as
>>before in exactly the same place.
>>
>>
>
>You also made sure "[global]" itself was uncommented, right?
>
>
Yes, I uncommented [global].
>
>
>>> 2. I can't remember, did you try svn:// access with svnserve instead?
>>>
>>>
>>>
>>I did not try this before. I just tried it and it worked fine. This
>>is useful in that it seems to point the finger to the HTTPS
>>functionality, however, I would rather not use the svn:// access
>>method because I don't want to create system accounts for those
>>accessing this repository.
>>
>>
>
>??
>
>Using svn:// access should have nothing to do with creating system
>accounts for repository users.
>
>
Hmmm. This would be great if it is possible... please elaborate.
Obviously I want security (hence the usage of HTTPS), so how does one
provide security with svn:// access? The original route I took was using
svn+ssh://, but according to "The Book", this requires system accounts
(from the "SSH authentication and authorization" section):
-----
svnserve's built-in authentication can be very handy, because it avoids
the need to create real system accounts. On the other hand, some
administrators already have well-established SSH authentication
frameworks in place. In these situations, all of the project's users
already have system accounts and the ability to “SSH into” the server
machine.
.
[snip]
.
What's happening here is that the Subversion client is invoking a local
ssh process, connecting to host.example.com, authenticating as the user
harry, then spawning a private svnserve process on the remote machine,
running as the user harry. ..
-----
All of this implies (to me anyway), that user 'harry' must have a system
account. Am I missing something?
Thanks,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by kf...@collab.net.
Andy Helten <an...@dot21rts.com> writes:
> >Some random-but-not-completely-random ideas:
> >
> > 1. Turn off http-compression in ~/.subversion/servers
> >
> Assuming I did this correctly (set 'http-compression = no' in the
> '[global]' section), this made no difference -- it failed exactly as
> before in exactly the same place.
You also made sure "[global]" itself was uncommented, right?
> > 2. I can't remember, did you try svn:// access with svnserve instead?
> >
> I did not try this before. I just tried it and it worked fine. This
> is useful in that it seems to point the finger to the HTTPS
> functionality, however, I would rather not use the svn:// access
> method because I don't want to create system accounts for those
> accessing this repository.
??
Using svn:// access should have nothing to do with creating system
accounts for repository users.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
kfogel@collab.net wrote:
>Andy Helten <an...@dot21rts.com> writes:
>
>
>>Any other suggestions, other than going back to CVS (which is becoming
>>my only alternative)? Should I upgrade to subversion 1.0.6 on the
>>server?
>>
>>
>
>Some random-but-not-completely-random ideas:
>
> 1. Turn off http-compression in ~/.subversion/servers
>
Assuming I did this correctly (set 'http-compression = no' in the
'[global]' section), this made no difference -- it failed exactly as
before in exactly the same place.
>
> 2. I can't remember, did you try svn:// access with svnserve instead?
>
I did not try this before. I just tried it and it worked fine. This is
useful in that it seems to point the finger to the HTTPS functionality,
however, I would rather not use the svn:// access method because I don't
want to create system accounts for those accessing this repository.
Any other ideas of how to trouble shoot the HTTPS/SSL problem?
Thanks,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by kf...@collab.net.
Andy Helten <an...@dot21rts.com> writes:
> Any other suggestions, other than going back to CVS (which is becoming
> my only alternative)? Should I upgrade to subversion 1.0.6 on the
> server?
Some random-but-not-completely-random ideas:
1. Turn off http-compression in ~/.subversion/servers
2. I can't remember, did you try svn:// access with svnserve instead?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
Ben Collins-Sussman wrote:
>On Tue, 2004-07-27 at 15:47, Andy Helten wrote:
>
>
>
>>No change after installing neon-0.24.7 -- it fails exactly as before. I
>>didn't install subversion 1.0.6 because the binary RPM is not available
>>for RedHat 9.0 and I don't have time to go through the build process (I
>>am new to subversion). However, I will try 1.0.6 on Windows which
>>exhibits the same problem as the RedHat version. Of course, this is a
>>worthless test if the problem is on the server side (the same RedHat
>>machine I've been using to checkout).
>>
>>
Subversion 1.0.6 on Windows did not fix the problem -- it failed exactly
as it did with 1.0.5 under RedHat 9.
>It could very likely be a server error. My next suggestion is to
>upgrade to apache 2.0.50; IIRC, there were some odd SSL bugs fixed in
>apache recently.
>
>
Same problem in the exact same place in the repository after upgrading
to apache 2.0.50. In fact, I recreated the repository after installing
the new version of apache and the subsequent checkout again failed in
the same place, exactly as before. Here is my current configuration:
1) Apache
dimension4600 {httpd-2.0.50}> /usr/sbin/httpd -version
Server version: Apache/2.0.50
Server built: Jul 28 2004 11:28:56
2) SVN
svn, version 1.0.5 (r9954)
compiled Jun 10 2004, 22:39:54
** note this is neon-0.24.7:
/usr/lib/libneon.so.24.0.7
3) Still RedHat 9 (pretty much stock)
Any other suggestions, other than going back to CVS (which is becoming
my only alternative)? Should I upgrade to subversion 1.0.6 on the server?
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-07-27 at 15:47, Andy Helten wrote:
> No change after installing neon-0.24.7 -- it fails exactly as before. I
> didn't install subversion 1.0.6 because the binary RPM is not available
> for RedHat 9.0 and I don't have time to go through the build process (I
> am new to subversion). However, I will try 1.0.6 on Windows which
> exhibits the same problem as the RedHat version. Of course, this is a
> worthless test if the problem is on the server side (the same RedHat
> machine I've been using to checkout).
It could very likely be a server error. My next suggestion is to
upgrade to apache 2.0.50; IIRC, there were some odd SSL bugs fixed in
apache recently.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Andy Helten <an...@dot21rts.com>.
Ben Collins-Sussman wrote:
>On Tue, 2004-07-27 at 12:57, Andy Helten wrote:
>
>
>
>>svn: REPORT of '/act/raidstor/!svn/vcc/default': Could not read response
>>body: SSL error: illegal padding (https://localhost)
>>
>>
>
>Someone else recently had this problem, and Joe Orton (our http/ssl
>expert) wasn't able to figure out much:
>
> http://www.contactor.se/~dast/svnusers/archive-2004-07/0527.shtml
>
>Can you try two things anyway?
>
>1. try turning off http-compression in the [global] area of your
>~/.subversion/servers file.
>
>2. try upgrading to neon-0.24.7 (or svn 1.0.6, which comes bundled with
>it)
>
>
No change after installing neon-0.24.7 -- it fails exactly as before. I
didn't install subversion 1.0.6 because the binary RPM is not available
for RedHat 9.0 and I don't have time to go through the build process (I
am new to subversion). However, I will try 1.0.6 on Windows which
exhibits the same problem as the RedHat version. Of course, this is a
worthless test if the problem is on the server side (the same RedHat
machine I've been using to checkout).
>See if either of these things make a difference.
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Error checking out large repository -- illegal padding
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-07-27 at 12:57, Andy Helten wrote:
> svn: REPORT of '/act/raidstor/!svn/vcc/default': Could not read response
> body: SSL error: illegal padding (https://localhost)
Someone else recently had this problem, and Joe Orton (our http/ssl
expert) wasn't able to figure out much:
http://www.contactor.se/~dast/svnusers/archive-2004-07/0527.shtml
Can you try two things anyway?
1. try turning off http-compression in the [global] area of your
~/.subversion/servers file.
2. try upgrading to neon-0.24.7 (or svn 1.0.6, which comes bundled with
it)
See if either of these things make a difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org