[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <487F17EE.5023.237EC55A@pageexec.freemail.hu>
Date: Thu, 17 Jul 2008 09:59:10 +0200
From: pageexec@...email.hu
To: "Rafael C. de Almeida" <almeidaraf@...il.com>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <greg@...ah.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [stable] Linux 2.6.25.10
On 17 Jul 2008 at 4:19, Rafael C. de Almeida wrote:
> pageexec@...email.hu wrote:
> > in other words, you should not be worrying about people not learning about
> > all security fixes, they already know it's not possible to provide such
> > information. however sharing your knowledge that you do have will *help*
> > them because 1. they can know for sure it's something important to apply
> > (no need to use their limited human resources to make that judgement),
> > 2. they can spend more of their resources on analyzing the *other* unmarked
> > fixes. overall this can only improve everyone's security.
>
> Hey, I have a crazy idea! What if they just mark all the bugs as a
> security bug (after all they all kinda are for some definition of
> security anyway)? That way people just apply all the patches and do not
> have to analyze anything, therefore not wasting their limited human
> resources at all!
>
> Linus' point is exactly that they shouldn't be treated differently,
yet they already are, see below.
> so you shouldn't allocate human resources to other bugs and just apply the
> security ones. If you want to convince someone you must tell us *why*
> those so-called security bugs are more important.
look at what went into 2.6.25.11 for example. it's a security fix. you do
treat them differently: you include them in -stable to the exclusion of
many other 'less important' fixes. read Documentation/stable_kernel_rules.txt
for how you not treat all fixes as equal (it's not only security ones that
are special cased).
> Also, you need to tell
> us what you consider to be a security bug. That's not clear to me at least.
anything that breaks the kernel's security model. privilege elevation
always does.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists