+1, even if i would appreciate a less "lawyer" language.
something like
"
first time configuration:
1. do you want to store your users/passwords for proxy and
repository on disk (yes, i don't care somebody else might
read them / no, i want to re-enter them each time)?
2. which proxy?
3. ...
if you want to change this configuration later on,
rerun blabla, edit .subversion/..., regedit blabla.
"
that there is a documentation for this is nothing you need to tell
the poor guy (except of course you have the exact link(s)) ...
this "configuration wizard" is also extensible. the first version
just might print:
"for proxies, passwords, etc. please edit ~/.subversion/... (unix),
regedit .... (windows)".
and leave the users work like it is now. the wizard then sets a
"firsttime=no" parameter in the config-file to remember it has been
run.
--- Daniel Berlin <dberlin@dberlin.org> wrote:
>
> On Monday, January 13, 2003, at 07:28 PM, Benjamin Pflugmann
> wrote:
>
> >
> > On Mon 2003-01-13 at 14:02:10 -0600, Ben Collins-Sussman wrote:
> >> <rbb@rkbloom.net> writes:
> >>
> >>> I just discovered that the svn client is caching passwords by
> >>> default.
> >>> This seems like a huge security hole, especially since it isn't
>
> >>> obvious
> >>> that it is being done [...]
> >>
> >> I'm not following your logic. It's a security hole because
> users
> >> don't know it's happening by default?
> >
> > Yes. It's called "unsafe defaults" and is the what the most
> active
> > worms targetting Microsoft Windows exploit mainly - several years
> > after the deficiency is well-known, fixes are long available and
> > everybody should know.
>
>
> >
> > (I am well aware that the setting we are talking about does not
> have
> > the same reach.)
> >
> >> (What would happen if every user read about it in documentation
> first?
> >> Would it still be a security hole?)
> >
> > Yes. Because humans are lazy. If a setting has security
> implications,
> > good software should encourage the user to make an active,
> reasonably
> > informed decision for case she wants to use the less safe
> setting.
> > IMHO, it cannot and should not enforce that, but it should help
> to do
> > the Right Thing.
> >
> > No, it wouldn't be a security hole anymore if you could be sure
> that
> > every user reads the documentation and changes the settings to
> the
> > safer one if she is unsure what to use or does not care. Notice
> the
> > paradox with the latter part?
> >
>
> How bout we just have the command line client warn them the first
> time
> we ask for and cache a password, right before asking for the
> password
> (in addition to moving passwords to ~/.subversion):
>
> "Warning: The password you type will be saved to disk and reused
> for
> later authentication to this repository. Please read the
> documentation
> if you do not understand the security implications of this. This
> message will not reappear for this repository.
> Password:"
>
> Would that make you feel better about the whole thing?
> The user would know what is happening, and that if they are unsure
> whether to care, it points them to the documentation (which
> presumably
> will spell out what will happen so they can decide whether they
> care).
>
> --Dan
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 12:22:08 2003