You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2014/05/15 16:16:13 UTC
svn doesn't cope well with read-only auth cache
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
Re: svn doesn't cope well with read-only auth cache
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> A couple of things:
A third thing:
In svn_config_write_auth_data() the realm is unconditionally added to
the input hash on the assumption that it is not present, overwritting
any realm that is present. After a successful write the realm is
removed from the hash on the assumption that it was not present
originally. If the write fails the realm is not removed from the hash.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn doesn't cope well with read-only auth cache
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> Not much interest it seems. Filed an issue, so this doesn't get forgotten:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4504
>
> I don't have the time nor expertise right now to work on this, but if
> someone else wants to have a go ... by all means.
Similar problem on Unix but without the 10 second delays. The delay
after the "Store password unencrypted" prompt is the WIN32 retry loop
invoked by svn_io_file_open() called from svn_config_write_auth_data().
What causes the delay before the "unencrypted" prompt?
A couple of things:
- svn_config_write_auth_data() is writing directly to the target file
rather than writing to a temporary file and renaming. Using the
rename mechanism would probably solve this problem is some cases
since our rename changes the permissions, however it would still fail
if the entire auth dir were readonly.
- svn_auth__simple_creds_cache_set() calls svn_config_write_auth_data()
and it is clearing the write error rather than returning it and there
is a comment questioning this behaviour:
if (err)
*saved = FALSE;
/* ### return error? */
svn_error_clear(err);
return SVN_NO_ERROR;
If we were to return the error it would generally cause the whole
operation to abort even though correct credentials had been supplied.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn doesn't cope well with read-only auth cache
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, May 16, 2014 at 2:47 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, May 15, 2014 at 4:16 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> 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
>>
>
> I'd like to add that, if there is any interest in helping users
> migrate from SVNKit to svn (like we are doing in our company now that
> IntelliJ IDEA finally has support for integrating with a commandline
> svn client), it would be good to fix this.
>
> Indeed, all users that have used SVNKit in the past, and then use a
> native client, will most likely run into this. With much head
> scratching and amazement at how extremely slow native svn is (wow, 30
> seconds just for executing 'svn ls', that's ... amazing).
>
Not much interest it seems. Filed an issue, so this doesn't get forgotten:
http://subversion.tigris.org/issues/show_bug.cgi?id=4504
I don't have the time nor expertise right now to work on this, but if
someone else wants to have a go ... by all means.
Keep in mind that a lot of users coming from SVNKit to svn will see
this as a performance issue in 'svn'. Not really a good first
impression when they switch to the "native side".
--
Johan
Re: svn doesn't cope well with read-only auth cache
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, May 15, 2014 at 4:16 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> 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
>
I'd like to add that, if there is any interest in helping users
migrate from SVNKit to svn (like we are doing in our company now that
IntelliJ IDEA finally has support for integrating with a commandline
svn client), it would be good to fix this.
Indeed, all users that have used SVNKit in the past, and then use a
native client, will most likely run into this. With much head
scratching and amazement at how extremely slow native svn is (wow, 30
seconds just for executing 'svn ls', that's ... amazing).
--
Johan