Ben Collins-Sussman wrote:
>
> On Nov 12, 2004, at 2:14 PM, kfogel@collab.net wrote:
>
>> Is this encryption based on the user's password or something?
>
No, Windows maintains encryption keys for each user (these can be
changed, of course). Someone would need physical access to the system
_and_ would have to boot into a non-Windows system to get at the key.
Doing so remotely wouldn't work.
In any case, the user doesn't have to type her password to get at the
file contents, but nobody else can read the file. Backup utilities
transfer the encrypted contents.
> My question is: what problem are we trying to solve?
Preventing malicious code (or users) from getting at the password.
> Through repeated discussions with users, my impression is that the
> problem is that an administrator (or perhaps someone sitting with you
> at your terminal) can accidentally glance at a cleartext password.
Hah. Security through obscurity again. :-(
At work, I've set up the SVN server on a linux box, but authentication
is with the Windows username and password (with the repos on https:),
because I don't want to maintain yet another auth database. I tell all
the users to encrypt their auth directories, because that Windows
password gives you access to lots more than just Subversion, and there
is no chance I'd convince them to type their password every time they
touch the repo.
> CVS solves this particular problem by doing a trivial rot-13-esque
> scrambling on the contents of .cvspass. Not real crypto, just enough
> to prevent accidental glances. Couldn't we do something like that?
> It would be simple It would be portable -- not requiring any
> OS-specific code.
Yes. And it would be useless for my purpose. We've all agreed before
that security through obscurity is a cure worse than the disease.
As to the #ifdef... well, there are some things that can't go into APR,
but in this case we can certainly avoid having #ifdefs scattered through
the code. I'm thinking along the lines of config_win.c: nobody notices
the #ifdef in there.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 13 00:17:50 2004