[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Obfuscate auth info

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-10-19 17:32:09 CEST

On Thu, Oct 19, 2006 at 01:44:04AM -0700, David Anderson wrote:
> +1, see Karl's explanation on this. He explains very plainly why this
> is a win in just about any situation. I'd just like to note that we
> are not treating this as an excuse to not investigat password manager
> for !(win32 || OSX). But until that investigation takes place, this is
> a silencer for the recurring complaints the users@ list has had for
> years.

I agree, though not strongly enough to push this feature through myself
(I'm +0 on it - my only original interest was in seeing how hard it was
to code).

I agree with almost all of your review comments, though I'll leave
producing an updated patch to someone who really wants to argue for the

A few notes from that review:

> >
> >-/* The password type used by the windows simple auth provider, passed
> >- into simple_first_creds_helper and simple_save_creds_helper. */
> >-static const char windows_crypto_type[] = "wincrypt";
> >-
> Why is this removed? Are we replacing "wincrypt" with this 'universal'
> obfuscator?

No, that was a stray hunk in this patch - it comes from r22024.

> >+
> >+/* Get cached obfuscated credentials from the simple provider's cache. */
> Should this read "from the obfuscated provider's cache" ?

No, I don't think so. The wincrypt, keychain, and now obfuscated simple
providers all use the plaintext simple provider's cache (that is, they
store the data in svn.simple/...).

> Good job. As an aside, I motion that the simple auth provider be
> altered to use the obfuscated set_password. That way, the cache is
> progressively updated to obfuscated storage when touched. The change
> should be a one-or-so-liner.

I thought of that, but that would unfortunately be a layering violation
- there's no reason to assume that the client wants to use the
obfuscating provider (and if they don't, they won't be able to read back
out the password they've stored).

However, I would really like a solution to this problem in general,
because the Keychain and wincrypt providers are also affected by this --
unless someone cleans out all the unencrypted auth data, we're not more
secure than 1.0.


  • application/pgp-signature attachment: stored
Received on Thu Oct 19 17:32:39 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.