"Alex Holst" <a@mongers.org> writes:
> I have articulated some of these reasons in a document partly aimed at
> Subversion developers and partly aimed at Subversion users. The part
> aimed at the developers is mostly complete, and I'd like you all to read
> it so we can talk about how to best carry some of these suggestings into
> the project. I think it is badly needed.
>
> Subversion security - http://mongers.org/svnsec
>
> I will continue to work on the document over the coming days.
I appreciate the thought put into the document, but find it less than
constructive.
> 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
> language and OS pitfalls. Additionally, security code inspection
> and testing can be used for increased assurance (not guarantee)
> that security flaws are not present. In some situations, a
> particular approach to software design can help reduce the
> exposure, should a flaw sneak past security code review and
> testing.
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...
> 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.
You are willing to assert that a security audit should be a higher
priority than whatever it was a given developer decided to do instead
of auditing. But you're not volunteering to do the audit yourself,
nor pay for others to do it. Security audits are mind-numbingly hard,
incredibly time-consuming. You're saying "The team should do X"
without addressing the costs and difficulties of X.
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?
> When this author briefly confronted Greg Stein (of Subversion and
> Apache Software Foundation) about the serious lack of a security
> stance long before 1.0 was released, Stein retorted that any
> security bugs would be in Apache 2, not Subversion itself. There
> was no need to worry too much about the security properties of
> the Subversion source code.
[Was it necessary to use the word "confronted" instead of "asked"?
You want to get people on your side here, right? :-) ]
One developer's optimistic prediction from a long time ago does not
represent the group's opinion, then or now. I'm not really sure why
you included that paragraph.
> 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.)
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.
> To date, 4 of 9 releases (in the 1.0.x branch) since 1.0 have
> been released to fix security bugs found by someone outside the
> Subversion project. 4 security bugs in 6 months is worrying to
> any user who puts much value into either the confidentiality,
> integrity or availability of their source code. There will be
> more bugs found. Hence, the improvement process must start now.
This is overly simplistic -- you're counting all security problems as
equally severe. An exploit that gives someone shell access is far
worse than a problem that leaks, say, the names (but not contents) of
paths that were changed beneath an authz-protected dir. We've had
both kinds of problems, and stuff in between.
You can't just say "4 security bugs in 6 months". You have to
differentiate on the basis of severity.
In the same spirity, you later write:
> 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.
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 23:46:11 2004