On 14 Jan 2003, Karl Fogel wrote:
> <rbb@rkbloom.net> writes:
> > That's fine, but I won't implement it. I disagree with this solution, and
> > you are making a rather large assumption about being able to sniff the
> > network. I only use SVN over SSL, because of the ability to sniff the
> > password off the wire. Also, there is the ability to implement digest
> > authentication to resolve that problem.
>
> Would you be willing to implement it with the other default (that is,
> the conservative one, which you prefer?) I won't pretend that the
> list might not discuss it some more, and later decide to tweak that
> default... But that property is true symmetrically of any solution: if
> someone implemented default "on" auth caching, and we later decided to
> become more conservative, then tweaking it to "off" would be a two
> second change as well.
>
> In other words, the main portion of this task is *not* the choosing of
> the default, and anyway the default may be changed back and forth N
> times before release.
>
> So if you're in general unwilling to implement a feature whose default
> behavior might get changed later, well, that's going to rule out a lot
> of Subversion work for you, which would be a pity :-(.
>
> Reconsider?
My goal in taking on this project is to close a security hole. I have no
problem implementing features which then get changed, shoot, most of APR
and Apache have been changed drastically since I started working on them,
and many of the changes are in ways that I disagree with. What concerns
me about this, isn't the chosen default, it is the reasoning behind the
default that we are leaning towards. We aren't talking about an edge case
here, we are talking about how the docs tell you to setup subversion on
the server side (through Apache), and the default setup for the client.
My main concern here, is that I am not willing to add code that I believe
to be a security hole. I would rather focus my attention on solving
other problems. Yes, it is easy to flip the default back and forth, but
by adding an initial default that I know to be a security hole, I am
saying that I do not believe the hole is big enough to worry about. The
problem is I disagree with that statement. If the code goes in with a
conservative default and then somebody changes it, then the person who
changes the code is making that statement, not me. The code we each
contribute speaks an amazing amount about what we each consider to be
important (not only in SVN, but in computer programs in general). I have
been bullied into making changes that I didn't agree with in the past, I
am no longer willing to do that.
I hope that makes sense. Instead of working on this, I will look at
adding cert support to SVN.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 19:40:15 2003