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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
