From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 20:08:41 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 13BB61065681; Mon, 22 Sep 2008 20:08:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C16748FC12; Mon, 22 Sep 2008 20:08:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 736D646B46; Mon, 22 Sep 2008 16:08:40 -0400 (EDT) Date: Mon, 22 Sep 2008 21:08:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> Message-ID: 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> <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , "Simon L. Nielsen" Subject: Re: 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 20:08:41 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > 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. I'm not sure I agree with this analysis. From a FreeBSD-centric perspective, vulnerabilities fall into four classes: - FreeBSD-generated code - Third party code blended with out code (arguably ours also) - "contrib" code that is in our revision control - Ports We dropped ports from our advisory scope because the number of vulnerabilities skyrocketted due to ports growing and the number of vulnerabilities discovered in them growing. We do provide a database of known-vulnerable ports and versions, but that's not generally the responsibility of the base security team, rather a separate ports security team. I think this is the right trade-off -- among our fears is that we over-release advisories, which would devalue the usefulness of advisories over time as referring specifically to critical issues. Extracted from the list of advisories on security.FreeBSD.org going back to the beginning of last year: Advisory Class FreeBSD-SA-08:09.icmp6 Blended FreeBSD-SA-08:08.nmount FreeBSD FreeBSD-SA-08:07.amd64 FreeBSD FreeBSD-SA-08:06.bind Contrib FreeBSD-SA-08:05.openssh Contrib FreeBSD-SA-08:03.sendfile FreeBSD FreeBSD-SA-08:02.libc Blended FreeBSD-SA-08:04.ipsec Blended FreeBSD-SA-08:01.pty FreeBSD FreeBSD-SA-07:10.gtar Contrib FreeBSD-SA-07:09.random FreeBSD FreeBSD-SA-07:08.openssl Contrib FreeBSD-SA-07:07.bind Contrib FreeBSD-SA-07:06.tcpdump Contrib FreeBSD-SA-07:05.libarchive FreeBSD FreeBSD-SA-07:04.file Contrib FreeBSD-SA-07:03.ipv6 Blended FreeBSD-SA-07:02.bind Contrib FreeBSD-SA-07:01.jail FreeBSD Counting on my fingers, that's 7 FreeBSD-specific, 4 that lie in code we basically maintain, and 8 that are in externally maintained software. Seems like a pretty even split. In the case of most third party code vulnerabilities, I believe we received non-trivial advanced warning of the impending vulnerability announcement. > 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) I'm not sure I agree with this assertion either. While there are exceptions, most vulnerabilities are known to the security team in advance of public discussion. Depends a bit on which security lists you read, of course... Robert N M Watson Computer Laboratory University of Cambridge