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: <20293.1306788607@turing-police.cc.vt.edu>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ