Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4504

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

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: ---
    • Fix Version/s: ---
    • Component/s: unknown
    • Labels:
      None

      Description

      See also http://svn.haxx.se/dev/archive-2014-05/0102.shtml.
      
      If the file with the cached credentials (the file under <subversion config
      dir>/auth/svn.simple) is read-only, 'svn' 1.8 (on Windows) works extremely
      slowly (and fails to update the credentials cache), and it gives a bogus "can
      only be stored unencrypted" prompt.
      
      [[[
      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, or which are migrating from SVNKit to svn, 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
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              jcorvel Johan Corveleyn
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: