Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [Bug 15895] New: glibc version 'GLIBC_VERSION' does not match released glibc version
@ 2023-12-20 12:17 bugzilla
  2023-12-20 14:09 ` [Buildroot] [Bug 15895] " bugzilla
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: bugzilla @ 2023-12-20 12:17 UTC (permalink / raw)
  To: buildroot

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

            Bug ID: 15895
           Summary: glibc version 'GLIBC_VERSION' does not match released
                    glibc version
           Product: buildroot
           Version: 2023.08
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Other
          Assignee: unassigned@buildroot.uclibc.org
          Reporter: peter.verbrugge@technolution.nl
                CC: buildroot@uclibc.org
  Target Milestone: ---

The glibc package generates its own version number for glibc. It seems to be on
purpose but this causes issues when matching versions against the official
glibc releases.

The version generated for 2023.08 seems to be
'glibc:2.37-2-g9f8513dc64119a424b312db97cef5d87d376defa' even though the glibc
project only released 2.37.

For tracking package versions used in a buildroot build we use 'make
show-info'. This generates a json blob containing all information about
packages, including a CPE string.

For glibc in 2023.08 this creates the following CPE string:
'cpe:2.3:a:gnu:glibc:2.37-2-g9f8513dc64119a424b312db97cef5d87d376defa:*:*:*:*:*:*:*'
This string does not match any known CVE security vulnerabilities. All reported
vulnerabilities are reported with the version number 2.37 (without the number
of commits since & hash).

There's probably a reason why buildroot has deviated from the glibc reported
version number & the versions used by the NIST that i'm not seeing, but this
makes the CPE export and subsequent security analysis unusable for glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] [Bug 15895] glibc version 'GLIBC_VERSION' does not match released glibc version
  2023-12-20 12:17 [Buildroot] [Bug 15895] New: glibc version 'GLIBC_VERSION' does not match released glibc version bugzilla
@ 2023-12-20 14:09 ` bugzilla
  2023-12-20 18:35 ` bugzilla
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: bugzilla @ 2023-12-20 14:09 UTC (permalink / raw)
  To: buildroot

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

--- Comment #1 from Thomas Petazzoni <thomas.petazzoni@bootlin.com> ---
This CPE id is generated based on GLIBC_VERSION, in package/glibc/glibc.mk:

GLIBC_VERSION = 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701

So indeed, the CPE id version field is
2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.

glibc.mk should probably do:

GLIBC_CPE_ID_VERSION = 2.38

so that the CPE id has 2.38 has the version, allowing correct matching with the
NIST database.

*However*, this still will not give the correct results. Indeed, the matching
with NIST database will be done assuming we use 2.38, so it will report all
CVEs that affect the original 2.38 release. But Buildroot is not using 2.38,
but 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701, which is 27 commits
above 2.38. This means that all CVEs fixed in those 27 commits will be reported
by this matching process, even if they are not applicable, because we already
have the fixes.

One option of course is to add GLIBC_IGNORE_CVES entries for those CVEs so that
they are ignored. But normally, we use that to ignore CVEs because they are
fixed by local patches, or because they are not applicable to the Buildroot
use-case/situation. It is a bit weird to have a GLIBC_IGNORE_CVES for a CVE
that in fact does not affect the version that we use. But admittedly, it would
be a valid entry for the version documented by GLIBC_CPE_ID_VERSION.

So in other words, my proposal would be:

- GLIBC_CPE_ID_VERSION = 2.38
- Addition of GLIBC_IGNORE_CVES entries for all CVEs fixed between 2.38 and
2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] [Bug 15895] glibc version 'GLIBC_VERSION' does not match released glibc version
  2023-12-20 12:17 [Buildroot] [Bug 15895] New: glibc version 'GLIBC_VERSION' does not match released glibc version bugzilla
  2023-12-20 14:09 ` [Buildroot] [Bug 15895] " bugzilla
@ 2023-12-20 18:35 ` bugzilla
  2023-12-20 20:03 ` bugzilla
  2024-06-15 15:25 ` bugzilla
  3 siblings, 0 replies; 5+ messages in thread
From: bugzilla @ 2023-12-20 18:35 UTC (permalink / raw)
  To: buildroot

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

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

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

--- Comment #2 from Yann E. MORIN <yann.morin.1998@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.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] [Bug 15895] glibc version 'GLIBC_VERSION' does not match released glibc version
  2023-12-20 12:17 [Buildroot] [Bug 15895] New: glibc version 'GLIBC_VERSION' does not match released glibc version bugzilla
  2023-12-20 14:09 ` [Buildroot] [Bug 15895] " bugzilla
  2023-12-20 18:35 ` bugzilla
@ 2023-12-20 20:03 ` bugzilla
  2024-06-15 15:25 ` bugzilla
  3 siblings, 0 replies; 5+ messages in thread
From: bugzilla @ 2023-12-20 20:03 UTC (permalink / raw)
  To: buildroot

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

--- Comment #3 from Thomas Petazzoni <thomas.petazzoni@bootlin.com> ---
I have submitted a small series at
https://patchwork.ozlabs.org/project/buildroot/list/?series=387611 that
addresses this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] [Bug 15895] glibc version 'GLIBC_VERSION' does not match released glibc version
  2023-12-20 12:17 [Buildroot] [Bug 15895] New: glibc version 'GLIBC_VERSION' does not match released glibc version bugzilla
                   ` (2 preceding siblings ...)
  2023-12-20 20:03 ` bugzilla
@ 2024-06-15 15:25 ` bugzilla
  3 siblings, 0 replies; 5+ messages in thread
From: bugzilla @ 2024-06-15 15:25 UTC (permalink / raw)
  To: buildroot

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #4 from Yann E. MORIN <yann.morin.1998@free.fr> ---
Thank you for your report.

The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
    https://gitlab.com/buildroot.org/buildroot/-/issues

We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.

Thank you!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-06-15 15:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-20 12:17 [Buildroot] [Bug 15895] New: glibc version 'GLIBC_VERSION' does not match released glibc version bugzilla
2023-12-20 14:09 ` [Buildroot] [Bug 15895] " bugzilla
2023-12-20 18:35 ` bugzilla
2023-12-20 20:03 ` bugzilla
2024-06-15 15:25 ` bugzilla

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox