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
change.
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.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Thu Oct 19 17:32:39 2006