linux-kernel - Re: [stable] Linux 2.6.25.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Jul 2008 11:49:45 +0200
From:	pageexec@...email.hu
To:	Tiago Assumpcao <tiago@...umpcao.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	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 15 Jul 2008 at 18:41, Linus Torvalds wrote:

> On Tue, 15 Jul 2008, Tiago Assumpcao wrote:
> > All I ask for is to receive the "There are updates available." message as soon
> > as one security problem is reported, understood and treated by your
> > development part. And that is, the sooner possible, if you please.
> 
> Umm. You're talking to _entirely_ the wrong person.
> 
> The people who want to track security issues don't run my development 
> kernels. They usually don't even run the _stable_ kernels.

how do you *know*?

> They tend to 
> run the kernels from some commercial distribution, and usually one that is 
> more than six months old as far as I - and other kernel developers - are 
> concerned.
> 
> IOW, when we fix security issues, it's simply not even appropriate or 
> relevant to you.

why? what makes you think that a bug fixed in 2.6.26 is not relevant to
2.6.20? do you or anyone else personally verify that? color me impressed
if you do that on every single fix you commit.

> More importantly, when we fix them, your vendor probably 
> won't have the fix for at least another week or two in most cases anyway.

correct, but also irrelevant, see below.

> So ask yourself - what would happen if I actually made a big deal out of 
> every bug we find that could possibly be a security issue. HONESTLY now!

why do you and others keep exaggerating of what is (well, was) expected from
you? what's with this 'big deal' business? can't you image a middle ground
where you simply just state what you know? say, my category 1-2 i talked
about before.

> We'd basically be announcing a bug that (a) may not be relevant to you, 
> but (b) _if_ it is relevant to you, you almost certainly won't actually 
> have fixed packages until a week or two later available to you!
> 
> Do you see?
> 
> I would not actually be helping you. I'd be helping the people you want to 
> protect against!

your argument rests on a fallacy that we discussed already but you keep
coming back with it. what makes you think that people exploiting kernel
bugs *rely* on your marking security bugs as such? they do *not*. they
are smarter (read: domain experts) than you or anyone else on lkml. they
will most likely spot the security issue when you *introduce* it, not
when you *fix* it. in other words, you are only helping the attackers by
withholding security information, not your users.

cheers,
  PaX Team

--
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/