From: "Rafael C. de Almeida" <almeidaraf@gmail.com>
To: pageexec@freemail.hu
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <greg@kroah.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, stable@kernel.org
Subject: Re: [stable] Linux 2.6.25.10
Date: Thu, 17 Jul 2008 04:19:21 -0300 [thread overview]
Message-ID: <487EF279.2050704@gmail.com> (raw)
In-Reply-To: <487D3056.1183.1C0E1C47@pageexec.freemail.hu>
pageexec@freemail.hu wrote:
> On 15 Jul 2008 at 13:42, Linus Torvalds wrote:
>
>> On Tue, 15 Jul 2008, pageexec@freemail.hu wrote:
>>> i understand and i think noone expects that. in fact, i know how much
>>> expertise and time it takes to determine that. but what happens when
>>> you do figure out the security relevance of a bug during bug submission
>> The issue is that I think it's then _misleading_ to mark that kind of
>> commit specially, when I actually believe that it's in the minority.
>>
>> If people think that they are safer for only applying (or upgrading to)
>> certain patches that are marked as being security-specific, they are
>> missing all the ones that weren't marked as such.
>
> and how is that different from today's situation where they aren't told
> at all? in other words, they already learned to live with that risk. if
> you tell them about a security bug, they will build that knowledge into
> their risk assessment process (which is what security is all about in
> the end). anything you omit will skew their decision making process (in
> particular, expose them to exploits if they fail to apply a fix because
> they make a bad judgement call).
>
> 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, 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. Also, you need to tell
us what you consider to be a security bug. That's not clear to me at least.
> what you're afraid of is that people will take your 'we mark security
> fixes we learn about' as 'we mark ALL security fixes that are such'. well,
> make that very clear in a public document (Documentation/SecurityBugs is
> a good place) and that's it, people will know you're doing a best effort
> disclosure and not more.
>
> cheers,
> PaX Team
next prev parent reply other threads:[~2008-07-17 7:19 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-03 3:58 Linux 2.6.25.10 Greg KH
2008-07-03 3:58 ` Greg KH
2008-07-03 17:08 ` Bart Van Assche
2008-07-03 17:29 ` Greg KH
2008-07-03 18:57 ` Greg KH
2008-07-03 19:31 ` pageexec
2008-07-14 12:04 ` [stable] " Greg KH
2008-07-15 2:14 ` pageexec
2008-07-15 2:27 ` Linus Torvalds
2008-07-15 15:31 ` pageexec
2008-07-15 16:07 ` Linus Torvalds
2008-07-15 16:13 ` Linus Torvalds
2008-07-17 21:08 ` Aidan Thornton
2008-07-15 19:03 ` pageexec
2008-07-15 19:16 ` Linus Torvalds
[not found] ` <487D20EC.26203.1BD1E5C5@pageexec.freemail.hu>
2008-07-15 20:18 ` Linus Torvalds
2008-07-15 20:23 ` pageexec
2008-07-15 20:42 ` Linus Torvalds
2008-07-15 21:18 ` pageexec
2008-07-15 21:26 ` Linus Torvalds
2008-07-15 22:08 ` pageexec
2008-07-15 23:28 ` Linus Torvalds
2008-07-16 0:00 ` Tiago Assumpcao
2008-07-16 0:16 ` Linus Torvalds
2008-07-16 0:38 ` Tiago Assumpcao
2008-07-16 0:51 ` Linus Torvalds
2008-07-16 1:10 ` Tiago Assumpcao
2008-07-16 1:41 ` Linus Torvalds
2008-07-16 2:24 ` Tiago Assumpcao
2008-07-16 3:11 ` Theodore Tso
2008-07-16 9:49 ` pageexec
2008-07-16 10:08 ` David Miller
2008-07-16 10:23 ` pageexec
2008-07-16 10:31 ` David Miller
2008-07-16 10:51 ` pageexec
2008-07-16 11:04 ` David Miller
2008-07-16 11:52 ` pageexec
2008-07-16 3:13 ` Greg KH
2008-07-16 9:01 ` pageexec
2008-07-16 9:35 ` Gabor Gombas
2008-07-16 10:04 ` pageexec
2008-07-16 14:43 ` Greg KH
2008-07-16 15:43 ` pageexec
2008-07-16 16:29 ` Greg KH
2008-07-16 17:25 ` pageexec
2008-07-16 18:08 ` Theodore Tso
2008-07-16 19:09 ` pageexec
2008-07-17 3:43 ` Mike Galbraith
2008-07-16 1:08 ` Theodore Tso
2008-07-16 1:30 ` pageexec
2008-07-16 1:53 ` Tiago Assumpcao
2008-07-16 2:02 ` Linus Torvalds
2008-07-16 2:36 ` Tiago Assumpcao
2008-07-16 4:07 ` Linus Torvalds
2008-07-16 4:16 ` Tiago Assumpcao
2008-07-16 3:27 ` Casey Schaufler
2008-07-16 4:13 ` Tiago Assumpcao
2008-07-16 4:21 ` Linus Torvalds
2008-07-16 5:02 ` Tiago Assumpcao
2008-07-16 5:13 ` Linus Torvalds
2008-07-16 5:26 ` Casey Schaufler
2008-07-16 9:33 ` pageexec
2008-07-16 13:21 ` Theodore Tso
2008-07-16 15:16 ` pageexec
2008-07-16 0:04 ` pageexec
2008-07-16 0:24 ` Linus Torvalds
2008-07-16 0:56 ` pageexec
2008-07-16 1:08 ` Linus Torvalds
2008-07-16 1:23 ` pageexec
2008-07-17 7:19 ` Rafael C. de Almeida [this message]
2008-07-17 7:59 ` pageexec
2008-07-17 4:21 ` Phil Pell
2008-07-15 18:33 ` Theodore Tso
2008-07-15 20:28 ` pageexec
2008-07-15 22:39 ` Greg KH
2008-07-15 22:47 ` David Miller
2008-07-15 23:08 ` Tiago Assumpcao
2008-07-15 23:21 ` David Miller
2008-07-15 23:26 ` pageexec
2008-07-15 23:26 ` Tiago Assumpcao
2008-07-15 23:22 ` pageexec
2008-07-15 23:35 ` David Miller
2008-07-15 23:09 ` pageexec
2008-07-15 20:15 ` Tiago Assumpcao
2008-07-20 1:13 ` Bernd Eckenfels
2008-07-15 23:34 ` Tiago Assumpcao
2008-07-19 0:47 ` David Schwartz
2008-07-19 1:01 ` david
2008-07-19 1:51 ` David Schwartz
2008-07-19 5:41 ` Willy Tarreau
2008-07-05 7:54 ` Bart Van Assche
2008-07-08 4:12 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=487EF279.2050704@gmail.com \
--to=almeidaraf@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pageexec@freemail.hu \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox