cvs commit: src/sys/compat/linux linux_misc.c

[Robert Watson]

On Sun, 25 Jun 2006, Alexander Leidinger wrote:

> Quoting Robert Watson <rwatson at freebsd.org> (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