You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alexey Neyman <st...@att.net> on 2019/02/26 01:41:13 UTC
Weird behavior of `svn --non-interactive`
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@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@yehat:~/work/lsk-ranges$ svn pl ^/
Properties on 'svn://svn.lynx.com/lynxsecure':
reviewboard:url
aneyman@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.
Re: Weird behavior of `svn --non-interactive`
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 27, 2019 at 01:27:15PM -0800, Alexey Neyman wrote:
> On 2/26/19 11:22 PM, Stefan Sperling wrote:
> > Since you have several password stores running, the best bet to get reliable
> > behaviour is to pick the one you actually want to use and configure it in
> > the ~/.subversion/config file.
> >
> > By the way, 'svn auth' will list cached credentials and also show which
> > password cache they are stored in.
>
> Ok, I left only gpg-agent configured since its the one giving the trouble.
>
> Issue still reproducible after a period of SVN inactivity.
The way gpg-agent works is that it tries to run a 'pinentry' program
to get the password. Once cached, after some time, the password expires.
What is supposed to happen after the password expires is that gpg-agent runs
the pinentry tool again to refresh its password store when SVN wants to
retrieve the password. However, with --non-interactive, SVN passes the
'--no-ask' option to gpg-agent which disables the pinentry program.
So what you could do in this situation is to manually invoke a pinentry
tool (there are several with various graphical and text frontends), type
the password, and SVN will keep working again for some time.
My conclusion is that the tools you are trying to use are at odds with
each other. You will want to use a more persistent SVN password store than
gpg-agent in your use case: plaintext storage, gnome-keyring, or kwallet
(the latter two should last throughout an entire desktop session).
The idea behind SVN's gpg-agent support is to avoid having the plaintext
password be written to disk. The password is kept in memory in plaintext
instead. But by design, this in-memory copy of the password will always
time out after a while and needs to be refreshed.
See also http://subversion.apache.org/docs/release-notes/1.8.html#gpg-agent
Re: Weird behavior of `svn --non-interactive`
Posted by Alexey Neyman <st...@att.net>.
On 2/26/19 11:22 PM, Stefan Sperling wrote:
> Since you have several password stores running, the best bet to get reliable
> behaviour is to pick the one you actually want to use and configure it in
> the ~/.subversion/config file.
>
> By the way, 'svn auth' will list cached credentials and also show which
> password cache they are stored in.
Ok, I left only gpg-agent configured since its the one giving the trouble.
Issue still reproducible after a period of SVN inactivity.
Regards,
Alexey.
Re: Weird behavior of `svn --non-interactive`
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 26, 2019 at 10:15:32PM -0800, Alexey Neyman wrote:
> 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...
Subversion does not know that you're running it in KDE.
By default it will prefer gpg-agent, detected by checking for the existence
of a shared socket (the location of which unfortunately changes between
versions of gpg-agent and between Linux distros). If that socket doesn't
exist or has no gpg-agent listening on it, SVN will keep trying other
auth stores in the default order given in the config file you've found.
> If you need me to build Subversion with some kind of debugging patch, let me
> know.
Since you have several password stores running, the best bet to get reliable
behaviour is to pick the one you actually want to use and configure it in
the ~/.subversion/config file.
By the way, 'svn auth' will list cached credentials and also show which
password cache they are stored in.
Re: Weird behavior of `svn --non-interactive`
Posted by Alexey Neyman <st...@att.net>.
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@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@yehat:~/work/lsk-ranges$ svn pl ^/
>>> Properties on 'svn://svn.lynx.com/lynxsecure':
>>> reviewboard:url
>>> aneyman@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@yehat:~/work/lsk-pristine$ svn --non-interactive pl
svn://svn/lynxsecure
Properties on 'svn://svn/lynxsecure':
reviewboard:url
aneyman@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.
Re: Weird behavior of `svn --non-interactive`
Posted by Alexey Neyman <st...@att.net>.
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@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@yehat:~/work/lsk-ranges$ svn pl ^/
>> Properties on 'svn://svn.lynx.com/lynxsecure':
>> reviewboard:url
>> aneyman@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?
Regards,
Alexey.
Re: Weird behavior of `svn --non-interactive`
Posted by Stefan Sperling <st...@elego.de>.
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@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@yehat:~/work/lsk-ranges$ svn pl ^/
> Properties on 'svn://svn.lynx.com/lynxsecure':
> reviewboard:url
> aneyman@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?