{"thread":{"id":"28166","subject":"BUG: Inconsistent handling of challenge-on-commit in git-svn","startedAt":"2011-08-19T21:29:17Z","lastAt":"2011-08-19T21:29:17Z","messageCount":1,"participants":["Thomas Robinson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"173884","messageId":"4E4ED5AD.6000209@systemsbiology.org","threadId":"28166","inReplyTo":null,"subject":"BUG: Inconsistent handling of challenge-on-commit in git-svn","fromName":"Thomas Robinson","fromEmail":"trobinson@systemsbiology.org","sentAt":"2011-08-19T21:29:17Z","receivedAt":"2011-08-19T21:29:17Z","isPatch":false,"sender":{"key":"trobinson@systemsbiology.org","avatar":null},"body":"Additionally reporting the issue here, because git-svn also fails to \nhandle this issue gracefully. Worry not; this is something that SVN \nshould fix upstream as well.\n\nI've noticed that, when a conflicting user is specified in what should \nbe an invalidatable portion of SVN's authentication cache, git-svn will \nfail the same obscure error thrown by the SVN binary:\n\n$ git svn dcommit\nCommitting to https://rf-ace.googlecode.com/svn/trunk ...\nURL access forbidden for unknown reason: access to \n'/svn/!svn/act/b039ca42-f359-41d0-9523-bbbca5266026' forbidden at \n/usr/local/git/libexec/git-core/git-svn line 4472\n\n\nThe difference, of course, is that explicitly passing my credentials via \n--username appears to be silently ignored, such that my workaround \nposited to the SVN team below *doesn't* work in Git SVN.\n\nThis, of course, contradicts the information I could find while \nsearching for the problem, notably here:\nhttp://groups.google.com/group/google-code-hosting/browse_thread/thread/72b6875507dca1d1\n\n\nAs such, it is possible that the cache challenge is spuriously taking \nprecedence over credentials specified by --username, causing an \nirresolvable conflict until a user's SVN cache is cleared. This is, \nneedless to say, less than ideal.\n\n\nMy original bug report to the SVN user community follows below. Thank \nyou for taking the time to read this.\n\n- Tom Robinson\n\n---\nThe following is a bug report for triage and review. I've been unable to \nlocate an adequate fix or discussion for this issue; however, I have \nfound an acceptable workaround.\n\n\nWhen built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17 (r1128011) \nappear to handle authentication challenges on commit in a non-robust manner.\n\nThe testing that follows is against a Google Code project that I \ncurrently maintain code for, which may be found here:\nhttp://code.google.com/p/rf-ace/\n\n\nHere is a sparse log of a fresh checkout and commit using SVN version \n1.6.16 (r1073529) on OSX. All builds are inclusive of ra-neon:\n\n$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn \n--username trobinson@systemsbiology.org\n... file data ...\nChecked out revision 265.\n\n$ cd rf-ace.svn\n... make some changes to existing files ...\n\n$ svn commit\n... write the log in my default editor ...\n\n\"svn-commit.tmp\" 35L, 1392C written\nsvn: Commit failed (details follow):\nsvn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf' \nforbidden\nsvn: Your commit message was left in a temporary file:\nsvn: '/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'\n\nThis same behavior exhibits in 1.6.17 (r1128011), and when a log message \nis given using -m.\n\n\n\nHere is an approximately equivalent session using SVN version 1.6.11 \n(r934486) in CentOS 6:\n\n$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace \n--username trobinson@systemsbiology.org\n... file data ...\nChecked out revision 265.\n\n$ cd rf-ace\n... make some changes to existing files ...\n\n$ svn up\n... file data ...\nChecked out revision 269.\n\n$ svn commit -m \"Irrelevant log message you can find in r270 of rf-ace\"\nAuthentication realm: <https://rf-ace.googlecode.com:443> Google Code \nSubversion Repository\nPassword for 'trobinso':\n[In which I press enter here to fall back to explicit Username \nspecification]\n\nAuthentication realm: <https://rf-ace.googlecode.com:443> Google Code \nSubversion Repository\nUsername: trobinson@systemsbiology.org\nPassword for 'trobinson@systemsbiology.org': [My correct password is \nentered here]\nSending        test/argparse_test.hpp\nTransmitting file data .\n-----------------------------------------------------------------------\nATTENTION!  Your password for authentication realm:\n\n    <https://rf-ace.googlecode.com:443> Google Code Subversion Repository\n\ncan only be stored to disk unencrypted!  You are advised to configure\nyour system so that Subversion can store passwords encrypted, if\npossible.  See the documentation for details.\n\nYou can avoid future appearances of this warning by setting the value\nof the 'store-plaintext-passwords' option to either 'yes' or 'no' in\n'/my/home/directory/.subversion/servers'.\n-----------------------------------------------------------------------\nStore password unencrypted (yes/no)? yes [I know, I know. See my notes \nbelow.]\n\nCommitted revision 270.\n\n\nNote that on personal dev boxes, authentication information has been \nstored locally in ~/.subversion (which, I note as an aside, is something \nI only do with definedly-insecure passwords like those automatically \ngenerated by Google Code on machines that are for internal development \nonly). This, too, may cause the issue.\n\nMy workaround, of course, is obvious. For all versions of SVN, \nspecifying the username explicitly (a la \"--username \ntrobinson@systemsbiology.org\") immediately follows up with a challenge \nfor my password. I have not verified if this resolves future commit \nattempts.\n\n\nThe catalyst for the issue is Google's recent transition of Google Code \nlogin system to that of Google Accounts. In this case, for conflicting \nusers, the issue only exposed itself when we cut back over to our \noriginal usernames, and I would speculate this occurs if (and only if)\nthe same username is specified with an alternate password (as mine was).\n\nThus, we have a compelling case for potentially spurious handling of \nconflicting user credentials, as may well expose themselves in the \nmigration of Google Code SVN repositories. In which I would speculate \nthat the right approach would be to invalidate the cached copy of the \nuser's credentials and re-challenge both the username and the password. \nIdeally, this behavior would be grafted into a configuration value, \nshould it not already exist.\n\n\nAs you might expect, searching for this information is nigh-impossible \nfor this exact edge condition, and you will probably receive several \nqueries of a similar nature as Google continues to transition accounts \nwith access to Google Code. Thus my posting of this bug report: assuming \nmy hypothesis is correct, it's a case of inconsistent credential \nhandling that results in a non-intuitive error message. As above, this \nwould be better handled by configurable invalidation of the user's \ncached credentials.\n\nThus concludes my report. Please copy me on any mail you expect for me \nto see, as I am not a subscriber to this list.\n\n\nBest regards,\n- Tom Robinson\n"}]}