On Mon, Jun 09, 2008 at 10:32:33AM -0700, Jack Repenning wrote:
> > ------- Additional comments from danielsh_at_tigris.org Mon Jun 9
> > 01:05:37 -0700 2008 -------
> > In non-interactive mode, it defaults to saving it (for
> > compatibility)
That's wrong. See the comments in these code snippets from
subversion/libsvn_subr/simple_providers.c (on trunk).
They document the current behaviour.
if (svn_cstring_casecmp(store_plaintext_passwords,
SVN_CONFIG_ASK) == 0)
{
if (non_interactive)
/* In non-interactive mode, the default behaviour is
* to not store the password, because it is usually
* passed on the command line. */
may_save_password = FALSE;
else if (b->plaintext_prompt_func)
{
/* We're interactive, and the client provided a
* prompt callback. So we can ask the user.
*
// some stuff omitted here, this function call asks the user:
SVN_ERR((*b->plaintext_prompt_func)(&may_save_password,
realmstring,
b->prompt_baton,
pool));
// some stuff omitted here
}
else
{
/* TODO: We might want to default to not storing if the
* prompt callback is NULL, i.e. have may_save_password
* default to FALSE here, in order to force clients to
* implement the callback.
*
* This would change the semantics of old API though.
*
* So for now, clients that don't implement the callback
* and provide no explicit value for
* SVN_AUTH_PARAM_STORE_PLAINTEXT_PASSWORDS
* cause unencrypted passwords to be stored by default.
* Needless to say, our own client is sane, but who knows
* what other clients are doing.
*/
may_save_password = TRUE;
}
The above comment means that if you use any client other than the
svn command line client (such as svnX), by the time we release 1.6,
you should ask the developers of your client to implement the callback
that asks the user whether saving passwords in plaintext is OK.
Else their client will cause our library to save the password in plaintext,
except in --non-interactive mode. We don't ever store plaintext passwords
in non-interactive mode anymore in current trunk (and thus 1.6).
> Here's the necessary test case, in case it's not apparent in the issue:
>
> 1. OS X Tiger + SVN 1.4.x history, with some credentials stored in
> keychain, none in ~/.subversion/auth/svn.simple
> 2. also nuke relevant creds from Apple Keychain
> 3. upgrade to Leopard (or, if you're already on Leopard, nuke any auth/
> svn.simple/* containing passwords)
> 4. no 1.5-specific configuration changes (no use of new "store-
> plaintext-passwords" setting)
That setting is trunk-specific, not 1.5-specific :)
> 5. build SVN trunk
> 6. install svnX, preferences point to your trunk SVN
> 7. Use svnX to browse some repository that requires credentials to
> browse
>
> Definition of "fail":
> Password appears in ~/.subversion/auth/svn.simple/*
>
> Definition of "pass":
> No password stored. I could live with failure of the operation,
> though it would be really cool if the op worked and the password was
> properly stuffed into the keychain
As explained above, if the tool uses --non-interactive, the password
should not be stored in plaintext with svn from current trunk.
So I guess Daniel is right -- this could be used to somewhat steer around
the fact that SecKeychainSetUserInteractionAllowed(FALSE); renders Keychain
unable to give us the cached password for some bizarre reason.
(For those who don't know what I'm talking about, see
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133862
which details the reason behind Jack's problem).
But isn't there a catch? To authenticate during --non-interactive without
having access to a cached password from Keychain, you need to pass
--password on the command line. Which probably means that your password
is saved in your shell's history instead of the svn auth area, right?
No idea which is the lesser evil :/
Stefan
- application/pgp-signature attachment: stored
Received on 2008-06-09 21:26:39 CEST