linux-kernel - Re: Linux 3.0-rc1

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:	Mon, 30 May 2011 16:50:07 -0400
From:	Valdis.Kletnieks@...edu
To:	Mustapha Rabiu <muztapha@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Linux 3.0-rc1

On Mon, 30 May 2011 20:33:29 -0000, Mustapha Rabiu said:
> Linus Torvalds <torvalds <at> linux-foundation.org> writes:
> 
> > 
> > Yay! Let the bikeshed painting discussions about version numbering
> > begin (or at least re-start).
> > 
> > I decided to just bite the bullet, and call the next version 3.0. It
> > will get released close enough to the 20-year mark, which is excuse
> > enough for me, although honestly, the real reason is just that I can
> > no longe rcomfortably count as high as 40.
> > 
> 
> Unsurprising, however, congratulations on yet another major release! 
> We applaud the fact that it'll be just as hideous as 2.6.x, without any 
> new or modified features. Might you explain why you didn't just 
> use 2.8.x ?
> 
> Also, given that multiple people have asked for a handful of things
> to be merged into the kernel, re: security, I'm puzzled about how 
> you managed to develop this self-styled 'alpha-male' based versioning 
> scheme without addressing unsettling discrepancies such 
> as /proc/pid/auxv, /proc/pid/stack and /proc/pid/syscall based 
> info-leaks or slub cache merging, etc, all of which have been publicly 
> discussed over varying periods of time, (circa ~2008)

We can come back and revisit those issues after we get done fixing
*all* the software that made a blind assumption that the kernel
release number matches '2\.[46]\.[0-9]+' (said assumption being
broken at *both* ends by a 3.0 release.

I have to agree with Linus on this one - if we're ruling out ABI-breaking
changes, we want to make this kernel release as little different as
we can.

Content of type "application/pgp-signature" skipped