cvs commit: src/sys/compat/linux linux_misc.c
rwatson at FreeBSD.org
Sun Jun 25 13:23:40 UTC 2006
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
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
University of Cambridge
More information about the cvs-src