Upcoming Releases Schedule...

Robert Watson rwatson at FreeBSD.org
Mon Sep 22 19:42:00 UTC 2008


On Mon, 22 Sep 2008, Jo Rhett wrote:

> Again, what you are saying makes a lot of sense, and I have no problem with 
> it.  We're just missing the crucial bit -- what is it going to take to reach 
> that goal?  Regardless of commit bits, etc and such forth. Is 10 hours a 
> week of one person enough?  Does it really need 4 people with 10 hours a 
> week? How do we get from here to there?
>
> This is where I think we're missing each other.  Achieving a commit bit -- 
> sure, no problem with what you have outlined.  But you haven't finished the 
> thought enough to confirm whether me having a commit bit would solve the 
> problem we are trying to solve.
>
> I mean honestly, is one person with a commit bit and some time enough to 
> solve the problem?  I've been involved with enough projects to know that the 
> real answer might be, "no, we actually have all the people we need with 
> commit bits but our infrastructure makes doing this difficult right now".

Lack of human resources, to use a vile term, is currently the limiting factor. 
What happens when that is cleared is another question, but in the end there 
aren't a whole lot of paths to greater efficiency here: for each 
vulnerability, we generally start with the HEAD of the tree working back by 
age, for each branch identifying:

- Whether the vulnerability, or broad class of vulnerabilities, exists
- If the same patch applies, whether it fixes all instances of the problem  in
   the next branch as well
- Generate commit candidate
- Test builds and runs
- Generate binary updates
- Generate appropriate security advisory information

This is an inherently manual process because security patches touch a variety 
of parts of the system and each has different implications, the tendency for 
vulnerabilities to come in classes, etc.  None of us remembers the format 
string vulnerability's arrival on the scene fondly since it became necessary 
to modify the compiler to try to mechanically sweep the tree for similar 
issues, for example.

The older a branch, the more likely it is that it requires a different 
analysis and a different patch, hence the sigh of relief when 5.x fell off the 
support list -- not because it was a bad branch, but because there was 
significant divergence and maintaining three active development branches at 
once (5.x, 6.x, and 7.x) was a serious stretch.

<long essay elided>

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-stable mailing list