#486527 SVN::Ra::new: colon instead of period in message for tunnel connection problems

Package:
libsvn1
Source:
subversion
Description:
Shared libraries used by Apache Subversion
Submitter:
Josef Spillner
Date:
2011-12-16 12:57:22 UTC
Severity:
minor
#486527#5
Date:
2008-06-16 16:24:38 UTC
From:
To:
I've cloned and modified a SVN repository (svn+ssh://...), all works fine. But I cannot
commit back my changes with git-svn dcommit. The error message looks
like that after the password query:

  Use of uninitialized value in concatenation (.) or string at
  /usr/lib/perl5/SVN/Core.pm line 579.
  Authorization failed:  at /usr/bin/git-svn line 3273

In the affected line it tries to call get_commit_editor, effectively in
line 3083:

  $self->SUPER::get_commit_editor($log, $cb, @lock, $pool);

The concatenation is probably hidden in the Perl bindings to SVN
somewhere. Using Perl 5.10.0.

#486527#10
Date:
2008-10-03 14:33:09 UTC
From:
To:
tags 486527 + moreinfo
quit

Hi, can you please add instructions on how to reproduce the issue by
pasting the commands you run?, or can you check with the 1.6.0.x version
from experimental whether it's been fixed upstream in the meantime?

Thanks, Gerrit.

#486527#17
Date:
2008-10-03 18:00:33 UTC
From:
To:
Am Freitag 03 Oktober 2008 16:33:09 schrieb Gerrit Pape:

I've tried to debug it further, and it looks like a combination of
1) PEBKAC,
2) non-cautious Perl programming and
3) not very useful SVN error messages.

1) The authorisation error was due to the line
	auth-access = read
instead of the default
	auth-access = write
in svnserve.conf. So not being able to commit was correct in that case.

2) Nevertheless something like the attached patch should be committed to
git-svn to let it handle errors without descriptions.

3) SVN should be improved to tell why authorisation failed.

During my tests I've also tried git-svn from experimental. Just a note that
the binary is located in /usr/lib/git-core. This is surely not intended?

Josef

#486527#26
Date:
2010-09-03 03:26:13 UTC
From:
To:
Hi Josef,

Josef Spillner wrote, two years ago:

Can you still reproduce this?  I tried first with file:/// and was able
to write, then with svn+ssh and received

 Authorization failed: Authorization failed at /usr/lib/git-core/git-svn line 4416

The underlying problem seems to be that in some circumstance libsvn
was/is returning an svn_error_t with message equal to NULL.  So it
would be nice to track it down.

#486527#35
Date:
2010-10-25 01:39:48 UTC
From:
To:
tags 486527 + unreproducible
quit

Hi again,

Josef Spillner wrote:

Ping?  I'd still be very interested in a reproduction recipe.

Marking unreproducible so heroes of bug reproduction know their work
would be appreciated. :)

#486527#40
Date:
2010-11-09 21:51:25 UTC
From:
To:
I hit this problem (I found
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422699 first, then
this bug).

Here's how I reproduced:

Setup an account on a remote system with /bin/false as a login shell:

remote# useradd -s /bin/false blah
remote# passwd blah
...

Try something that tickles the SVN/Core.pm code from the local system:
local# git svn init -Ttrunk svn+ssh://blah@remote/junk
...

#486527#45
Date:
2010-11-10 08:48:47 UTC
From:
To:
tags 486527 - moreinfo unreproducible
found 486527 git/1:1.7.2.3-2
quit

Quentin Neill wrote:

Nice!  Yes, I can reproduce this.
Jonathan

libsvn-perl version: 1.6.12dfsg-2

#486527#54
Date:
2011-12-16 12:53:27 UTC
From:
To:
severity 486527 minor
retitle 486527 SVN::Ra::new: colon instead of period in message for tunnel connection problems
reassign 486527 libsvn1 1.6.17dfsg-3
quit

Hi,

Thanks again for the reproduction recipe.  With libsvn-perl
1.6.17dfsg-3:

	$ git svn init -Ttrunk svn+ssh://blah@localhost/junk
	blah@localhost's password:
	Network connection closed unexpectedly: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. at /usr/lib/git-core/git-svn line 2299

So the cause (svn_error_t with NULL message) is still present and
still produces a weird symptom.  This time the symptom is less severe
than before: a goofy error message with colon promising explanation
and no delivery.  So the fix to bug#422699 indeed improved things.

The svn_error_t comes from subversion/libsvn_ra_svn/marshal.c, in
readbuf_input():

  SVN_ERR(svn_ra_svn__stream_read(conn->stream, data, len));
  if (*len == 0)
    return svn_error_create(SVN_ERR_RA_SVN_CONNECTION_CLOSED, NULL, NULL);

This regression seems to have come about in r870846.  I'm not familiar
enough with libsvn to say if libsvn should be putting a message in the
svn_error_t object or the bindings should use a period instead of a
colon when the message is not present.

Hope that helps,
Jonathan