From owner-cvs-src@FreeBSD.ORG Sun Jun 25 13:23:40 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AB3316A409; Sun, 25 Jun 2006 13:23:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81A4443D49; Sun, 25 Jun 2006 13:23:36 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3DCD646C91; Sun, 25 Jun 2006 09:23:35 -0400 (EDT) Date: Sun, 25 Jun 2006 14:23:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20060625142745.my6cnc4yog0kcggc@netchild.homeip.net> Message-ID: <20060625141943.X82242@fledge.watson.org> References: <200606231849.k5NIncuF041890@repoman.freebsd.org> <20060623214521.7b1441a6@Magellan.Leidinger.net> <20060625002255.F8526@fledge.watson.org> <20060625142745.my6cnc4yog0kcggc@netchild.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, secteam@freebsd.org Subject: Re: cvs commit: src/sys/compat/linux linux_misc.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 13:23:40 -0000 On Sun, 25 Jun 2006, Alexander Leidinger wrote: > Quoting Robert Watson (from Sun, 25 Jun 2006 00:32:54 > +0100 (BST)): > >> This isn't just not a huge security flaw, it's not a security flaw at all. >> It is a reliability bug due to a mis-implemented API that results in a >> clean failure in the presence of a well-characterized case. It doesn't >> appear to be exploitable to gain privilege, deny service rmeotely, etc. >> If this is a critical stability fix, it should be treated as an errata >> patch candidate. In the future, please don't use the "Security" tag for >> this type of change. However, do feel free to e-mail re@ to talk about >> whether this is an errata patch candidate, keeping secteam@ in the loop, as >> they currently own the 6.1 branch. > > I didn't know what to use instead to mark up an important fix to the people > which own the branch. Do you think it is worth to add ... maybe "Errata > candidate:" to the commit template to draw attention to something very > early? I'm not sure there currently is a formal tag for that. In the past, I've simply noted something like the following: RELENG_6_0 merge candidate. I think the general model for errata candidates is that the process is driven by the developer who believes that they have a change that reqiures an errata note, rather than by the branch owners. In particular, once there's been adequate testing time, the onus is on the developer to e-mail re@ (with a CC to secteam@) to discuss whether it's an appropriate candidate patch or not, at which point the right direction can be determined. BTW, if the Oracle used to work and now doesn't (i.e., a regression), then it may well be that this is a good errata patch candidate. However, if it has never worked, then I'm not sure it is a good errata patch candidate, and waiting on 6.2 may be the preferred model. Robert N M Watson Computer Laboratory University of Cambridge