On 10/18/06, Alex Holst <email@example.com> wrote:
> Quoting Max Bowsher (firstname.lastname@example.org):
> > Alex Holst wrote:
> > > I beg of you: Please don't introduce this obfuscation to auth data in
> > > Subversion.
> > Question: If you feel so strongly about it, are you also campaigning for
> > the trivial obfuscation to be removed from CVS?
> No. First, my customers don't use CVS, so I don't really care. Secondly,
> I suspect it would be much harder to remove features introduced many
> years ago in a dated scm tool than it would be to prevent the
> introduction of questionable obfuscation features in a newer, modern scm
> I also think a mistake made years ago shouldn't be made again.
There is a separate change proposed (at the Summit) to not store
effectively-cleartext authn data by default. That still has to be
discussed here, of course, and it's independent of this obfuscation
change, but it's yet another step in the right direction.
In the meantime, obfuscating the auth data seems like an unambiguous
win to me:
1. Organizations that currently don't adopt Subversion because of
this (and there are some) will now be willing to adopt it. More
users is good. They understand that it's still cleartext, but
they want to at least avoid accidental compromises.
2. Users are no more likely to think that their data is truly
encrypted after this change than before, thanks to the warning.
Sure, most people will never see the warning, but anyone who
looks at their password will also see the warning, which is all
that matters. (Yes, the few people who use 'grep' to look for
their password won't find it and may go away thinking that
therefore it's not stored in cleartext. I'm willing to live
with this slight "regression".)
3. We will stop wasting users@ list time with this issue every few
> I claim that, regardless of what warning might appear in the password
> file, obfuscated auth data will result in many users/admins/managers
> thinking it takes a lot of effort to recover their password. Anyone who
> has ever dealt with users or managers knows I'm not kidding.
> Which is greater? The cost of educating users who post to the mailing
> list about clear text passwords or the very likely possibility that
> a user will shoot themselves in the foot because they didn't feel a need
> to investigate ssh keys, certs or kerberos auth?
These two paragraphs look like they're talking about the same thing, but
really they're talking about different things.
Easy password recovery was never a design goal of the current system
anyway, it's just an unintentional consequence of not obfuscating the
passwords. And it is unrelated to the phenomenon of a user mistakenly
thinking that their password is stored securely; the latter is highly unlikely
to happen because of the warning comment in the password file.
(I couldn't quite tell if you were implying some sort of connection between
ease of password recovery and users mistakenly assuming secure storage,
but I didn't see any other way to read those two paragraphs.)
Anyway, I give an enthusiastic +1 to the change!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Oct 19 07:46:45 2006