Message-ID: <20080723042737.GC6784@suse.de>
Date:	Tue, 22 Jul 2008 21:27:37 -0700
From:	Greg KH <gregkh@...e.de>
To:	"Rodrigo Rubira Branco (BSDaemon)" <rbranco@...checkpoint.com>
Cc:	Alan Cox <alan@...hat.com>, linux-kernel@...r.kernel.org,
	stable@...nel.org, greg@...ah.com,
	'Justin Forbes' <jmforbes@...uxtx.org>,
	'Zwane Mwaikambo' <zwane@....linux.org.uk>,
	'Theodore Ts'o' <tytso@....edu>,
	'Randy Dunlap' <rdunlap@...otime.net>,
	'Dave Jones' <davej@...hat.com>,
	'Chuck Wolber' <chuckw@...ntumlinux.com>,
	'Chris Wedgwood' <reviews@...cw.f00f.org>,
	'Michael Krufky' <mkrufky@...uxtv.org>,
	'Chuck Ebbert' <cebbert@...hat.com>,
	'Domenico Andreoli' <cavokz@...il.com>,
	'Willy Tarreau' <w@....eu>, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	caglar@...dus.org.tr, casey@...aufler-ca.com,
	spender@...ecurity.net, pageexec@...email.hu,
	rodrigo@...nelhacking.com
Subject: Re: [stable] Linux 2.6.25.10 (resume)

On Mon, Jul 21, 2008 at 09:48:13PM -0300, Rodrigo Rubira Branco (BSDaemon) wrote:
> Alan Cox escreveu:
>>> @@ -1,7 +1,7 @@
>>> -Linux kernel developers take security very seriously.  As such, we'd
>>> -like to know when a security bug is found so that it can be fixed and
>>> -disclosed as quickly as possible.  Please report security bugs to the
>>> -Linux kernel security team.
>>> +Linux kernel developers take security very seriously, in exactly the 
>>> +same way we do with any other bugs.  As such, we'd like to know when +a 
>>> security bug is found so that it can be fixed as soon as possible.
>>> +Please report security bugs to the Linux kernel security team.
>>>     
>>
>> NAK this. If the fix is not clear and the bug not too serious it is better
>> to disclose it than fail to fix it. The security team does not usually fix 
>> the
>> bugs, the experts in the various bits of code do.
>>   
> ACK ;)  Changed the sentence.  Tks.
>
>>> -Any exploit code is very helpful and will not be released without
>>> -consent from the reporter unless it has already been made public.
>>> +Any exploit code is very helpful and will not be released.
>>>     
>>
>> NAK this too. If someone releases an exploit publically or it leaks we
>> want to be able to freely share it too. Your proposal would mean any but
>> those dumb enough to agree to this could share it. That is why the unless 
>> made
>> public is part of every generic NDA document on the planet.
>>   
> Agreed.  Changed the sentence.  Tks.
>> The rest needs Linus to return from holiday for discussion and that'll
>> be a week or two. In the meantime you might want to define "disclose" as
>> I don't think we all agree on what it means as you've not defined who is 
>> and
>> isn't the linux security team and/or its helpers.
> Cool.

> --- SecurityBugs.orig	2008-07-16 23:46:09.000000000 -0300
> +++ SecurityBugs	2008-07-21 07:28:01.000000000 -0300
> @@ -1,7 +1,9 @@
> -Linux kernel developers take security very seriously.  As such, we'd
> -like to know when a security bug is found so that it can be fixed and
> -disclosed as quickly as possible.  Please report security bugs to the
> -Linux kernel security team.
> +Linux kernel developers take security very seriously, in exactly the 
> +same way we do with any other bugs.  As such, we'd like to know when 
> +a security bug is found so that it can be fixed as soon as possible by
> +the experts in this portion of the kernel code.
> +
> +Please report security bugs to the Linux kernel security team.

You have trailing spaces in your patch, please run all patches through
scripts/checkpatch.pl to catch stuff like this.

> @@ -14,23 +16,26 @@
>  As it is with any bug, the more information provided the easier it
>  will be to diagnose and fix.  Please review the procedure outlined in
>  REPORTING-BUGS if you are unclear about what information is helpful.
> -Any exploit code is very helpful and will not be released without
> -consent from the reporter unless it has already been made public.
> +Any exploit code is very helpful and will not be released by our team
> +unless already made public.  The exploit code may be shared with third
> +parties to facilitate a fix or to verify the vulnerability.

Your two changed sentances are contradictory.
What is wrong with the original wording?

>  2) Disclosure
>  
>  The goal of the Linux kernel security team is to work with the
>  bug submitter to bug resolution as well as disclosure.  We prefer
> -to fully disclose the bug as soon as possible.  It is reasonable to
> +to not disclose the bug, since we believe any kind of bug deserves the
> +same attention and will be quickly patched.  It is reasonable to

No, again, you are using the word "disclose" in an odd way here.

Of course the bug is "disclosed" in that it is made public, "here's a
fix for foo breaking".

So this wording change is not right.

>  delay disclosure when the bug or the fix is not yet fully understood,
>  the solution is not well-tested or for vendor coordination.  However, we
>  expect these delays to be short, measurable in days, not weeks or months.
>  A disclosure date is negotiated by the security team working with the
> -bug submitter as well as vendors.  However, the kernel security team
> -holds the final say when setting a disclosure date.  The timeframe for
> -disclosure is from immediate (esp. if it's already publically known)
> -to a few weeks.  As a basic default policy, we expect report date to
> -disclosure date to be on the order of 7 days.
> +bug submitter as well as vendors if the submitter wants to disclose.  

Again, trailing spaces.

What was wrong with the original wording?

thanks,

greg k-h
--
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