Date: Mon, 22 Sep 2008 12:49:18 -0700 From: Jo Rhett <jrhett@netconsonance.com> To: "Simon L. Nielsen" <simon@FreeBSD.org> Cc: freebsd-stable <freebsd-stable@FreeBSD.org> Subject: Release team resources Message-ID: <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> In-Reply-To: <20080920205645.GI1151@arthur.nitro.dk> References: <alpine.BSF.1.10.0809181935540.16464@fledge.watson.org> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <C096D142-4572-48DF-8CCA-053B41003A07@netconsonance.com> <alpine.BSF.1.10.0809191158330.40909@fledge.watson.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <4d7dd86f0809192057s33dfd92fv598488a4c05ada14@mail.gmail.com> <4B2A556D-B13D-4B71-819A-F9B23C5685AF@netconsonance.com> <20080920205645.GI1151@arthur.nitro.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75E31E23-23BA-4A5D-90F1-984C8C0AC895>