"Erik Huelsmann" <ehuels_at_gmail.com> writes:
> Well, there's a big chance of me being perceivede as rude after my
> next statement, but this has been discussed *many* times before.
>
> The choice to store passwords in plain text has been a very conscious
> decision; it has also been replaced by more appropriate storage
> mechanisms on platforms which support that (Keychain on OSX,
> Crypto-API on Windows). Unfortunately, Linux doesn't feature a
> *standardized* crypto-agent. We don't need people lecturing us what's
> secure and what's not: we need people implementing secure storage
> mechanisms or patches to Subversion to support these mechanisms.
Basically agree with your sentiment, but:
We could switch to a default of not storing plaintext passwords, if we
1) Had a run-time option ('--store-password' or something) that
causes it to be stored permanently for that working copy, and
2) Had a config option to turn on password-storing as a default
The goal of our current run-time default was to make things easy for
users. When we made the decision, we understood we were compromising
security a bit. (This is a familiar trade-off in security design.)
We could make things somewhat less convenient, and somewhat more secure,
though, by doing the above. Personally, I think many users would
habituate to running a command with --store-password initially, or would
just set their configs in the appropriate way, but at least then it
would be a conscious decision. For users who are very worried about
security, it's an awful thing to discover that Subversion has been
saving your password in plaintext; but for users who are not so worried,
it's *not* such an awful thing to have to pass a flag or set a config
bit to get passwords save by default.
Thus, the tradeoff is not completely symmetrical, and I *think* I'd be
in favor of defaulting the other way, for that reason. I'm not sure why
we didn't do it that way originally, in fact. I don't think we ever
discussed having both the flag and the config option.
Hadmut, I have to admit I was also frustrated at wading through your
long mail telling us what we already know about security (and I know you
know we already know it, because you had this discussion over on the
users@ list already), and then gets to a concrete proposal at the very
end -- and even then the proposal is not even very detailed: I had to
fill in some details :-(.
Despite that frustration, I think there is a useful point here, and it
may be worth considering changing Subversion's default if we offer the
right options to control the behavior.
But *not* for 1.5! :-)
-Karl
---------------------------------------------------------------------
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-06 22:55:49 CEST