[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Secure programming additions to HACKING

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-04-23 20:11:29 CEST

On Tue, Apr 23, 2002 at 11:05:15AM -0500, Karl Fogel wrote:
> "Sander Striker" <striker@apache.org> writes:
> > I'm sure Alex wants to contribute in that department.
> >
> > I think it is wise to 'educate' the developers in the mean time, so
> > the same mistakes won't be introduced while others are being fixed.
> What I'm getting at is, it'll be better to figure out some code
> changes first and *then* write the new material for HACKING, based on
> the tangible experiences in the code.

There have already been "tangible experiences" with patches. We've seen
patches that use strcpy() and malloc(), for example.

Thus, generic mistakes *ARE* a good thing to put in there.

> That patch to HACKING would have had no effect on people's coding.
> The generic practices that it recommends most of us here already know.

The HACKING document is not for *us*, though. It is for (potential)
contributors. Anything that we can include in there, before we have to see
their patch will reduce our load, distributing it appropriately.

> Those who don't know quickly find out anyway, because of all the peer
> review. I don't think there's any place in Subversion itself where we
> read arbitrary length data into a fixed-length array; if there is,
> it's because it slipped by a bunch of people who are well aware it's a
> no-no.

I'd prefer to catch it sooner.

> The stuff about security boundaries is helpful, but it wasn't specific
> enough to actually change anyone's behavior (I didn't know what I was
> supposed to do differently, for instance). It needs concrete examples
> from Subversion to be effective, that's all I'm saying.

While true, what Alex has done is a start, and should go in. If you want to
wait for perfection, then you won't get what you want.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 23 20:11:58 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.