Quoting Ben Reser (ben@reser.org):
> People have run security testing audit tools on our source code and
> reviewed the places it found to verify if there were issues or not.
Ah yes. I recall someone mentioned rats once. Unfortunately, most static
analysers aren't very good. In my experience, splint is the best one but
the default config is not very usable, so you'd have to invest a lot of
time into it.
> As far as surface area of possiblity for attacks. Sure we support
> multiple access methods. But the vast majority of users don't run all
> of them.
[..]
I wasn't trying to point out that the number of access methods is a
problem. I tried to elaborate in the document. Please tell me if it's
any clearer.
> In fact the SVN project itself only makes our repository
> available via http. The main Apache module is all of 9531 lines.
> mod_authz_svn is all of 635 lines. And svnserve is 1974 lines. These
> are relatively small amounts of code with clear deliniations between the
> access layers and the support code. If you feel that the Apache server
> itself is too big of a risk to run then don't use it, use svnserve.
Oh, I wasn't referring to the size of the svn modules in this case. I
was referring to the rest of Apache :)
My point: Most users don't think like this. They don't realise how much
code is exposed when they run Apache. They just install it, and it
works. I will be documenting which Apache modules are required, which
will bring the count down to a handful or so. Hopefully such
documentation can fit into the book somewhere.
> Do we look for potential security issues when reviewing code? I know I
> do when I review every commit. I can't speak for everyone else. I
> think it's pretty unfair to say that we need to implement "security
> review of new code."
I don't think that's an unfair statement at all. You know you look for
security problems, but I didn't know you did. And you don't know who
else looks for security problems either. I'm sure you'll agree that the
more people who look, the better.
One or two people cannot do this alone. When someone reviews a patch,
it would help to know how many people actually looked for security
problems. Just because this is open source doesn't mean people are
looking at the code for the reasons you'd like them to.
> Everything that gets committed to our repo gets
> reviewed by multiple people. Do we miss things, absolutely. But the
> same process you praise for ensuring careful attention to maintaining
> repository integrity, works to avoid security issues.
Ok, that's great. I'll revise the document to reflect this. By the token
that all vulnerabilities up until now have been introduced before 1.0,
I'd still advocate that a structured review of the apache modules and
svnserve take place.
> The problem with your assessment is that it is based on only part of the
> picture. Many discussions regarding the issues you bring up go on via
> the security list that you don't have access to or a committers only
> list that you also do not have access to. We talk about these matters
> here to avoid needlessly exposing our users to problems before we have
> solutions or needlessly scaring users about things we realize aren't
> really issues.
Ah. This was not my understanding. sussman invited me to the security
list once about 200 years ago and then changed his mind as he realised
the list was used by people who can quickly fix a bug, commit and
release a patch. I wasn't going to be of much use in that scenario. Has
this changed?
> Also you say that 4 out of 9 releases have been for security issues
> found by outsiders. That's not true. The last two security releases
> have been for issues that have been found by developers.
Apologies for this oversight. I've corrected this in the document now.
> Additionally, I don't see how it is relevent who discovers an issue.
Ouch. There are people who, when they find a security problem, tell no
one. They use the vulnerability for their own purposes. If the project
members actively look for bugs, there are going to be fewer bugs to be
found by hostile outsiders.
> If you want to do something rather than writing an assessment of how
> we're not doing things right, why don't you make an effort to get
> involved in reviewing code? Writing test suite coverage. Don't sit
> there high and mighty saying we're doing a poor job. Do something.
I feel that I am. Experience tells me that this project gets much
further if I can get *some* level of organised code audits started. I
don't mean to be high and mighty. I promise. It won't make any
difference at all if I sit down and review the code.
I am of much more value to this project by helping developers with
certain things than I would be if I sat down and found bugs: I won't be
here always, but an established culture of security-aware developers
*will* -- or at least has a greater chance of being so.
I've revised the document to try to get this better across. I've also
removed the remark you found offensive. It wasn't meant to be.
I hope we can continue this discussion.
--
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 01:20:29 2004