The following is a bug report for triage and review. I've been unable to
locate an adequate fix or discussion for this issue; however, I have
found an acceptable workaround.
When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17 (r1128011)
appear to handle authentication challenges on commit in a non-robust
manner.
The testing that follows is against a Google Code project that I
currently maintain code for, which may be found here:
http://code.google.com/p/rf-ace/
Here is a sparse log of a fresh checkout and commit using SVN version
1.6.16 (r1073529) on OSX. All builds are inclusive of ra-neon:
$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn
--username trobin...@systemsbiology.org
... file data ...
Checked out revision 265.
$ cd rf-ace.svn
... make some changes to existing files ...
$ svn commit
... write the log in my default editor ...
"svn-commit.tmp" 35L, 1392C written
svn: Commit failed (details follow):
svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf'
forbidden
svn: Your commit message was left in a temporary file:
svn:
'/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'
This same behavior exhibits in 1.6.17 (r1128011), and when a log message
is given using -m.
Here is an approximately equivalent session using SVN version 1.6.11
(r934486) in CentOS 6:
$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace
--username trobin...@systemsbiology.org
... file data ...
Checked out revision 265.
$ cd rf-ace
... make some changes to existing files ...
$ svn up
... file data ...
Checked out revision 269.
$ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
Authentication realm: <https://rf-ace.googlecode.com:443> Google Code
Subversion Repository
Password for 'trobinso':
[In which I press enter here to fall back to explicit Username
specification]
Authentication realm: <https://rf-ace.googlecode.com:443> Google Code
Subversion Repository
Username: trobin...@systemsbiology.org
Password for 'trobin...@systemsbiology.org': [My correct password is
entered here]
Sending test/argparse_test.hpp
Transmitting file data .
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:
<https://rf-ace.googlecode.com:443> Google Code Subversion Repository
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
'/my/home/directory/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes [I know, I know. See my notes
below.]
Committed revision 270.
Note that on personal dev boxes, authentication information has been
stored locally in ~/.subversion (which, I note as an aside, is something
I only do with definedly-insecure passwords like those automatically
generated by Google Code on machines that are for internal development
only). This, too, may cause the issue.
My workaround, of course, is obvious. For all versions of SVN,
specifying the username explicitly (a la "--username
trobin...@systemsbiology.org") immediately follows up with a challenge
for my password. I have not verified if this resolves future commit
attempts.
The catalyst for the issue is Google's recent transition of Google Code
login system to that of Google Accounts. In this case, for conflicting
users, the issue only exposed itself when we cut back over to our
original usernames, and I would speculate this occurs if (and only if)
the same username is specified with an alternate password (as mine was).
Thus, we have a compelling case for potentially spurious handling of
conflicting user credentials, as may well expose themselves in the
migration of Google Code SVN repositories. In which I would speculate
that the right approach would be to invalidate the cached copy of the
user's credentials and re-challenge both the username and the password.
Ideally, this behavior would be grafted into a configuration value,
should it not already exist.
As you might expect, searching for this information is nigh-impossible
for this exact edge condition, and you will probably receive several
queries of a similar nature as Google continues to transition accounts
with access to Google Code. Thus my posting of this bug report: assuming
my hypothesis is correct, it's a case of inconsistent credential
handling that results in a non-intuitive error message. As above, this
would be better handled by configurable invalidation of the user's
cached credentials.
Thus concludes my report. Please copy me on any mail you expect for me
to see, as I am not a subscriber to this list.
Best regards,
- Tom Robinson
