instead of caching your own Makefile, can you start writing the "-hardened-r3" into a file named "localversion-hardened" in hardened-sources ? this is much easier to maintain and generate and doesnt involve clobbering the EXTRAVERSION field
The EXTRAVERSION clobbering doesn't come from the patchset but from the behaviour of kernel-2.eclass. However, it does allow that behaviour to be overridden if K_NOSETEXTRAVERSION is defined. What would be the advantage in doing that and manually maintaining a localversion-hardened patch?
the fact that the information in EXTRAVERSION is being lost seems pretty bad to me 2.6.23-r6 is actually 2.6.23.xx-r6
I've been meaning to reply to this for some time but just didn't get around to it. You are suggesting that the emphasis be placed upon the version number scheme used by upstream stable releases. But the consitutent patchsets that make up the end product are: * genpatches-base (and the upstream stable patch by proxy) * hardened-extras Of these, hardened-extras is by far the most important. It is this patchset that - not least - incorporates the grsecurity patch, the raison d'etre of this ebuild. That's the patchset through which the maintainers call the shots. Thus, the current naming scheme for hardened-sources reflects the progress of the hardened-extras patchset, just as the naming scheme for gentoo-sources reflects that of genpatches itself. Upstream stable releases are typically (but not always - as will be seen) delivered through genpatches. Even if we were to adopt a naming scheme that made it more readily apparent to the casual observer which upstream stable release has been incorporated, then why should the upstream version be considered more significant than the genpatches version, let alone the hardened-extras version? In my view, it could even prove to be misleading. I think it's safe to say that hardened-sources is by far the most proactively maintained kernel in portage when it comes to dealing with mainline vulnerabilities. As such, it is actually quite common for patches that address critical issues to be folded into hardened-patches in advance of genpatches-base and the upstream stable releases themselves. Consider the following table which clarifies the relationship between all of the 2.6.23 hardened-sources releases, the associated genpatches-base patchset and the upstream stable patch: ----------------------------+------------+-----------+------- release | genpatches | stable | notes ----------------------------+------------+-----------+------- hardened-sources-2.6.23 | 2.6.23-1 | 2.6.23.1 | 1,2,3 hardened-sources-2.6.23-r1 | 2.6.23-1 | 2.6.23.1 | 1,2,3 hardened-sources-2.6.23-r2 | 2.6.23-3 | 2.6.23.8 | 4,5 hardened-sources-2.6.23-r3 | 2.6.23-4 | 2.6.23.9 | 6,7 hardened-sources-2.6.23-r4 | 2.6.23-6 | 2.6.23.12 | hardened-sources-2.6.23-r5 | 2.6.23-6 | 2.6.23.12 | hardened-sources-2.6.23-r6 | 2.6.23-7 | 2.6.23.14 | hardened-sources-2.6.23-r7 | 2.6.23-9 | 2.6.23.15 | 8 hardened-sources-2.6.23-r8 | 2.6.23-9 | 2.6.23.15 | 8,A hardened-sources-2.6.23-r9 | 2.6.23-10 | 2.6.23.17 | hardened-sources-2.6.23-r10 | 2.6.23-10 | 2.6.23.17 | B hardened-sources-2.6.23-r11 | 2.6.23-10 | 2.6.23.17 | C hardened-sources-2.6.23-r12 | 2.6.23-10 | 2.6.23.17 | ----------------------------+------------+-----------+------- NOTES: 1) Contained "ptrace-hang.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.8 2) Contained "nfs-writeback-race.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.7 3) Contained "alsa-hdsp-dds-offset.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.8 4) Contained "usb-storage-nikon-d200-quirk.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.9 5) Contained "usb-storage-nikon-d40x-quirk.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.9 6) Contained "forcedeth-boot-delay.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.10 7) Contained "usb-sysfs-power-nodes" in advance of inclusion in subsequent upstream stable release 2.6.23.10 8) Contained "vmsplice-user-pointer.patch" in advance of inclusion in subsequent upstream stable release 2.6.23.16 Also, although I have deliberately avoided focussing upon hardened-extras itself (in particular, changes related to grsec/PaX) in the above breakdown, consider some of the changes that it brought to the party which serve only to demonstrate further how unreliable the upstream stable release version is to determine the fitness-for-purpose of the kernel as a whole: A) Pulled in hardened-extras-2.6.23-6 which included all upstream stable-queue patches available at the time. In fact, these patches went on to form the subsequent upstream stable release 2.6.23.10 with no modification whatsoever. B) Pulled in hardened-extras-2.6.23-8 which included backported patch for CVE-2008-1367 (fixed upstream in 2.6.24.4 but never in 2.6.23) C) Pulled in hardened-extras-2.6.23-9 which included "fix-dnotify-close-race.patch" for CVE-2008-1375 (fixed upstream in 2.6.24.6 but never in 2.6.23) If your request were to be implemented then the releases would have looked something like this: hardened-sources-2.6.23.1 hardened-sources-2.6.23.1-r1 hardened-sources-2.6.23.8 hardened-sources-2.6.23.9 hardened-sources-2.6.23.12 hardened-sources-2.6.23.12-r1 hardened-sources-2.6.23.14 hardened-sources-2.6.23.15 hardened-sources-2.6.23.15-r1 hardened-sources-2.6.23.17 hardened-sources-2.6.23.17-r1 hardened-sources-2.6.23.17-r2 hardened-sources-2.6.23.17-r3 Is this helpful? Considering the way that it's maintained, no - I don't believe it is. Let us briefly consider 2.6.24 also: * hardened-sources-2.6.24-r1 included fix for CVE-2008-1675 in advance of upstream stable release and genpatches * hardened-sources-2.6.24-r2 included stable patch 2.6.24.7 ahead of genpatches. Moreover, it includes independent patches for CVE-2008-2148 (not addressed in 2.6.24 upstream), CVE-2007-6282 (not addressed in 2.6.24 upstream, nor in genpatches) and CVE-2008-1615 (not addressed in 2.6.24 upstream, nor in genpatches) My point is this: hardened-sources is, ultimately, its own patchset. The only way you can really know what is going on with hardened-sources is to read its ChangeLog or otherwise monitor its development activity, just as you would expect to do with any bespoke patchset. In my view, there is really nothing to be gained my moving to a naming scheme that revolves around the upstream stable patch versioning scheme - quite the reverse. Moreover, it would entail a move away from the scheme that is employed by genpatches and well supported by kernel-2.eclass. If the subject of this bug is such a big deal then why is hardened being singled out? The scope of this bug concerns the entire kernel herd. I vote for a resolution of WONTFIX. In any case, Gordon Malm is leading on hardened-sources development so it his opinion that will carry the most weight.
Kerin's post/analysis pretty much sums up my own opinion on this topic. Closing INVALID as "The problem described is not a bug" seems more appropriate.
