On 10/20/06, Samay <getafix123@hotmail.com> wrote:
> how about something similar to http://nsd.dyndns.org/pwsafe/ to manage
> passwords within Subversion client side ... at least for the CLI ...
I have three concerns at first glance:
1) It's C++, not very nice for integration with Subversion.
2) It's not a linkable library, and wrapping command execution is
absolutely out.
3) Never heard of it. That's *not* a trait I'm looking for in an
application that holds my secrets. What kind of scrutiny has this
package received from the world (especially security experts) ?
> provides real protection instead of a smoke screen by obfuscation!
Blindly integrating with a secure password store whose implementation
is not well scrutinized, or with silly default behavior (eg. no master
password, which degrades to storing in cleartext), will create a much
thicker smoke screen by providing no security gain, while proudly
claiming that it does. Integrating with a secure password store is not
a silver bullet that will just magically work without work and care.
I feel that this thread has degraded into an amalgamation of two very
separate issues. One is changing the current cleartext cache to an
obfuscated-cleartext cache; the second, which got tagged on at some
point, is integrating with secure password stores for operating
systems other than Windows and OSX.
I do not think that there is any debate whatsoever that the latter is
desirable, and desired. Nobody has yet taken the step to actually
implement this yet, for various reasons (including the difficulty of
choosing the right secure store, and time to implement), but patches
are always welcome.
The first issue, however, is completely orthogonal to integration with
secure stores. Assume an OS on which a systemwide secure store is not
at all available. On such a system, passwords are currently cached
cleartext, which provides zero security, and a medium to high risk of
accidental disclosure (a grep that happens to match part of your
password will print it to screen, for instance).
The proposed patch does not change the security level of the cache
(and goes out of its way to clearly indicate in the cache file that it
doesn't). However, it reduces the risk of accidental disclosure to a
much more reasonable level. The patch is very simple, and needs only
minor tweaks to be immediately commitable.
In this context, why is password obfuscation with a large warning not desirable?
Again, I am not saying that secure store integration is not desirable.
If you wish to propose a patch to integrate Subversion with a proven
and widely used secure password store which we don't yet support, by
all means do so, it will be most welcome (this applies to all of you
reading this by the way). But let's try to keep this thread focused on
the issue of what we want to happen when a secure store is not
available, for whatever reason.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 20 10:34:13 2006