> On 06/20/2012 10:22 PM, kmradke_at_rockwellcollins.com wrote:
> > Dmitry Pavlenko <pavlenko_at_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.
Received on 2012-06-21 15:53:02 CEST