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
Received on 2019-02-28 09:27:29 CET