Hi Daniel,
On Mon, Aug 19, 2013 at 12:06 PM, Daniel Shahaf <danie...@elego.de> wrote:
> Mark Tsuchida wrote on Mon, Aug 19, 2013 at 11:19:42 -0700:
>> svn co https://our.server.com/svn/myrepo/trunk -> Requires
>> authentication with client 1.8.x but not with 1.6.x or 1.7.x
>> svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1
>> svn list https://our.server.com/svn/myrepo -> Requires auth, as expected
>>
>> The 1.8.x clients can successfully check out myrepo/trunk if a
>> username and password are given, for a user with access to the
>> repository root.
[...]
> Information that might be relevant includes:
>
> - The authz file
> - The <Location> block
Thanks for the suggestions. I've been able to simplify the authz file
to the following without changing the problematic behavior:
-- begin --
[myrepo:/]
mark = rw
* =
[myrepo:/trunk]
* = r
mark = rw
[/]
mark = rw
* =
-- end --
The <location> block looks like this:
-- begin --
<Location /svn>
DAV svn
SVNParentPath /home/svnroot
SSLRequireSSL
AuthType Basic
AuthName "Repository"
AuthUserFile /etc/httpd/httpdsvnpasswd
AuthzSVNAccessFile /etc/httpd/svnAccess
Satisfy Any
Require valid-user
</Location>
-- end --
> - Whether 1.7.x reproduces the problem under either serf and neon (did
> you test with each of them?)
I tried compiling SVN 1.7.11 with serf 1.3.1 and neon 0.29.6. Both work fine:
$ ~/tmp/bin/svn --config-option servers:global:http-library=serf co
https://our.server.com/svn/myrepo/trunk
# -> OK
$ ~/tmp/bin/svn --config-option servers:global:http-library=neon co
https://our.server.com/svn/myrepo/trunk
# -> OK
> - Whether the problem reproduces with 1.6.17
>
> Also, you should upgrade to at least 1.6.17, if not 1.7.11 or 1.8.1, to
> pick up fixes to security issues. (An upgrade to at least 1.7 could
> easily fix your problem, too, since it'll enable 1.7+ clients to talk
> HTTPv2, which will avoid the HTTP-non-v2 compatibility codepath (unless
> you have 1.6 clients too...).)
I haven't had a chance to test this yet. I see your point about
upgrading, but it would be nice if we could keep 1.6.11, which is the
default version on CentOS/RHEL 6.4, unless this turns out to be a true
incompatibility.
Mark
