Re: Subversion security needs to improve.

Quoting Toby Johnson (toby@etjohnson.us):
> I find this document very hard to read.

Thanks for your comments. I've revised the document to clear up a few
things you mentioned. Terms such as 'security features' and 'secure
features' are well known in software security literature, but I've tried
to elaborate a little.

I also didn't want to *dictate* exactly how the project implemented
security and that now comes across as vague :)

> You seem to
> hint that Subversion's multiple access methods are a security issue, but
> don't describe why other than saying it's a lot of code.

That's not the case. I've improved this section. Please see if it's
clearer now.

> You state that
> "in some situations, a particular approach to software design can help
> reduce the exposure", then claim that the developers fail to follow that
> "particular approach" without describing what that approach might be.

That's because it varies for httpd, svnserve and sshd and the (security)
people I showed this to before mailing it to the list understood exactly
what I meant. I've tried to elaborate on this in the document, too.

> In short, it's long on accusations and short on solutions. The only
> concrete recommendations you give are three bullet points at the end,
> which are rather vague in themselves.

I much prefer 'facts' or 'observations' to accusations. In some of the
other responses, a few problems in my data have been pointed out, so
I'll revise that as I respond to each post.

-- 
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