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

Re: Weird behavior of `svn --non-interactive`

From: Alexey Neyman <stilor_at_att.net>
Date: Tue, 26 Feb 2019 22:15:32 -0800

On 2/26/19 8:42 PM, Alexey Neyman wrote:
> On 2/26/19 12:07 AM, Stefan Sperling wrote:
>> On Mon, Feb 25, 2019 at 05:41:13PM -0800, Alexey Neyman wrote:
>>> Hi all,
>>>
>>> I am encountering some weird behavior after upgrading my workstation to
>>> Ubuntu 18.10 - which also upgraded the SVN to version 1.10.0
>>> (r1827917).
>>>
>>> An attempt to query anything from the server using the
>>> `--non-interactive`
>>> flag fails, unless there has been a recent "interactive session"
>>> with this
>>> server.
>>>
>>> aneyman_at_yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/
>>> svn: E170013: Unable to connect to a repository at URL
>>> 'svn://svn.lynx.com/lynxsecure'
>>> svn: E170001: Can't get username or password
>>> aneyman_at_yehat:~/work/lsk-ranges$ svn pl ^/
>>> Properties on 'svn://svn.lynx.com/lynxsecure':
>>>    reviewboard:url
>>> aneyman_at_yehat:~/work/lsk-ranges$ svn --non-interactive pl ^/
>>> Properties on 'svn://svn.lynx.com/lynxsecure':
>>>    reviewboard:url
>>>
>>> This happens during various actions by `rbt` (RBTools) which runs
>>> svn with
>>> --non-interactive flag.
>>>
>>> Note that the "interactive" run of svn does not even query the
>>> password - it
>>> happily uses the stored password and proceeds. Why isn't the
>>> non-interactive
>>> invocation doing the same?
>>>
>>> I also tried the development version of Subversion a couple of weeks
>>> ago; it
>>> has the same behavior.
>>>
>>> Regards,
>>> Alexey.
>> I agree this looks like a bug.
>>
>> To find the bug we'll likely need to know which password store is
>> actually being used by your installation of Subversion.
>> plaintext? gpg-agent? gnome-keyring? kwallet?
>>
> SVN configuration doesn't have the password store option specified, so
> I assume it is using the default - according to the comment in the
> .subversion/config, it is "gpg-agent,gnome-keyring,kwallet". I have
> kwallet installed and configured with empty master password. I also
> have gpg-agent and gnome-keyring installed, but I don't think I ever
> used either of them on that machine. How can I check which store was
> SVN actually trying to use at the time it happens?
Actually, it is gpg-agent.

I went to $HOME/.subversion/auth/svn.simple; somehow there is a mixture
of files using gpg-agent and gnome-keyring authentication methods. I
found the one corresponding to the repository URL; it has:

K 8
passtype
V 9
gpg-agent

Funny thing is, I found another file in that directory that refers to
the same repository, just with a different URL (one is using the FQDN of
the Subversion server, the other just the hostname). That other file
uses gnome-keyring and it seems to work fine:

aneyman_at_yehat:~/work/lsk-pristine$ svn --non-interactive pl
svn://svn/lynxsecure
Properties on 'svn://svn/lynxsecure':
   reviewboard:url
aneyman_at_yehat:~/work/lsk-pristine$ svn --non-interactive pl
svn://svn.lynx.com/lynxsecure
svn: E170013: Unable to connect to a repository at URL
'svn://svn.lynx.com/lynxsecure'
svn: E170001: Can't get username or password

How does SVN decide when to use gpg-agent and when to use gnome-keyring?
By the way, I am running KDE so I'd assume the kwallet would be the
default - but it isn't...

If you need me to build Subversion with some kind of debugging patch,
let me know.

Regards,
Alexey.
Received on 2019-02-27 07:15:55 CET

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.