[Buildroot] [Bug 15895] glibc version 'GLIBC_VERSION' does not match released glibc version

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=15895

Yann E. MORIN <yann.morin.1998 at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yann.morin.1998 at free.fr

--- Comment #2 from Yann E. MORIN <yann.morin.1998 at free.fr> ---
Peter, All,

As for the reason why we use such a version string, one can read the fine
details in that very good (as usual) LWN article; it dates back 4 years
now, but the reasons are still the same, and boils down to the fact that
glibc does not do dot-releases:
    https://lwn.net/Articles/736429/

So, rather than backport all and every patch going on the maintenance
branch, we sinply choose the latest commit on said branch whenever there
is a reason to update the version.

I understand that this does not help with CPE/CVE identification, but as
Thomas points out, we have a way out, something along the lines of:

    GLIBC_VERSION_MAJOR = 2.38
    GLIBC_VERSION_MINOR = 27-g750a45a783906a19591fb8ff6b7841470f1f5701
    GLIBC_VERSION = $(GLIBC_VERSION_MAJOR)-$(GLIBC_VERSION_MINOR)

    GLIBC_CPE_ID_VERSION = $(GLIBC_VERSION_MAJOR)
    # CVE-YYYY-XXXXXX fixed in [sha1 of commit fix]
    GLIBC_IGNORE_CVES += CVE-YYYY-XXXXX
    # CVE-YYYY-XXXXXX fixed in [sha1 of commit fix]
    GLIBC_IGNORE_CVES += CVE-YYYY-XXXXX

and so on... It is indeed a bit tedious, but we have to play with whatever
cards upstream dealt us; in this case, no dot-release.

It would be awesome if you were willing to submit such a patch!

Regards,
Yann e. MORIN.

-- 
You are receiving this mail because:
You are on the CC list for the bug.