> On 06/20/2012 10:22 PM, kmra...@rockwellcollins.com wrote: > > Dmitry Pavlenko <pavle...@tmatesoft.com> wrote on 06/20/2012 11:14:58 AM: > >> simple_providers.c (svn_auth__simple_creds_cache_get): I propose to > >> drop all assignments > >> "need_to_save = FALSE" except the initial one; otherwise assignment > >> to FALSE may override existing > >> TRUE value. This may happen if default_username!=username and > >> default_password==password: in this > >> case need_to_save will be FALSE. Not very popular case, I guess, > but anyway. > >> > >> http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-06-20#l76 > >> > >> I also propose there (not covered by the patch) > >> * either not to use 'have_passtype' at all > >> * or always save credentials if have_passtype == FALSE > >> > >> Currently if have_passtype == FALSE (i.e. passsword encryption > >> format has been changed) new > >> credentials are saved only if old username differs from new username > >> (whatever old and new passwords are). > > > > Somehow I've also seen password cache files without a passtype. > > My recollection is that "passtype" isn't a required field, and is in fact > only used when storage of passwords has been offloaded to a third-party > keyring such as Gnome Keyring or KDE Wallet. Lack of a passtype field > indicates (again, IIRC) that the password should be stored directly in the > cache file. If, however, you have disabled plaintext password storage in > your runtime configuration, of course Subversion will honor that. The > result is that your password never gets cached.
In this case I did not have Gnome Keyring or KDE Wallet enabled and plaintext passwords were not disabled. The auth cache file did not change even though it did not contain a passtype or password field when I told it to save the password. It immediately started working again when I deleted the auth cache file so it was recreated. There were no permission problems as the user had rwx attributes on the file and I was able to edit the file before I manually deleted it. I just tested the simple test case of "svn ls https://..."; on the command line and the key/value pairs were correctly added when missing. However, if the password cache request is part of an svn:external (in this case references an https:// path where the original repo is checked out with http://) it appears to no longer correctly update the cache file. As a test, I simply manually removed the passtype and password keys and values. I'm not sure how to get a auth cache file without these keys, but it is definitely not correctly updated when used from an svn:external. I tested a 1.7.5 release built from source on RHEL5, Solaris 10, and Solaris 10 x86. Kevin R.
