Quoting kfogel@collab.net (kfogel@collab.net):
> I appreciate the thought put into the document, but find it less than
> constructive.
As mentioned, this was not intended. After all, I'm not esr :)
> > Virtually every security bug found in software either stems from
> > a design or implementation flaw. Hence, making secure software
> > require careful adherence to rules about avoiding programming
[..]
>
> Except for the part about inspection, these are all vague wishes, not
> concrete advice. You mention "rules", but do not describe them.
> Everyone who writes an API in Subversion thinks about the security
> implications. However, sometimes we don't think of them all. If you
> have an improved process for thinking of them, this would be the place
> to describe it...
I did this recently. When I suggested you read the excellent Microsoft
Press book "Threat Modeling" by Swiderski and Snyder, your comment was
something along the line that you probably couldn't learn anything about
security from Microsoft. :)
As for rules, I was deliberately trying to avoid specific suggestions as
they might not be 100% compatible with all the activities in this
project. I thought it would be best to narrow them down together. I am
not yet disillusioned enough to believe that a single person can define
how this project should go about improving this.
I'm just sorry I picked a wrong word and got the number of bugs wrong.
> > The Subversion team do none of these things. They have a webpage
> > with a contact address for reporting security bugs, and this is a
> > good thing. They even react to security problems with the usual
> > speed one has come to expect from non-commercial
> > vendors. However, it would be better if the entire team actively
> > started to audit existing code for bugs and implemented security
> > review of new code. One or two people cannot do this alone. The
> > entire team needs to participate.
>
> Yes, that would be nice, yet no one has volunteered to do it, because
> they find other things to be higher priority.
This conflicts with the essence of a point Ben Reser made, doesn't it?
He spends time looking for security problems and goes so far as to say
the effort made toward avoiding corruption bugs also go towards avoiding
security problems.
> What *specifically* is the team doing wrong now, or failing to do
> right? If you want to change their behavior, what will the costs be?
I've tried to expand on the specifics and I'll continue tomorrow. It's
2.30am here.
The costs depend on how aggressive you want to be, but it really boils
down to some other work not getting done. I can't qoute a number as the
cost for the subversion project of postponing features, nor the cost to
the project of being subject to a particular number of vulnerabilities.
Can you elaborate on what "costs" mean in this context? Maybe I can answer the
question better.
> > Karl Fogel announced to the Subversion developer list in June
> > 2004 that he was starting a security code audit and then followed
> > up a month later by stating that he would not be able to finish
> > the audit.
>
> That's right. It was taking a *huge* amount of time. (And I still
> didn't spot the path-based-authz problems that were later discovered!
> So all that time was wasted.)
I don't agree it was a waste of time. It "just" takes more effort and
more people actively looking over the code. If most developers were able
to spend 30 minutes per week looking for security bugs, they would slowly
get better at it and catch more things without a serious disruption to
the development progress.
> The costs of the audit turned out to far outweigh the benefits, i.e.,
> it was costing a lot and not benefiting us much anyway. If someone
> with more skill at a security audit (you?) did it, it might cost less
> and benefit Subversion more. Then the tradeoff would be worth it.
Please see my point to Ben Reser about the value of building a culture
of security-aware developers as opposed to a single individual who looks
for these things. Do you still feel a single individual finding problems
is the best approach?
> > The Subversion team is very serious about repository
> > integrity. They work hard to avoid bugs that could lead to
> > corrupt repositories. That same effort should be applied to
> > avoiding bugs that could lead to security compromises.
>
> That's a fallacy -- the efforts are not tradeable, for all sorts of
> reasons.
Again, I got the sense from Ben Reser that the approach I praised to
avoid corruption bugs went towards avoiding security bugs. You don't
seem to think so. It would be a great first step if all/most developers
had the same understanding of the level of effort that goes into
avoiding security bugs.
> I'm saying all this only partly defend the Subversion team (of course
> I too wish for fewer security releases!). I'm also saying it because
> whatever you propose must be based on an realistic assessment of the
> costs and benefits, and describe -- concretely -- how to get the work
> done. You haven't done any of that, and that's why your document
> isn't much help, I'm afraid.
I'll try to be more specific. As mentioned on IRC, in my experience
people seem to be more willing to follow along with an idea if they can
see the overall point, instead of suddenly implementing a security
counter-measure for no real reason. svn seems to be the exception to
this rule :)
I've revised the document again based on this email exchange. I'll
continue tomorrow. If I left anything out, please tell me.
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 02:34:46 2004