* [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