linux-kernel - Re: Kernel version numbers after 4.9.255 and 4.4.255

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, 4 Feb 2021 21:19:33 +0100
From:   Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255

David Laight wrote...

> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.

Hitting such version checks still might happen, though.

Also, any wrapping introduces a real risk package managers will see
version numbers running backwards and therefore will refrain from
installing an actually newer version.

For scripts/package/builddeb (I don't use that, though), you could work
around by setting an epoch, i.e. (untested)

-$sourcename ($packageversion) $distribution; urgency=low
+$sourcename (1:$packageversion) $distribution; urgency=low

but every packaging mechanism in-tree and outside should adopt such a
change, if even possible. Which is why this feels bad.

Possibly I am missing something: What's the reason to not use
EXTRAVERSION as back in the old 2.6.x.y days, so change to 4.4.255.1 and
so on? Well, unless there are still installations who treat 4.4.255 as
2.6.64.255.

    Christoph