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

svn doesn't cope well with read-only auth cache

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 15 May 2014 16:16:13 +0200

If the file with the cached credentials (the file under <subversion
config dir>/auth/svn.simple) is read-only, 'svn' 1.8 (on Windows) will
behave as follows after a password change:

[[[
C:\>svn ls https://svn.example.com/svn
Authentication realm: <https://svn.example.com:443> SVN
Password for 'myself': ********
### delay of 10+ seconds

-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

   <https://svn.example.com:443> SVN

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'C:/Some/Path/Subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes

### another delay of 10+ seconds

branches/
tags/
trunk/
]]]

Some observations:

- The "can only be stored unencrypted" prompt is completely bogus. It
can't and it won't. After the above operation, the new password is not
stored. The next svn invocation will again prompt for the password.
BTW, with svn 1.7 the "can only be stored unencrypted" prompt does not
appear, so this is new-in-1.8 behavior.

- The two 10+ seconds delays: this is some kind of retry-loop. Looking
with ProcMon, I observed that during this delay svn.exe performs
exactly 101 attempts to write to the auth-cache file (which all fail
with ACCESS DENIED).

Shouldn't svn be able to write to the file anyway, even if it's
read-only, because I'm the owner? If not, a failure with a clear error
message would be better than the current behavior.

Now, the reason why this file happens to be read-only is because of
SVNKit. Apparently, SVNKit makes the file read-only when it caches
credentials. I have reported an issue in their issue tracker for this
[1], but in any case I think native svn should be able to handle this
better (users that switch between different clients can easily run
into this).

P.S.: I don't know if the same problem is present on other platforms
... I only tested this on Windows.

[1] http://issues.tmatesoft.com/issue/SVNKIT-508 -- SVNKit sets auth
cache file (svn.simple) read-only, causing problems for native svn

-- 
Johan
Received on 2014-05-17 03:43:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.