Re: Weird behavior of `svn --non-interactive`
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`
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`
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`
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`
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`
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?
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.