From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:49:27 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CA831065676; Mon, 22 Sep 2008 19:49:27 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id EF9008FC47; Mon, 22 Sep 2008 19:49:26 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MJnO4E011994; Mon, 22 Sep 2008 12:49:24 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.417] Message-Id: <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> From: Jo Rhett To: "Simon L. Nielsen" In-Reply-To: <20080920205645.GI1151@arthur.nitro.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 12:49:18 -0700 References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.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> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable Subject: Release team resources X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 19:49:27 -0000 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