linux-kernel - Re: [RFC] Kernel version numbering scheme change

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:	Thu, 16 Oct 2008 19:46:02 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Greg KH <greg@...ah.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
>...
> > If a distribution will try to autobuild an urgent OpenSSL security 
> > update for their stable release in a chroot on a machine running
> > kernel 2009.2.3 they will surely love you for being responsible
> > for this...
> 
> Distros properly patch things and backport "urgent OpenSSL security
> updates" to older versions of packages, so they would not run into this
> problem.

You didn't get my point.

Let me make an example:

The current Debian release will be supported until one year after the
next release gets released.

Someone from the Debian security team send a fixed package to the
buildds.

The buildds build packages in chroots.

A buildd may run any Debian release.

And it's perfectly normal that a buildd runs a more recent release of 
Debian than the one a package gets built for in a chroot.

No matter what you claim, you suggest to break currently working setups.

> Newer releases would run into this problem, but as almost all distros
> have huge, easy to run, build systems, a change like this would show up
> immediately and be fixed in a matter of hours, with the needed fixes
> being pushed upstream to the various packages as needed.
> 
> So I really don't think this is much of a problem.
>...

Using the same logic we could drop all legacy userspace ABIs
immediately - after all, it should only be a matter of hours
for a distribution to e.g. upgrade their glibc to 2.8 ...

You cannot suggest to change something that is some kind of informal 
userspace ABI and the claim it was not much of a problem.

I don't know what exactly would break, but various places in userspace 
would break in perhaps unexpected and strange ways, and this would cause 
many people quite a bit of headaches and work.

And I don't see any *really* good reason that would justify such
a change in the versioning.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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