> How many times does it have to be discussed until people finally
> understand that it is an absolute no-go to store passwords in plaintext
> without user consent?
Your argument has a valid basic point. Most GUI apps will not
remember a user's password unless the user checks a little box saying
so. If you don't check the box, the application will remember the
password until you close the application, which is reasonably
convenient. For Subversion to silently remember passwords without so
much as a peep (or, for that matter, a CLI for forgetting them) could
be considered a violation of reasonable user expectations.
However, some perspective is in order:
1. Subversion is not a GUI application. The longest the library can
remember a password in memory is the lifetime of the calling process,
which for command-line use is one operation. Nobody is going to
assent to reentering their password for every status, update,
checkout, and commit. Subversion could default to not remembering the
password, but it would be the first default everyone needs to change
when using it. People evaluating Subversion as an alternative to CVS
(which is just as nefarious in this department) would very quickly
develop the impression that Subversion is a pain in the ass to use,
whether or not they conciously agree with the default.
So, far from being an "absolute no-go," this default may well have
been critical to the success Subversion has had in the version control
ecosystem. I don't know if git, Monotone, Bazaar, etc. make the same
choice, to the extent that they have user/password network
authentication code at all, but I would be a little surprised if they
don't.
2. Implementing GNOME and KDE keychain support in the Subversion
libraries would be a good thing in principle, but:
- Good things don't automatically happen in free software; someone
has to do the work.
- This one is twice as hard as most things because there are two
APIs to code for rather than one.
- Keychain APIs which are part of GUI library may be designed with
the idea in mind that you are already a GUI app who has bought
into that particular GUI. We've seen issues under OSX due to this
assumption and we might see the same issues with the GNOME or KDE
APIs. How do we know which keychain API is appropriate to invoke
at run time, if any? Do they have ways of honoring
--non-interactive? There might be clean answers to these
questions or there might not.
3. If Subversion ever becomes a model citizen in this regard, will
that help to make password authentication secure in the organizations
which use it? No. Passwords are inherently a horrible choice for
authentication. Users write them down on pieces of paper and leave
them on their desks for janitors to find. People hand them over to
their secretaries and local technical support staff, share them with
their friends, and reveal them over the phone to anyone who asks
nicely. Applications give them out cheerfully to servers with
unverifiable SSL certificates. To be sure, every other option is hard
to deploy and marginalized, but you're never going to get a good
security infrastructure out of passwords. Getting all righteous about
Subversion's default is kind of like complaining about a particularly
dry day in Arizona.
4. Making everyone's password the same in every app using LDAP is
*especially* bad. It may be "standard," but standard security
practices are what makes identity theft such a thriving business in
today's world. Using the same passwords everywhere teaches users to
give up their organizational identity to pretty much any piece of
software which asks for it. Having learned the habit, your users are
almost certainly using their corporate passswords for their
livejournal and AIM accounts. Given that users are going to store
their Subversion passwords on disk one way or another, you would be
much better off assigning them randomly and treating them like a web
hosting provider treats database passwords: a shared secret between
the client and server apps.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-07 08:13:10 CEST