Release team resources

[Jo Rhett]

Thank you for answering the resources problem in detail, I appreciate  
it.

> For what secteam support of the base system costs, it's mainly time
> for the members of the security team which is the cost.  The more
> branches, the more time is required.  This is not a linear cost and
> has multiple parts to it:
	...
> There is also a cost in hardware for supported branches though this is
> less of an issue.
	...
>
> The more releases are supported, the more disk-space is also needed
> for freebsd-update mirrors.  Again, far from an unsolvable problem by
> any means, but also a factor

This is what I suspected, but having the detail backing it up helps  
tremendously.

Has there been done any work on metrics for the support needs?   
Obviously these are a bit of hand waving because the number and type  
of security problems are hard to predict, but it does help to provide  
a useful model for understanding "costs"

In specific, is it known how many man-hours would be necessary to  
extend support for a recent release?

NOTE that I am not trying to extend the support for 4.x or 5.x or even  
6.x once 8 has shipped.  I think that 2 full releases is perfectly  
reasonable.  I'm just asking about the recent releases.

> While I'm not going more into the general discussion of how long to
> support branches, I will note that as rwatson has said - adding more
> people to secteam is not as simple as it sounds (though we are in the
> process of expanding right now).

I assumed not.  I was curious to what extent outside people could help  
support the process, while leaving commits to the internal people.   
For example, for everything except the jail vulnerability in the last  
4 years the security problems were related to third party utilities,  
and were widely published in security mailing lists.  Someone without  
a commit bit could certainly build the patch, test the patch on  
relevant versions, etc.

Likewise, if a patch was created for the latest version, an outside  
person could test the patch on a desired-to-support build, confirm  
that it works and/or change the patch as necessary for the older build  
(like when third party utility versions were different between major  
releases).

Is the overhead of supporting these "not-committers" such that it is  
not useful for the secteam as a whole?

(obviously the longer term goal would be to determine which of the  
outside testers would be useful for promoting within the group)

> Newer patches also wouldn't make it to freebsd-update
> as that is managed by secteam.

For my needs/desires I'd rather focus on something that would get  
pushed to freebsd-update.

> We have had one case where a committer was interested in supporting an
> older release and back-ported patches from security advisories for a
> while.  The patches for the older releases were then reviewed in each
> case by the security team before commit, but that only lasted for a
> while and was a couple of years ago AFAIR.  In theory this could
> happen again if the Security Officer at the time is OK with it - I
> haven't talked with Colin about this in a while, so I can't recall is
> position.  There would still need to be committer which is the
> interface to secteam and do the commits.  Most issues (though of
> course not all) which gets advisories are not public at the time of
> the advisory, so a fix to older branches would be likely be delayed
> some compared to initial disclosure.

As noted above, very few of the security releases were based on  
information not available to the general public (who read security- 
related mailing lists, anyway)

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness