Release team resources
jrhett at netconsonance.com
Mon Sep 22 19:49:27 UTC 2008
Thank you for answering the resources problem in detail, I appreciate
> 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
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
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)
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
More information about the freebsd-stable