On Wed, 2004-10-20 at 16:31, Alex Holst wrote:
> Subversion security - http://mongers.org/svnsec
My reactions:
(1) Your comments about "attack surface" aren't very applicable to us.
All of the Subversion code base is an attack surface, because all of our
code operates on input which can be influenced by, at the very least,
committers.
(2) Your comments about the ratio of security releases is uncharitable.
Mostly at the urging of Ben Reser, we have used the term "security
release" very broadly. Some of us have been reluctant to do so, since
we knew some people would use those words against us. Congratulations,
you're part of the problem.
(3) Your statement "The subversion team do none of these things" in
reference to secure coding practices borders on libel. The three things
you mentioned were:
1. Adherence to practices avoiding language pitfalls
2. Code review for security flaws
3. Compartmentalized design.
We do adhere to practices avoiding language pitfalls. By using APR
pools, we avoid a category of memory management problems such as
double-freeing bugs. By avoiding fixed-length buffers in most contexts
and by constructing strings using apr_psprintf() and svn_stringbuf, we
avoid buffer overruns. (The one buffer overrun discovered in Subversion
to date was in a piece of extremely old code which did not reflect on
common coding practice.)
We have a lot of code review in this project, though we don't rigorously
track how well a given commit has been reviewed. But for instance,
Peter accidentally introduced a security hole in svnserve in r10620, I
caught it, it was fixed in r10939, and that bug never hit a release.
It's true that our design is not as compartmentalized as it could be.
arch likes to tout how they run over dumb file transport, so that no new
code faces read-only access to your repository. But as a result, they
have to rely heavily upon client-side caching to make up for the
performance deficit, and in some usage patterns client-side caching
won't help.
---------------------------------------------------------------------
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:33:13 2004