On Mon, Jun 09, 2008 at 01:45:21PM -0700, Jack Repenning wrote:
>
> On Jun 9, 2008, at 12:26 PM, Stefan Sperling wrote:
>
> > 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.
>
> Not sure I parse this, so just for clarity: svnX does use the command
> line (building command-line invocations and parsing command-line
> output).
What I said above only applies to clients that use the API directly.
> > 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).
>
> That's going to be a problem for the likes of svnX, since they do
> everything --non-interactive, yet rely upon SVN to cache credentials
> (and users would prefer this cache be secure).
Well, what I said above lacks an important exception:
Our command line client only defaults to not storing plaintext
passwords in non-interactive mode if the user has not configured
any other behaviour in the config file.
Once users configure Subversion to use the plaintext cache,
the creds will be stored there. So for svnX, the plaintext cache
isn't broken, it just won't be used by default anymore.
It would be nicer if they could use Keychain, of course. But because
of the --non-interactive bug we're seeing with the Keychain API I don't
see much chance that we can make this work from our side.
We (that includes us as well as the svnX developer and user community)
need to get Apple to fix this.
Or people who are affected by this decide to cut their ties to a
closed-source vendor and switch to a free OS where this kind of bug
could be comparatively trivially fixed by the end user *cough* ;)
> > 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 :/
>
> Not the shell's history, since these wrappers don't use an interactive
> shell; they invoke the command-line tool via popen() (or language-
> specific equivalent). There may be a copy of the user's login shell
> involved there, but it's not interactive and doesn't save history.
> There's some risk of leakage through "ps" and the like.
OK, but leakage via ps is also pretty bad.
> I am now trying to
> represent these several GUI wrapper developer communities by proxy.
> I've tried to contact them, without response, but since many of my
> users are also users of theirs, I want these things to work right.
They should certainly work right. But not at the expense of leaking
plaintext passwords to disk without the user's consent. That's what
the dont-save-plaintext-passwords-by-default branch was all about,
after all.
If anyone has any further questions regarding the new plaintext caching
behaviour in 1.6 and its consequences, don't hesitate to ask.
We certainly don't want to break 3rd party tools with this.
But 3rd party client developers may need to take some action in order
for plaintext password caching to work properly with their client.
They need to implement a way our library can use to ask the user
whether plaintext password caching is OK, in case users do not indicate
any preference in their config files.
How 3rd party developers can do this is straightforward and well
documented in our API, so I don't expect many problems with clients
that use the API directly.
As for tools that simply wrap the command line client, they will
get safe default behaviour anyway. It's unfortunate that the Keychain
cache is currently so broken that svnX can't use it, but that's not
our fault.
Stefan
- application/pgp-signature attachment: stored
Received on 2008-06-10 12:45:44 CEST