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]

Message-ID: <487DEED3.1351.1EF6349A@pageexec.freemail.hu>
Date:	Wed, 16 Jul 2008 12:51:31 +0200
From:	pageexec@...email.hu
To:	David Miller <davem@...emloft.net>
CC:	tiago@...umpcao.org, torvalds@...ux-foundation.org, greg@...ah.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	stable@...nel.org
Subject: Re: [stable] Linux 2.6.25.10

On 16 Jul 2008 at 3:31, David Miller wrote:

> From: pageexec@...email.hu
> Date: Wed, 16 Jul 2008 12:23:50 +0200
> 
> > On 16 Jul 2008 at 3:08, David Miller wrote:
> > 
> > > IOW, when we fix security issues, it's simply not even appropriate or 
> > > relevant to you.
> > 
> > i'll ask again: why aren't security fixes that you fix relevant to users
> > of older kernels (as that's what the topic was)?
> 
> Backporting any fix to older kernels is a chore, the further back you
> go, the harder and less fun it is.

it depends on the fix and the context of the code it touches. a one
liner in 2.6.26 may not necessarily have to become a 100 line, multi-file
fix in 2.6.16. look at 28d838cc4dfea980cb6eda0a7409cbf91889ca74 for an
example, that was trivial to backport to many kernel versions before.

also, if you can find a commercial distro whose kernel predates even
yours (i.e., yours is between mainline and a well maintained commercial
one) then you may not actually have such a big problem with backports
even for more complex fixes as you can peek at what the commercial guys
are doing.

in any case, you're answering a different question or i'm failing to see
the logical connection between 'irrelevant' and 'laborious'. basically you
said now that you don't provide security info because it's labourious to
backport fixes, or something like that. i'm afraid there's no such logical
connection. you also didn't answer the question about why you should not
make the life of people doing the actual backports (paid for, commercial,
whatever the trigger word for you is) easier.

> The tipping point is really quick to where someone hacking the kernel
> for fun simply isn't going to do it, nor should they be expected to.
> 
> That's why people who want a stable supported kernel with fixes
> constantly backported have grown accustomed to paying for that service.

and how does that imply that you should not mark security fixes as such?
remember, we're not discussing how backports are done in the world, but
why you're helping them by withholding security information. because if
you admit that you're not, then that's one less reason to withhold this
info.

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/