Re: [OE-core] [RFT][PATCH] glibc: Upgrade to 2.39
Hello Raj,
Is this one
https://lists.openembedded.org/g/openembedded-core/message/194128 ok?
Regards,
Andy
On 19.01.2024 15:47, Khem Raj wrote:
On Thu, Jan 18, 2024 at 11:22 PM Andrej Valek wrote:
Hello Raj,
I will try to take a look on this today. Is the patch the same as here
https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut=c0594edef0d2108860421d0cfd460993264e18c3
? Means, if I can take it from there.
yes. Keep an eye on yoe/mut, as I am updating it there
Thanks,
Andy
On 17.01.2024 08:20, Khem Raj wrote:
On Tue, Jan 16, 2024 at 11:10 PM Andrej Valek wrote:
Hello Raj,
Don't forget to change the glibc-version.inc too and try to make a
optimization/cleaning like I proposed here:
https://lists.openembedded.org/g/openembedded-core/message/193572 ;).
yeah CVEs list will need cleaning anyway as it will be verson bump. But if
you turn your suggestion into a patch I can include it in patchset.
Regards,
Andy
On 16.01.2024 20:53, Khem Raj wrote:
Upgrade localdef to get glibc 2.39 build fixes
Details of release [1]
[1] https://sourceware.org/glibc/wiki/Release/2.39
Signed-off-by: Khem Raj
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
...2.38.bb => cross-localedef-native_2.39.bb} | 0
meta/recipes-core/glibc/glibc-common.inc | 2 +-
...bc-locale_2.38.bb => glibc-locale_2.39.bb} | 0
...bc-mtrace_2.38.bb => glibc-mtrace_2.39.bb} | 0
...-scripts_2.38.bb => glibc-scripts_2.39.bb} | 0
...tsuite_2.38.bb => glibc-testsuite_2.39.bb} | 0
meta/recipes-core/glibc/glibc-version.inc | 8 ++--
...ests_2.38.bb => glibc-y2038-tests_2.39.bb} | 0
...dd-hardlink-resolver-from-util-linux.patch | 2 +-
...-fix-ups-hardlink-to-make-it-compile.patch | 2 +-
...Look-for-host-system-ld.so.cache-as-.patch | 8 ++--
...Fix-buffer-overrun-with-a-relocated-.patch | 4 +-
...Raise-the-size-of-arrays-containing-.patch | 22 -
...k-glibc-Allow-64-bit-atomics-for-x86.patch | 4 +-
...Make-relocatable-install-for-locales.patch | 10 ++--
...Fall-back-to-faccessat-on-faccess2-r.patch | 4 +-
...the-path-sets-wrong-config-variables.patch | 2 +-
...ss-building-and-testing-instructions.patch | 2 +-
...glibc-Help-bootstrap-cross-toolchain.patch | 4 +-
...eglibc-Resolve-__fpscr_values-on-SH4.patch | 4 +-
...port-cross-locale-generation-support.patch | 46 +--
...-archive-uses-a-hard-coded-locale-pa.patch | 4 +-
...Do-not-ask-compiler-for-finding-arch.patch | 2 +-
...y-the-header-between-arm-and-aarch64.patch | 4 +-
...h-printf-builtin-in-nscd-init-script.patch | 2 +-
...igure.ac-Set-libc_cv_rootsbindir-onl.patch | 2 +-
...ell-interpreter-overridable-in-tzsel.patch | 6 +--
...Use-bin-sh-default-shell-interpreter.patch | 2 +-
...d-failed-in-unprivileged-process-BZ-.patch | 6 +--
...build-time-paths-in-the-output-binar.patch | 6 +--
...e-Pass-mcpu-along-with-march-to-dete.patch | 5 +-
...Bump-__GLIBC_MINOR__-to-39-on-master.patch | 25 ++
.../glibc/{glibc_2.38.bb => glibc_2.39.bb}| 1 +
34 files changed, 106 insertions(+), 85 deletions(-)
rename meta/recipes-core/glibc/{cross-localedef-native_2.38.bb =>
cross-localedef-native_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-locale_2.38.bb =>
glibc-locale_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-mtrace_2.38.bb =>
glibc-mtrace_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-scripts_2.38.bb =>
glibc-scripts_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-testsuite_2.38.bb =>
glibc-testsuite_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-y2038-tests_2.38.bb =>
glibc-y2038-tests_2.39.bb} (100%)
create mode 100644
meta/recipes-core/glibc/glibc/0024-features.h-Bump-__GLIBC_MINOR__-to-39-on-master.patch
rename meta/recipes-core/glibc/{glibc_2.38.bb => glibc_2.39.bb} (98%)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 3720a4c5b86..977fb316107 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -20,7 +20,7 @@ GCCVERSION ?= "13.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.41%"
GDBVERSION ?= "14.%"
-GLIBCVERSION ?= "2.38%"
+GLIBCVERSION ?= "2.39%"
LINUXLIBCVERSION ?= "6.6%"
QEMUVERSION ?= "8.1%"
GOVERSION ?= "1.20%"
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.38.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/cross-localedef-native_2.38.bb
rename to meta/recipes-core/glibc/cross-localedef-native_2.39.bb
diff --git a/meta/recipes-core/glibc/glibc-common.inc
b/meta/recipes-core/glibc/glibc-common.inc
index be33c298
[OE-core][PATCH] glibc: Refresh CVE statuses
- drop irrelevant CVEs Signed-off-by: Valek Andrej --- meta/recipes-core/glibc/glibc-version.inc | 5 - meta/recipes-core/glibc/glibc_2.39.bb | 2 -- 2 files changed, 7 deletions(-) diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes-core/glibc/glibc-version.inc index 7efcd0818f6..b8f0a4a119e 100644 --- a/meta/recipes-core/glibc/glibc-version.inc +++ b/meta/recipes-core/glibc/glibc-version.inc @@ -7,9 +7,4 @@ GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https" UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+(\.(?!90)\d+)*)" -CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4911] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-4806] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-5156] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-0687] = "fixed-version: Fixed in stable branch updates" diff --git a/meta/recipes-core/glibc/glibc_2.39.bb b/meta/recipes-core/glibc/glibc_2.39.bb index 910bbdd71b0..b5aa15ec5bb 100644 --- a/meta/recipes-core/glibc/glibc_2.39.bb +++ b/meta/recipes-core/glibc/glibc_2.39.bb @@ -16,8 +16,6 @@ CVE_STATUS[CVE-2019-1010025] = "disputed: \ Allows for ASLR bypass so can bypass some hardening, not an exploit in itself, may allow \ easier access for another. 'ASLR bypass itself is not a vulnerability.'" -CVE_STATUS[CVE-2023-25139] = "cpe-stable-backport: This is integrated into the 2.37 branch as of 07b9521fc6" - DEPENDS += "gperf-native bison-native" NATIVESDKFIXES ?= "" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194128): https://lists.openembedded.org/g/openembedded-core/message/194128 Mute This Topic: https://lists.openembedded.org/mt/103882809/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] glibc: Refresh CVE statuses
- drop irrelevant CVEs Signed-off-by: Valek Andrej --- meta/recipes-core/glibc/glibc-version.inc | 5 - meta/recipes-core/glibc/glibc_2.39.bb | 2 -- 2 files changed, 7 deletions(-) diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes-core/glibc/glibc-version.inc index 7efcd0818f6..b8f0a4a119e 100644 --- a/meta/recipes-core/glibc/glibc-version.inc +++ b/meta/recipes-core/glibc/glibc-version.inc @@ -7,9 +7,4 @@ GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https" UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+(\.(?!90)\d+)*)" -CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4911] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-4806] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-5156] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-0687] = "fixed-version: Fixed in stable branch updates" diff --git a/meta/recipes-core/glibc/glibc_2.39.bb b/meta/recipes-core/glibc/glibc_2.39.bb index 910bbdd71b0..b5aa15ec5bb 100644 --- a/meta/recipes-core/glibc/glibc_2.39.bb +++ b/meta/recipes-core/glibc/glibc_2.39.bb @@ -16,8 +16,6 @@ CVE_STATUS[CVE-2019-1010025] = "disputed: \ Allows for ASLR bypass so can bypass some hardening, not an exploit in itself, may allow \ easier access for another. 'ASLR bypass itself is not a vulnerability.'" -CVE_STATUS[CVE-2023-25139] = "cpe-stable-backport: This is integrated into the 2.37 branch as of 07b9521fc6" - DEPENDS += "gperf-native bison-native" NATIVESDKFIXES ?= "" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194124): https://lists.openembedded.org/g/openembedded-core/message/194124 Mute This Topic: https://lists.openembedded.org/mt/103882748/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFT][PATCH] glibc: Upgrade to 2.39
Hello Raj,
I will try to take a look on this today. Is the patch the same as here
https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut=c0594edef0d2108860421d0cfd460993264e18c3
? Means, if I can take it from there.
Thanks,
Andy
On 17.01.2024 08:20, Khem Raj wrote:
On Tue, Jan 16, 2024 at 11:10 PM Andrej Valek wrote:
Hello Raj,
Don't forget to change the glibc-version.inc too and try to make a
optimization/cleaning like I proposed here:
https://lists.openembedded.org/g/openembedded-core/message/193572 ;).
yeah CVEs list will need cleaning anyway as it will be verson bump. But if
you turn your suggestion into a patch I can include it in patchset.
Regards,
Andy
On 16.01.2024 20:53, Khem Raj wrote:
Upgrade localdef to get glibc 2.39 build fixes
Details of release [1]
[1] https://sourceware.org/glibc/wiki/Release/2.39
Signed-off-by: Khem Raj
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
...2.38.bb => cross-localedef-native_2.39.bb} | 0
meta/recipes-core/glibc/glibc-common.inc | 2 +-
...bc-locale_2.38.bb => glibc-locale_2.39.bb} | 0
...bc-mtrace_2.38.bb => glibc-mtrace_2.39.bb} | 0
...-scripts_2.38.bb => glibc-scripts_2.39.bb} | 0
...tsuite_2.38.bb => glibc-testsuite_2.39.bb} | 0
meta/recipes-core/glibc/glibc-version.inc | 8 ++--
...ests_2.38.bb => glibc-y2038-tests_2.39.bb} | 0
...dd-hardlink-resolver-from-util-linux.patch | 2 +-
...-fix-ups-hardlink-to-make-it-compile.patch | 2 +-
...Look-for-host-system-ld.so.cache-as-.patch | 8 ++--
...Fix-buffer-overrun-with-a-relocated-.patch | 4 +-
...Raise-the-size-of-arrays-containing-.patch | 22 -
...k-glibc-Allow-64-bit-atomics-for-x86.patch | 4 +-
...Make-relocatable-install-for-locales.patch | 10 ++--
...Fall-back-to-faccessat-on-faccess2-r.patch | 4 +-
...the-path-sets-wrong-config-variables.patch | 2 +-
...ss-building-and-testing-instructions.patch | 2 +-
...glibc-Help-bootstrap-cross-toolchain.patch | 4 +-
...eglibc-Resolve-__fpscr_values-on-SH4.patch | 4 +-
...port-cross-locale-generation-support.patch | 46 +--
...-archive-uses-a-hard-coded-locale-pa.patch | 4 +-
...Do-not-ask-compiler-for-finding-arch.patch | 2 +-
...y-the-header-between-arm-and-aarch64.patch | 4 +-
...h-printf-builtin-in-nscd-init-script.patch | 2 +-
...igure.ac-Set-libc_cv_rootsbindir-onl.patch | 2 +-
...ell-interpreter-overridable-in-tzsel.patch | 6 +--
...Use-bin-sh-default-shell-interpreter.patch | 2 +-
...d-failed-in-unprivileged-process-BZ-.patch | 6 +--
...build-time-paths-in-the-output-binar.patch | 6 +--
...e-Pass-mcpu-along-with-march-to-dete.patch | 5 +-
...Bump-__GLIBC_MINOR__-to-39-on-master.patch | 25 ++
.../glibc/{glibc_2.38.bb => glibc_2.39.bb}| 1 +
34 files changed, 106 insertions(+), 85 deletions(-)
rename meta/recipes-core/glibc/{cross-localedef-native_2.38.bb =>
cross-localedef-native_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-locale_2.38.bb =>
glibc-locale_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-mtrace_2.38.bb =>
glibc-mtrace_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-scripts_2.38.bb =>
glibc-scripts_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-testsuite_2.38.bb =>
glibc-testsuite_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-y2038-tests_2.38.bb =>
glibc-y2038-tests_2.39.bb} (100%)
create mode 100644
meta/recipes-core/glibc/glibc/0024-features.h-Bump-__GLIBC_MINOR__-to-39-on-master.patch
rename meta/recipes-core/glibc/{glibc_2.38.bb => glibc_2.39.bb} (98%)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 3720a4c5b86..977fb316107 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -20,7 +20,7 @@ GCCVERSION ?= "13.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.41%"
GDBVERSION ?= "14.%"
-GLIBCVERSION ?= "2.38%"
+GLIBCVERSION ?= "2.39%"
LINUXLIBCVERSION ?= "6.6%"
QEMUVERSION ?= "8.1%"
GOVERSION ?= "1.20%"
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.38.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/cross-localedef-native_2.38.bb
rename to meta/recipes-core/glibc/cross-localedef-native_2.39.bb
diff --git a/meta/recipes-core/glibc/glibc-common.inc
b/meta/recipes-core/glibc/glibc-common.inc
index be33c29857c..5b62884a017 100644
--- a/meta/recipes-core/glibc/glibc-common.inc
+++ b/meta/recipes-core/glibc/glibc-common.inc
@@ -22,4 +22,4 @@ ARM_INSTRUCTION_SET:armv6 = "arm"
#
COMPATIBLE_HOST:libc-musl:class-target = "null"
-PV = "2.38"
+PV = "2.39+git"
diff --git a/meta/recipes-c
Re: [OE-core] [RFT][PATCH] glibc: Upgrade to 2.39
Hello Raj,
Don't forget to change the glibc-version.inc too and try to make a
optimization/cleaning like I proposed here:
https://lists.openembedded.org/g/openembedded-core/message/193572 ;).
Regards,
Andy
On 16.01.2024 20:53, Khem Raj wrote:
Upgrade localdef to get glibc 2.39 build fixes
Details of release [1]
[1] https://sourceware.org/glibc/wiki/Release/2.39
Signed-off-by: Khem Raj
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
...2.38.bb => cross-localedef-native_2.39.bb} | 0
meta/recipes-core/glibc/glibc-common.inc | 2 +-
...bc-locale_2.38.bb => glibc-locale_2.39.bb} | 0
...bc-mtrace_2.38.bb => glibc-mtrace_2.39.bb} | 0
...-scripts_2.38.bb => glibc-scripts_2.39.bb} | 0
...tsuite_2.38.bb => glibc-testsuite_2.39.bb} | 0
meta/recipes-core/glibc/glibc-version.inc | 8 ++--
...ests_2.38.bb => glibc-y2038-tests_2.39.bb} | 0
...dd-hardlink-resolver-from-util-linux.patch | 2 +-
...-fix-ups-hardlink-to-make-it-compile.patch | 2 +-
...Look-for-host-system-ld.so.cache-as-.patch | 8 ++--
...Fix-buffer-overrun-with-a-relocated-.patch | 4 +-
...Raise-the-size-of-arrays-containing-.patch | 22 -
...k-glibc-Allow-64-bit-atomics-for-x86.patch | 4 +-
...Make-relocatable-install-for-locales.patch | 10 ++--
...Fall-back-to-faccessat-on-faccess2-r.patch | 4 +-
...the-path-sets-wrong-config-variables.patch | 2 +-
...ss-building-and-testing-instructions.patch | 2 +-
...glibc-Help-bootstrap-cross-toolchain.patch | 4 +-
...eglibc-Resolve-__fpscr_values-on-SH4.patch | 4 +-
...port-cross-locale-generation-support.patch | 46 +--
...-archive-uses-a-hard-coded-locale-pa.patch | 4 +-
...Do-not-ask-compiler-for-finding-arch.patch | 2 +-
...y-the-header-between-arm-and-aarch64.patch | 4 +-
...h-printf-builtin-in-nscd-init-script.patch | 2 +-
...igure.ac-Set-libc_cv_rootsbindir-onl.patch | 2 +-
...ell-interpreter-overridable-in-tzsel.patch | 6 +--
...Use-bin-sh-default-shell-interpreter.patch | 2 +-
...d-failed-in-unprivileged-process-BZ-.patch | 6 +--
...build-time-paths-in-the-output-binar.patch | 6 +--
...e-Pass-mcpu-along-with-march-to-dete.patch | 5 +-
...Bump-__GLIBC_MINOR__-to-39-on-master.patch | 25 ++
.../glibc/{glibc_2.38.bb => glibc_2.39.bb}| 1 +
34 files changed, 106 insertions(+), 85 deletions(-)
rename meta/recipes-core/glibc/{cross-localedef-native_2.38.bb =>
cross-localedef-native_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-locale_2.38.bb => glibc-locale_2.39.bb}
(100%)
rename meta/recipes-core/glibc/{glibc-mtrace_2.38.bb => glibc-mtrace_2.39.bb}
(100%)
rename meta/recipes-core/glibc/{glibc-scripts_2.38.bb =>
glibc-scripts_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-testsuite_2.38.bb =>
glibc-testsuite_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-y2038-tests_2.38.bb =>
glibc-y2038-tests_2.39.bb} (100%)
create mode 100644
meta/recipes-core/glibc/glibc/0024-features.h-Bump-__GLIBC_MINOR__-to-39-on-master.patch
rename meta/recipes-core/glibc/{glibc_2.38.bb => glibc_2.39.bb} (98%)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 3720a4c5b86..977fb316107 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -20,7 +20,7 @@ GCCVERSION ?= "13.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.41%"
GDBVERSION ?= "14.%"
-GLIBCVERSION ?= "2.38%"
+GLIBCVERSION ?= "2.39%"
LINUXLIBCVERSION ?= "6.6%"
QEMUVERSION ?= "8.1%"
GOVERSION ?= "1.20%"
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.38.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/cross-localedef-native_2.38.bb
rename to meta/recipes-core/glibc/cross-localedef-native_2.39.bb
diff --git a/meta/recipes-core/glibc/glibc-common.inc
b/meta/recipes-core/glibc/glibc-common.inc
index be33c29857c..5b62884a017 100644
--- a/meta/recipes-core/glibc/glibc-common.inc
+++ b/meta/recipes-core/glibc/glibc-common.inc
@@ -22,4 +22,4 @@ ARM_INSTRUCTION_SET:armv6 = "arm"
#
COMPATIBLE_HOST:libc-musl:class-target = "null"
-PV = "2.38"
+PV = "2.39+git"
diff --git a/meta/recipes-core/glibc/glibc-locale_2.38.bb
b/meta/recipes-core/glibc/glibc-locale_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/glibc-locale_2.38.bb
rename to meta/recipes-core/glibc/glibc-locale_2.39.bb
diff --git a/meta/recipes-core/glibc/glibc-mtrace_2.38.bb
b/meta/recipes-core/glibc/glibc-mtrace_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/glibc-mtrace_2.38.bb
rename to meta/recipes-core/glibc/glibc-mtrace_2.39.bb
diff --git a/meta/recipes-core/glibc/glibc-scripts_2.38.bb
b/meta/recipes-core/glibc/glibc-scripts_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/glibc-scripts_2.38.bb
rename to meta/recipes-core/glibc/glibc-scripts_2.39.bb
Re: [OE-core] [PATCH] glibc: Set status for CVE-2023-5156 & CVE-2023-0687
Hi Simone, I would like make a small improvements here ;). Once you're touching this file, make it little bit more optimized. Something like this: CVE_STATUS_GROUPS += "CVE_STATUS_GLIBC" CVE_STATUS_GLIBC = "CVE-2023-4527 CVE-2023-4911 CVE-2023-4806"... CVE_STATUS_GLIBC[status] = "fixed-version: Fixed in stable branch updates" Then we don't have to set the same status multiple times separately. Regards, Andy On 11.01.2024 16:20, Simone Weiß wrote: From: Simone Weiß Set `CVE_STATUS`for those CVEs, they have already been fixed with the latest pull for stable branch fixes done in rev e444d2bed0ea140a574414fcd5a689867e8ba312. Hence the issues are fixed already. Signed-off-by: Simone Weiß --- meta/recipes-core/glibc/glibc-version.inc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes-core/glibc/glibc-version.inc index ccf9d505c5..5f24a10826 100644 --- a/meta/recipes-core/glibc/glibc-version.inc +++ b/meta/recipes-core/glibc/glibc-version.inc @@ -10,4 +10,6 @@ UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+(\.(?!90)\d+)*)" CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4911] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4806] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-5156] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-0687] = "fixed-version: Fixed in stable branch updates" -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193572): https://lists.openembedded.org/g/openembedded-core/message/193572 Mute This Topic: https://lists.openembedded.org/mt/103663782/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] cve-check: Classify patched CVEs into 3 statuses
Hi Marta,
That's fine, as I said we designed the "ignore" with status
"cpe-incorrect" or "ignored" exactly for those purposes. Extending the
option with "not affected" doesn't make any sense.
You have to set the status to "why is not affected" = "ignored". Which
completely covers the requested case.
Regards,
Andrej
On 25.10.2023 11:33, Marta Rybczynska wrote:
Hi Andrej,
This is more complex. "Not affected" is also an issue that isn't present in the
code - like when we have a version that has never had the vulnerability.
Those are also currently 'Patched' in cve-check.
This work is in sync with what VEX is doing, is it the use-case
Matsanaga-Shinji?
Regards,
Marta
On Wed, Oct 25, 2023 at 8:44 AM Andrej Valek wrote:
Hi all,
Do we really need a new "not_affected" state? I guess the ignore state
is exactly designed for those purposes.
Regards,
Andrej
On 25.10.2023 07:13, Matsunaga-Shinji wrote:
CVEs that are currently considered "Patched" are classified into the following
3 statuses:
1. "Patched" - means that a patch file that fixed the vulnerability has
been applied
2. "Not affected" - means that the package version (PV) is not affected by the
vulnerability
3. "Undecidable" - means that versions cannot be compared to determine if they
are affected by the vulnerability
Signed-off-by: Shinji Matsunaga
Signed-off-by: Shunsuke Tokumoto
---
Changes for v2:
- Fix the status "Out of range" to "Not affected"
meta/classes/cve-check.bbclass | 55 +++---
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index b55f4299da..502db324df 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -185,10 +185,10 @@ python do_cve_check () {
patched_cves = get_patched_cves(d)
except FileNotFoundError:
bb.fatal("Failure in searching patches")
-ignored, patched, unpatched, status = check_cves(d, patched_cves)
-if patched or unpatched or (d.getVar("CVE_CHECK_COVERAGE") == "1"
and status):
-cve_data = get_cve_info(d, patched + unpatched + ignored)
-cve_write_data(d, patched, unpatched, ignored, cve_data,
status)
+ignored, patched, unpatched, not_affected, undecidable, status =
check_cves(d, patched_cves)
+if patched or unpatched or not_affected or undecidable or
(d.getVar("CVE_CHECK_COVERAGE") == "1" and status):
+cve_data = get_cve_info(d, patched + unpatched + ignored +
not_affected + undecidable)
+cve_write_data(d, patched, unpatched, ignored, not_affected,
undecidable, cve_data, status)
else:
bb.note("No CVE database found, skipping CVE check")
@@ -308,13 +308,13 @@ def check_cves(d, patched_cves):
products = d.getVar("CVE_PRODUCT").split()
# If this has been unset then we're not scanning for CVEs here (for
example, image recipes)
if not products:
-return ([], [], [], [])
+return ([], [], [], [], [], [])
pv = d.getVar("CVE_VERSION").split("+git")[0]
# If the recipe has been skipped/ignored we return empty lists
if pn in d.getVar("CVE_CHECK_SKIP_RECIPE").split():
bb.note("Recipe has been skipped by cve-check")
-return ([], [], [], [])
+return ([], [], [], [], [], [])
# Convert CVE_STATUS into ignored CVEs and check validity
cve_ignore = []
@@ -328,6 +328,8 @@ def check_cves(d, patched_cves):
conn = sqlite3.connect(db_file, uri=True)
# For each of the known product names (e.g. curl has CPEs using curl and
libcurl)...
+cves_not_affected = []
+cves_undecidable = []
for product in products:
cves_in_product = False
if ":" in product:
@@ -355,6 +357,7 @@ def check_cves(d, patched_cves):
vulnerable = False
ignored = False
+undecidable = False
product_cursor = conn.execute("SELECT * FROM PRODUCTS WHERE ID IS ?
AND PRODUCT IS ? AND VENDOR LIKE ?", (cve, product, vendor))
for row in product_cursor:
@@ -376,7 +379,7 @@ def check_cves(d, patched_cves):
except:
bb.warn("%s: Failed to compare %s %s %s for %s" %
(product, pv, operator_start,
version_start, cve))
-vulnerable_start = False
+undecidable = True
else:
vulnerable_start = False
@@ -387,10 +390,15 @@ def che
Re: [OE-core] [PATCH v2] cve-check: Classify patched CVEs into 3 statuses
Hi all,
Do we really need a new "not_affected" state? I guess the ignore state
is exactly designed for those purposes.
Regards,
Andrej
On 25.10.2023 07:13, Matsunaga-Shinji wrote:
CVEs that are currently considered "Patched" are classified into the following
3 statuses:
1. "Patched" - means that a patch file that fixed the vulnerability has
been applied
2. "Not affected" - means that the package version (PV) is not affected by the
vulnerability
3. "Undecidable" - means that versions cannot be compared to determine if they
are affected by the vulnerability
Signed-off-by: Shinji Matsunaga
Signed-off-by: Shunsuke Tokumoto
---
Changes for v2:
- Fix the status "Out of range" to "Not affected"
meta/classes/cve-check.bbclass | 55 +++---
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index b55f4299da..502db324df 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -185,10 +185,10 @@ python do_cve_check () {
patched_cves = get_patched_cves(d)
except FileNotFoundError:
bb.fatal("Failure in searching patches")
-ignored, patched, unpatched, status = check_cves(d, patched_cves)
-if patched or unpatched or (d.getVar("CVE_CHECK_COVERAGE") == "1"
and status):
-cve_data = get_cve_info(d, patched + unpatched + ignored)
-cve_write_data(d, patched, unpatched, ignored, cve_data,
status)
+ignored, patched, unpatched, not_affected, undecidable, status =
check_cves(d, patched_cves)
+if patched or unpatched or not_affected or undecidable or
(d.getVar("CVE_CHECK_COVERAGE") == "1" and status):
+cve_data = get_cve_info(d, patched + unpatched + ignored +
not_affected + undecidable)
+cve_write_data(d, patched, unpatched, ignored, not_affected,
undecidable, cve_data, status)
else:
bb.note("No CVE database found, skipping CVE check")
@@ -308,13 +308,13 @@ def check_cves(d, patched_cves):
products = d.getVar("CVE_PRODUCT").split()
# If this has been unset then we're not scanning for CVEs here (for
example, image recipes)
if not products:
-return ([], [], [], [])
+return ([], [], [], [], [], [])
pv = d.getVar("CVE_VERSION").split("+git")[0]
# If the recipe has been skipped/ignored we return empty lists
if pn in d.getVar("CVE_CHECK_SKIP_RECIPE").split():
bb.note("Recipe has been skipped by cve-check")
-return ([], [], [], [])
+return ([], [], [], [], [], [])
# Convert CVE_STATUS into ignored CVEs and check validity
cve_ignore = []
@@ -328,6 +328,8 @@ def check_cves(d, patched_cves):
conn = sqlite3.connect(db_file, uri=True)
# For each of the known product names (e.g. curl has CPEs using curl and libcurl)...
+cves_not_affected = []
+cves_undecidable = []
for product in products:
cves_in_product = False
if ":" in product:
@@ -355,6 +357,7 @@ def check_cves(d, patched_cves):
vulnerable = False
ignored = False
+undecidable = False
product_cursor = conn.execute("SELECT * FROM PRODUCTS WHERE ID IS ? AND PRODUCT IS ? AND VENDOR LIKE ?", (cve, product, vendor))
for row in product_cursor:
@@ -376,7 +379,7 @@ def check_cves(d, patched_cves):
except:
bb.warn("%s: Failed to compare %s %s %s for %s" %
(product, pv, operator_start,
version_start, cve))
-vulnerable_start = False
+undecidable = True
else:
vulnerable_start = False
@@ -387,10 +390,15 @@ def check_cves(d, patched_cves):
except:
bb.warn("%s: Failed to compare %s %s %s for %s" %
(product, pv, operator_end, version_end,
cve))
-vulnerable_end = False
+undecidable = True
else:
vulnerable_end = False
+if undecidable:
+bb.note("%s-%s is undecidable to %s" % (pn, real_pv,
cve))
+cves_undecidable.append(cve)
+break
+
if operator_start and operator_end:
vulnerable = vulnerable_start and vulnerable_end
else:
@@ -406,9 +414,9 @@ def check_cves(d, patched_cves):
break
product_cursor.close()
-if not vulnerable:
+if not undecidable and not vulnerable:
bb.note("%s-%s is not vulnerable to
[OE-core][PATCH] maintainers.inc: Modify email address
From: Andrej Valek andrej.va...@siemens.com -> andre...@skyrain.eu Signed-off-by: Andrej Valek --- meta/conf/distro/include/maintainers.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 17f038c71e..a7a74f1d2b 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -82,7 +82,7 @@ RECIPE_MAINTAINER:pn-buildtools-extended-tarball = "Richard Purdie -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#185061): https://lists.openembedded.org/g/openembedded-core/message/185061 Mute This Topic: https://lists.openembedded.org/mt/100439845/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] cve_check: convert CVE_CHECK_IGNORE to CVE_STATUS
- Try to add convert and apply statuses for old CVEs - Drop some obsolete ignores, while they are not relevant for current version Signed-off-by: Andrej Valek Reviewed-by: Peter Marko --- .../distro/include/cve-extra-exclusions.inc | 149 meta/recipes-bsp/grub/grub2.inc | 6 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 3 +- .../recipes-connectivity/bind/bind_9.18.16.bb | 2 +- .../bluez5/bluez5_5.68.bb | 4 +- .../openssh/openssh_9.3p1.bb | 9 +- .../openssl/openssl_3.1.1.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.3.bb | 4 +- meta/recipes-core/glibc/glibc_2.37.bb | 17 +- meta/recipes-core/libxml/libxml2_2.11.4.bb| 4 - meta/recipes-core/systemd/systemd_253.3.bb| 3 - meta/recipes-devtools/cmake/cmake.inc | 4 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 6 +- meta/recipes-devtools/gcc/gcc-13.1.inc| 3 +- meta/recipes-devtools/git/git_2.39.3.bb | 7 - meta/recipes-devtools/jquery/jquery_3.6.3.bb | 5 +- meta/recipes-devtools/ninja/ninja_1.11.1.bb | 3 +- .../recipes-devtools/python/python3_3.11.4.bb | 16 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 - meta/recipes-extended/cpio/cpio_2.14.bb | 3 +- meta/recipes-extended/cups/cups.inc | 17 +- .../iputils/iputils_20221126.bb | 5 +- .../libtirpc/libtirpc_1.3.3.bb| 3 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 - meta/recipes-extended/shadow/shadow_4.13.bb | 7 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 2 +- meta/recipes-extended/zip/zip_3.0.bb | 7 +- .../libnotify/libnotify_0.8.2.bb | 2 +- meta/recipes-gnome/librsvg/librsvg_2.56.1.bb | 3 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 19 +- .../linux/cve-exclusion_6.1.inc | 361 -- .../libpng/libpng_1.6.40.bb | 3 +- meta/recipes-multimedia/libtiff/tiff_4.5.1.bb | 4 +- .../libgcrypt/libgcrypt_1.10.2.bb | 4 +- .../recipes-support/libxslt/libxslt_1.1.38.bb | 4 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 3 +- meta/recipes-support/sqlite/sqlite3_3.42.0.bb | 6 - 41 files changed, 310 insertions(+), 421 deletions(-) diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc index 0ae63e2c63..61fb08dbeb 100644 --- a/meta/conf/distro/include/cve-extra-exclusions.inc +++ b/meta/conf/distro/include/cve-extra-exclusions.inc @@ -15,44 +15,43 @@ # the aim of sharing that work and ensuring we don't duplicate it. # +# strace https://nvd.nist.gov/vuln/detail/CVE-2000-0006 +CVE_STATUS[CVE-2000-0006] = "upstream-wontfix: CVE is more than 20 years old \ +with no resolution evident. Broken links in CVE database references make resolution impractical." -# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006 -# CVE is more than 20 years old with no resolution evident -# broken links in CVE database references make resolution impractical -CVE_CHECK_IGNORE += "CVE-2000-0006" - -# epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238 -# The issue here is spoofing of domain names using characters from other character sets. -# There has been much discussion amongst the epiphany and webkit developers and -# whilst there are improvements about how domains are handled and displayed to the user -# there is unlikely ever to be a single fix to webkit or epiphany which addresses this -# problem. Ignore this CVE as there isn't any mitigation or fix or way to progress this further -# we can seem to take. -CVE_CHECK_IGNORE += "CVE-2005-0238" - -# glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756 -# Issue is memory exhaustion via glob() calls, e.g. from within an ftp server -# Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681 -# Upstream don't see it as a security issue, ftp servers shouldn't be passing -# this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT or similar -CVE_CHECK_IGNORE += "CVE-2010-4756" - -# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509 -# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511 -# The encoding/xml package in go can potentially be used for security exploits if not used correctly -# CVE applies to a netapp product as well as flagging a general issue. We don't ship anything -# exposing this interface in an exploitable way -CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511" +# epiphany https://nvd.nist.gov/vuln/detail/CVE-2005-0238 +CVE_STATUS[CVE-2005-0238]
Re: [OE-core][PATCH v9 0/3] CVE-check handling
Even better, So I will make one more rebase, just for "[OE-core][PATCH v9 3/3] cve_check: convert CVE_CHECK_IGNORE to CVE_STATUS" Regards, Andrej On Wed, 2023-07-19 at 11:16 +, Ross Burton wrote: > On 19 Jul 2023, at 11:54, Richard Purdie > wrote: > > > > On Wed, 2023-07-19 at 10:26 +, Valek, Andrej wrote: > > > Hello, > > > > > > I would like to ask, what's the status here? > > > > I've asked for some people to help review it and I'm waiting on their > > feedback. FWIW they did promise "this morning" yesterday so they have > > around 6 minutes! > > I suspect I was that person :). I have no major objections to the patch now. > > Cheers, > Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184580): https://lists.openembedded.org/g/openembedded-core/message/184580 Mute This Topic: https://lists.openembedded.org/mt/99716038/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v9 0/3] CVE-check handling
Hello, I would like to ask, what's the status here? Regards, Andrej On Fri, 2023-06-23 at 13:14 +0200, Andrej Valek wrote: > After discussion in all parallel threads we proposed following variant which > covers both expressed requirements to have very small number of different cve > statuses and also very large number of them at the same time. > This is a compromise version which maybe is not ideal but deals with > conflicting responses we got. > > Changes compared to version 8: > - moved CVE_CHECK_STATUSMAP into separated cve-check-map.conf file > - this will allow to use it without inheriting the cve-check class, like for > SPDX > > Documentation will be updated in separated repository. > > meta/classes/cve-check.bbclass | 81 +++- > meta/conf/bitbake.conf | 1 + > meta/conf/cve-check-map.conf | 28 ++ > .../distro/include/cve-extra-exclusions.inc | 371 +- > meta/lib/oe/cve_check.py | 25 ++ > meta/lib/oeqa/selftest/cases/cve_check.py | 26 +- > meta/recipes-bsp/grub/grub2.inc | 6 +- > meta/recipes-connectivity/avahi/avahi_0.8.bb | 3 +- > .../recipes-connectivity/bind/bind_9.18.15.bb | 2 +- > .../bluez5/bluez5_5.66.bb | 4 +- > .../openssh/openssh_9.3p1.bb | 9 +- > .../openssl/openssl_3.1.1.bb | 3 +- > meta/recipes-core/coreutils/coreutils_9.3.bb | 4 +- > meta/recipes-core/glibc/glibc_2.37.bb | 17 +- > meta/recipes-core/libxml/libxml2_2.10.4.bb | 4 - > meta/recipes-core/systemd/systemd_253.3.bb | 3 - > meta/recipes-devtools/cmake/cmake.inc | 4 +- > meta/recipes-devtools/flex/flex_2.6.4.bb | 6 +- > meta/recipes-devtools/gcc/gcc-13.1.inc | 3 +- > meta/recipes-devtools/git/git_2.39.3.bb | 7 - > meta/recipes-devtools/jquery/jquery_3.6.3.bb | 5 +- > meta/recipes-devtools/ninja/ninja_1.11.1.bb | 3 +- > .../recipes-devtools/python/python3_3.11.3.bb | 13 +- > meta/recipes-devtools/qemu/qemu.inc | 13 +- > meta/recipes-devtools/rsync/rsync_3.2.7.bb | 3 - > meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 - > meta/recipes-extended/cpio/cpio_2.14.bb | 3 +- > meta/recipes-extended/cups/cups.inc | 17 +- > .../ghostscript/ghostscript_10.01.1.bb | 3 +- > .../iputils/iputils_20221126.bb | 5 +- > .../libtirpc/libtirpc_1.3.3.bb | 3 +- > .../logrotate/logrotate_3.21.0.bb | 5 +- > meta/recipes-extended/procps/procps_4.0.3.bb | 4 - > meta/recipes-extended/shadow/shadow_4.13.bb | 7 +- > meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- > .../xinetd/xinetd_2.3.15.4.bb | 2 +- > meta/recipes-extended/zip/zip_3.0.bb | 7 +- > .../libnotify/libnotify_0.8.2.bb | 2 +- > meta/recipes-gnome/librsvg/librsvg_2.56.0.bb | 3 +- > meta/recipes-graphics/builder/builder_0.1.bb | 3 +- > .../xorg-xserver/xserver-xorg.inc | 19 +- > .../linux/cve-exclusion_6.1.inc | 11 +- > .../libpng/libpng_1.6.39.bb | 3 +- > meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 10 +- > .../libgcrypt/libgcrypt_1.10.2.bb | 4 +- > .../recipes-support/libxslt/libxslt_1.1.38.bb | 4 +- > meta/recipes-support/lz4/lz4_1.9.4.bb | 3 +- > meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 7 - > 48 files changed, 403 insertions(+), 373 deletions(-) > create mode 100644 meta/conf/cve-check-map.conf > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#184575): https://lists.openembedded.org/g/openembedded-core/message/184575 Mute This Topic: https://lists.openembedded.org/mt/99716038/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v8 1/3] cve-check: add option to add additional patched CVEs
On Fri, 2023-06-23 at 10:02 +, Ross Burton wrote:
> On 22 Jun 2023, at 13:00, Andrej Valek via lists.openembedded.org
> wrote:
> > - Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
> > The CVE_STATUS should contain an information about status wich
> > is decoded in 3 items:
> > - generic status: "Ignored", "Patched" or "Unpatched"
> > - more detailed status enum
> > - description: free text describing reason for status
>
> I think this needs to be clearer about what the intended use of the keywords
> are.
>
> Is the canonical data the CVE_STATUS[CVE-1234-5678] attribute, and the mapping
> from the status there via CVE_CHECK_STATUSMAP simply for backwards
> compatibility with the existing file format? Is this deprecating the status
> fields in those files or is it just a high-level summary? Either way, that
> should be made clear.
>
Yes, it's for backport compatibility, and extending the existing "Ignored",
"Patched" statuses with reasons.
> > +# Possible options for CVE statuses
> > +
> > +# used by this class internally when fix is detected (NVD DB version check
> > or CVE patch file)
> > +CVE_CHECK_STATUSMAP[patched] = "Patched"
> > +# use when this class does not detect backported patch (e.g. vendor kernel
> > repo with cherry-picked CVE patch)
> > +CVE_CHECK_STATUSMAP[backported-patch] = "Patched"
> > +# use when NVD DB does not mention patched versions of stable/LTS branches
> > which have upstream CVE backports
> > +CVE_CHECK_STATUSMAP[cpe-stable-backport] = "Patched"
> > +# use when NVD DB does not mention correct version or does not mention any
> > verion at all
> > +CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
>
> It bothers me that some of these status flags are working around the fact that
> the CPE is incorrect, when that CPE data can be fixed. Instead of setting
> fixed-version, we can just mail NIST and fix the CPE.
>
Yes, but while you're sending it, the current status has to be covered. And you
don't know, if the CPE will be fixed or not.
> > +# used internally by this class if CVE vulnerability is detected which is
> > not marked as fixed or ignored
> > +CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
> > +# use when CVE is confirmed by upstream but fix is still not available
> > +CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
> > +
> > +# used for migration from old concept, do not use for new vulnerabilities
> > +CVE_CHECK_STATUSMAP[ignored] = "Ignored"
> > +# use when NVD DB wrongly indicates vulnerability which is actually for a
> > different component
> > +CVE_CHECK_STATUSMAP[cpe-incorrect] = "Ignored"
> > +# use when upstream does not accept the report as a vulnerability (e.g.
> > works as designed)
> > +CVE_CHECK_STATUSMAP[disputed] = "Ignored"
> > +# use when vulnerability depends on build or runtime configuration which is
> > not used
> > +CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored"
> > +# use when vulnerability affects other platform (e.g. Windows or Debian)
> > +CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
>
> > +# use when upstream acknowledged the vulnerability but does not plan to fix
> > it
> > +CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
>
> Is this any different to ‘disputed’?
>
Of course. In the "upstream-wontfix" status, we know, that it won't be fixed.
But for "disputed" you don't know, if it's a bug or not.
> Do we expect to add a lot more statuses to this table, or for users to add
> their own values? It feels like maybe this should be a dict in
> lib/oe/cve_check.py instead of exposed in the data store.
>
Exactly, know I moved it separated file, where users could extend their own
statuses. The current version is just a "basement" of supported one.
> > + # Process CVE_STATUS_GROUPS to set multiple statuses and optional
> > detail or description at once
> > + for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
> > + cve_group = d.getVar(cve_status_group)
> > + if cve_group is not None:
> > + for cve in cve_group.split():
> > + d.setVarFlag("CVE_STATUS", cve,
> > d.getVarFlag(cve_status_group, "status"))
> > + else:
> > + bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
> > cve_status_group)
> > +}
>
> CVE_STATUS_GROUPS isn’t documented in the class or the commit message.
>
Added a description directly into class.
>
Regards,
Andrej
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183325):
https://lists.openembedded.org/g/openembedded-core/message/183325
Mute This Topic: https://lists.openembedded.org/mt/99695984/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v9 2/3] oeqa/selftest/cve_check: rework test to new cve status handling
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26 +++
.../logrotate/logrotate_3.21.0.bb | 5 ++--
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c..60cecd1328 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,34 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"detail" : issue["detail"] if "detail" in issue else "",
+"description" : issue["description"] if "description" in
issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["detail"]), 0)
+self.assertEqual(len(found_cves["CVE-2011-1098"]["description"]),
0)
+detail = "not-applicable-platform"
+description = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1548"]["description"],
description)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1549"]["description"],
description)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1550"]["description"],
description)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60..b83f39b129 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,9 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "not-applicable-platform: CVE is debian, gentoo or
SUSE specific on the way logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183323):
https://lists.openembedded.org/g/openembedded-core/message/183323
Mute This Topic: https://lists.openembedded.org/mt/99716040/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v9 0/3] CVE-check handling
After discussion in all parallel threads we proposed following variant which covers both expressed requirements to have very small number of different cve statuses and also very large number of them at the same time. This is a compromise version which maybe is not ideal but deals with conflicting responses we got. Changes compared to version 8: - moved CVE_CHECK_STATUSMAP into separated cve-check-map.conf file - this will allow to use it without inheriting the cve-check class, like for SPDX Documentation will be updated in separated repository. meta/classes/cve-check.bbclass| 81 +++- meta/conf/bitbake.conf| 1 + meta/conf/cve-check-map.conf | 28 ++ .../distro/include/cve-extra-exclusions.inc | 371 +- meta/lib/oe/cve_check.py | 25 ++ meta/lib/oeqa/selftest/cases/cve_check.py | 26 +- meta/recipes-bsp/grub/grub2.inc | 6 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 3 +- .../recipes-connectivity/bind/bind_9.18.15.bb | 2 +- .../bluez5/bluez5_5.66.bb | 4 +- .../openssh/openssh_9.3p1.bb | 9 +- .../openssl/openssl_3.1.1.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.3.bb | 4 +- meta/recipes-core/glibc/glibc_2.37.bb | 17 +- meta/recipes-core/libxml/libxml2_2.10.4.bb| 4 - meta/recipes-core/systemd/systemd_253.3.bb| 3 - meta/recipes-devtools/cmake/cmake.inc | 4 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 6 +- meta/recipes-devtools/gcc/gcc-13.1.inc| 3 +- meta/recipes-devtools/git/git_2.39.3.bb | 7 - meta/recipes-devtools/jquery/jquery_3.6.3.bb | 5 +- meta/recipes-devtools/ninja/ninja_1.11.1.bb | 3 +- .../recipes-devtools/python/python3_3.11.3.bb | 13 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 - meta/recipes-extended/cpio/cpio_2.14.bb | 3 +- meta/recipes-extended/cups/cups.inc | 17 +- .../ghostscript/ghostscript_10.01.1.bb| 3 +- .../iputils/iputils_20221126.bb | 5 +- .../libtirpc/libtirpc_1.3.3.bb| 3 +- .../logrotate/logrotate_3.21.0.bb | 5 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 - meta/recipes-extended/shadow/shadow_4.13.bb | 7 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 2 +- meta/recipes-extended/zip/zip_3.0.bb | 7 +- .../libnotify/libnotify_0.8.2.bb | 2 +- meta/recipes-gnome/librsvg/librsvg_2.56.0.bb | 3 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 19 +- .../linux/cve-exclusion_6.1.inc | 11 +- .../libpng/libpng_1.6.39.bb | 3 +- meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 10 +- .../libgcrypt/libgcrypt_1.10.2.bb | 4 +- .../recipes-support/libxslt/libxslt_1.1.38.bb | 4 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 3 +- meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 7 - 48 files changed, 403 insertions(+), 373 deletions(-) create mode 100644 meta/conf/cve-check-map.conf -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183321): https://lists.openembedded.org/g/openembedded-core/message/183321 Mute This Topic: https://lists.openembedded.org/mt/99716038/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v9 1/3] cve-check: add option to add additional patched CVEs
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 81 --
meta/conf/bitbake.conf | 1 +
meta/conf/cve-check-map.conf | 28
meta/lib/oe/cve_check.py | 25 +++
4 files changed, 122 insertions(+), 13 deletions(-)
create mode 100644 meta/conf/cve-check-map.conf
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..55e3baf1ed 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,12 +70,28 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional detail and description for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
#
+# Settings the same status and reason for multiple CVEs is possible
+# via CVE_STATUS_GROUPS variable.
+#
+# CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
+#
+# CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0003"
+# CVE_STATUS_WIN[status] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS_PATCHED = "CVE-1234-0002 CVE-1234-0004"
+# CVE_STATUS_PATCHED[status] = "fixed-version: Fixed externally"
+#
+# All possible CVE statuses could be found in cve-check-map.conf
+# CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
# Layers to be excluded
@@ -88,6 +104,24 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE is deprecated in favor of CVE_STATUS")
+for cve in (d.getVar("CVE_CHECK_IGNORE") or "").split():
+d.setVarFlag("CVE_STATUS", cve, "ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
or description at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+cve_group = d.getVar(cve_status_group)
+if cve_group is not None:
+for cve in cve_group.split():
+d.setVarFlag("CVE_STATUS", cve, d.getVarFlag(cve_status_group,
"status"))
+else:
+bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
cve_status_group)
+}
+
def generate_json_report(d, out_path, link_path):
if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
import json
@@ -260,7 +294,7 @@ def check_cves(d, patched_cves):
"""
Connect to the NVD database and find unpatched cves.
"""
-from oe.cve_check import Version, convert_cve_version
+from oe.cve_check import Version, convert_cve_version, decode_cve_status
pn = d.getVar("PN")
real_pv = d.getVar("PV")
@@ -282,7 +316,12 @@ def check_cves(d, patched_cves):
bb.note("Recipe has been skipped by cve-check")
return ([], [], [], [])
-cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# Convert CVE_STATUS into ignored CVEs and check validity
+cve_ignore = []
+for cve in (d.getVarFlags("CVE_STATUS") or {}):
+decoded_status, _, _ = decode_cve_status(d, cve)
+if decoded_status == "Ignored":
+cve_ignore.append(cve)
impo
Re: [OE-core][PATCH v7 0/3] CVE-check handling
OK, Now I know what's the problem. SPDX are being created without inheriting the cve-check class. Regards, Andrej On Thu, 2023-06-22 at 15:59 +0200, Valek Andrej wrote: > Hello Luca, > > I wanted to check the logs, but it requires a login/password. Would it be > possible to send a link where is not required? Maybe here > https://autobuilder.yoctoproject.org/typhoon/#/ ? > > Regards, > Andrej > > On Thu, 2023-06-22 at 15:55 +0200, Luca Ceresoli wrote: > > Hello Andrej, > > > > On Thu, 22 Jun 2023 13:50:32 + > > "Andrej Valek via lists.openembedded.org" > > wrote: > > > > > Hello Luca, > > > > > > How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it > > > didn't print any warning. Should I build an image? > > > > I don't know how to reproduce _exactly_ the build environment of the > > autobuilders, however the logs have some good hints (click the "stdio" > > links in the page at the URL I provided). E.g. for the qemuarm64 > > builder it says: > > > > Running '. ./oe-init-build-env; bitbake core-image-sato core-image-sato-sdk > > core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk - > > k' > > ... > > MACHINE = "qemuarm64" > > DISTRO = "poky" > > ...and more settings you might want to put in your local.conf... > > > > So you may try that. > > > > Luca > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183246): https://lists.openembedded.org/g/openembedded-core/message/183246 Mute This Topic: https://lists.openembedded.org/mt/99693212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v7 0/3] CVE-check handling
Hello Luca, I wanted to check the logs, but it requires a login/password. Would it be possible to send a link where is not required? Maybe here https://autobuilder.yoctoproject.org/typhoon/#/ ? Regards, Andrej On Thu, 2023-06-22 at 15:55 +0200, Luca Ceresoli wrote: > Hello Andrej, > > On Thu, 22 Jun 2023 13:50:32 + > "Andrej Valek via lists.openembedded.org" > wrote: > > > Hello Luca, > > > > How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it > > didn't print any warning. Should I build an image? > > I don't know how to reproduce _exactly_ the build environment of the > autobuilders, however the logs have some good hints (click the "stdio" > links in the page at the URL I provided). E.g. for the qemuarm64 > builder it says: > > Running '. ./oe-init-build-env; bitbake core-image-sato core-image-sato-sdk > core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk -k' > ... > MACHINE = "qemuarm64" > DISTRO = "poky" > ...and more settings you might want to put in your local.conf... > > So you may try that. > > Luca > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183244): https://lists.openembedded.org/g/openembedded-core/message/183244 Mute This Topic: https://lists.openembedded.org/mt/99693212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v7 0/3] CVE-check handling
Hello Luca, How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it didn't print any warning. Should I build an image? Regards, Andrej On Thu, 2023-06-22 at 14:42 +0200, Luca Ceresoli wrote: > Hello Andrej, > > On Thu, 22 Jun 2023 08:59:02 +0200 > "Andrej Valek via lists.openembedded.org" > wrote: > > > After discussion in all parallel threads we proposed following variant which > > covers both expressed requirements to have very small number of different > > cve > > statuses and also very large number of them at the same time. > > This is a compromise version which maybe is not ideal but deals with > > conflicting responses we got. > > > > Changes compare to version 6: > > - added conversion from CVE_CHECK_IGNORE to CVE_STATUS > > - added comments for all statuses > > - dropped "not-affected" status > > - conversion showed that it is not very usefull > > - added "disputed" status > > > > Documentation will be updated in separated repository. > > This patchset generates a lot of warnings when run on the autobuilders. > Here are a few: > > WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail cpe-incorrect for > CVE_STATUS[CVE-2017-5957] = "cpe-incorrect: Applies against virglrender < > 0.6.0 and not qemu itself", fallback to Unpatched > WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail not-applicable-config > for CVE_STATUS[CVE-2007-0998] = "not-applicable-config: The VNC server can > expose host files uder some circumstances. We don't enable it by default.", > fallback to Unpatched > WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail disputed for > CVE_STATUS[CVE-2018-18438] = "disputed: The issues identified by this CVE were > determined to not constitute a vulnerability.", fallback to Unpatched > NOTE: recipe python3-calver-2022.6.26-r0: task do_create_runtime_spdx: > Succeeded > WARNING: qemu-8.0.0-r0 do_create_spdx: Invalid detail not-applicable-platform > for CVE_STATUS[CVE-2023-0664] = "not-applicable-platform: Issue only applies > on Windows", fallback to Unpatched > > WARNING: cpio-2.14-r0 do_create_spdx: Invalid detail not-applicable-platform > for CVE_STATUS[CVE-2010-4226] = "not-applicable-platform: Issue applies to use > of cpio in SUSE/OBS", fallback to Unpatched > > WARNING: bluez5-5.66-r0 do_create_spdx: Invalid detail cpe-incorrect for > CVE_STATUS[CVE-2022-3563] = "cpe-incorrect: This issues have kernel fixes > rather than bluez fixes", fallback to Unpatched > WARNING: bluez5-5.66-r0 do_create_spdx: Invalid detail cpe-incorrect for > CVE_STATUS[CVE-2022-3637] = "cpe-incorrect: This issues have kernel fixes > rather than bluez fixes", fallback to Unpatched > > For a more complete list you can look at the build page: > https://swatbot.yoctoproject.org/collection/17294/ > > All/most of the warnings are about CVEs. > > I haven't looked in detail at what is the intended behavior of your > patch set, however I'm removing it from my testing branch for the time > being. > > Best regards, > Luca > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183242): https://lists.openembedded.org/g/openembedded-core/message/183242 Mute This Topic: https://lists.openembedded.org/mt/99693212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v8 1/3] cve-check: add option to add additional patched CVEs
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 99 +-
meta/lib/oe/cve_check.py | 25 +
2 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..4eb6dff7de 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,14 +70,48 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional detail and description for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
#
+# CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
+# Possible options for CVE statuses
+
+# used by this class internally when fix is detected (NVD DB version check or
CVE patch file)
+CVE_CHECK_STATUSMAP[patched] = "Patched"
+# use when this class does not detect backported patch (e.g. vendor kernel
repo with cherry-picked CVE patch)
+CVE_CHECK_STATUSMAP[backported-patch] = "Patched"
+# use when NVD DB does not mention patched versions of stable/LTS branches
which have upstream CVE backports
+CVE_CHECK_STATUSMAP[cpe-stable-backport] = "Patched"
+# use when NVD DB does not mention correct version or does not mention any
verion at all
+CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+
+# used internally by this class if CVE vulnerability is detected which is not
marked as fixed or ignored
+CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
+# use when CVE is confirmed by upstream but fix is still not available
+CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
+
+# used for migration from old concept, do not use for new vulnerabilities
+CVE_CHECK_STATUSMAP[ignored] = "Ignored"
+# use when NVD DB wrongly indicates vulnerability which is actually for a
different component
+CVE_CHECK_STATUSMAP[cpe-incorrect] = "Ignored"
+# use when upstream does not accept the report as a vulnerability (e.g. works
as designed)
+CVE_CHECK_STATUSMAP[disputed] = "Ignored"
+# use when vulnerability depends on build or runtime configuration which is
not used
+CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored"
+# use when vulnerability affects other platform (e.g. Windows or Debian)
+CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# use when upstream acknowledged the vulnerability but does not plan to fix it
+CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
+
# Layers to be excluded
CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -88,6 +122,24 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE is deprecated in favor of CVE_STATUS")
+for cve in (d.getVar("CVE_CHECK_IGNORE") or "").split():
+d.setVarFlag("CVE_STATUS", cve, "ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
or description at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+cve_group = d.getVar(cve_status_group)
+if cve_group is not None:
+for cve in cve_group.split():
+d.setVarFlag("CVE_STATUS", cve
[OE-core][PATCH v8 2/3] oeqa/selftest/cve_check: rework test to new cve status handling
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26 +++
.../logrotate/logrotate_3.21.0.bb | 5 ++--
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c..60cecd1328 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,34 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"detail" : issue["detail"] if "detail" in issue else "",
+"description" : issue["description"] if "description" in
issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["detail"]), 0)
+self.assertEqual(len(found_cves["CVE-2011-1098"]["description"]),
0)
+detail = "not-applicable-platform"
+description = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1548"]["description"],
description)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1549"]["description"],
description)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1550"]["description"],
description)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60..b83f39b129 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,9 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "not-applicable-platform: CVE is debian, gentoo or
SUSE specific on the way logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183239):
https://lists.openembedded.org/g/openembedded-core/message/183239
Mute This Topic: https://lists.openembedded.org/mt/99695985/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v8 0/3] CVE-check handling
After discussion in all parallel threads we proposed following variant which covers both expressed requirements to have very small number of different cve statuses and also very large number of them at the same time. This is a compromise version which maybe is not ideal but deals with conflicting responses we got. Changes compared to version 7: - reverted dropped CVE ignores for lz4 and tiff Documentation will be updated in separated repository. meta/classes/cve-check.bbclass| 99 - .../distro/include/cve-extra-exclusions.inc | 371 +- meta/lib/oe/cve_check.py | 25 ++ meta/lib/oeqa/selftest/cases/cve_check.py | 26 +- meta/recipes-bsp/grub/grub2.inc | 6 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 3 +- .../recipes-connectivity/bind/bind_9.18.15.bb | 2 +- .../bluez5/bluez5_5.66.bb | 4 +- .../openssh/openssh_9.3p1.bb | 9 +- .../openssl/openssl_3.1.1.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.3.bb | 4 +- meta/recipes-core/glibc/glibc_2.37.bb | 17 +- meta/recipes-core/libxml/libxml2_2.10.4.bb| 4 - meta/recipes-core/systemd/systemd_253.3.bb| 3 - meta/recipes-devtools/cmake/cmake.inc | 4 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 6 +- meta/recipes-devtools/gcc/gcc-13.1.inc| 3 +- meta/recipes-devtools/git/git_2.39.3.bb | 7 - meta/recipes-devtools/jquery/jquery_3.6.3.bb | 5 +- meta/recipes-devtools/ninja/ninja_1.11.1.bb | 3 +- .../recipes-devtools/python/python3_3.11.3.bb | 13 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 - meta/recipes-extended/cpio/cpio_2.14.bb | 3 +- meta/recipes-extended/cups/cups.inc | 17 +- .../ghostscript/ghostscript_10.01.1.bb| 3 +- .../iputils/iputils_20221126.bb | 5 +- .../libtirpc/libtirpc_1.3.3.bb| 3 +- .../logrotate/logrotate_3.21.0.bb | 5 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 - meta/recipes-extended/shadow/shadow_4.13.bb | 7 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 2 +- meta/recipes-extended/zip/zip_3.0.bb | 7 +- .../libnotify/libnotify_0.8.2.bb | 2 +- meta/recipes-gnome/librsvg/librsvg_2.56.0.bb | 3 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 19 +- .../linux/cve-exclusion_6.1.inc | 11 +- .../libpng/libpng_1.6.39.bb | 3 +- meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 10 +- .../libgcrypt/libgcrypt_1.10.2.bb | 4 +- .../recipes-support/libxslt/libxslt_1.1.38.bb | 4 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 3 +- meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 7 - 46 files changed, 392 insertions(+), 373 deletions(-) -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183237): https://lists.openembedded.org/g/openembedded-core/message/183237 Mute This Topic: https://lists.openembedded.org/mt/99695982/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v7 1/3] cve-check: add option to add additional patched CVEs
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 99 +-
meta/lib/oe/cve_check.py | 25 +
2 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..4eb6dff7de 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,14 +70,48 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional detail and description for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
#
+# CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
+# Possible options for CVE statuses
+
+# used by this class internally when fix is detected (NVD DB version check or
CVE patch file)
+CVE_CHECK_STATUSMAP[patched] = "Patched"
+# use when this class does not detect backported patch (e.g. vendor kernel
repo with cherry-picked CVE patch)
+CVE_CHECK_STATUSMAP[backported-patch] = "Patched"
+# use when NVD DB does not mention patched versions of stable/LTS branches
which have upstream CVE backports
+CVE_CHECK_STATUSMAP[cpe-stable-backport] = "Patched"
+# use when NVD DB does not mention correct version or does not mention any
verion at all
+CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+
+# used internally by this class if CVE vulnerability is detected which is not
marked as fixed or ignored
+CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
+# use when CVE is confirmed by upstream but fix is still not available
+CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
+
+# used for migration from old concept, do not use for new vulnerabilities
+CVE_CHECK_STATUSMAP[ignored] = "Ignored"
+# use when NVD DB wrongly indicates vulnerability which is actually for a
different component
+CVE_CHECK_STATUSMAP[cpe-incorrect] = "Ignored"
+# use when upstream does not accept the report as a vulnerability (e.g. works
as designed)
+CVE_CHECK_STATUSMAP[disputed] = "Ignored"
+# use when vulnerability depends on build or runtime configuration which is
not used
+CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored"
+# use when vulnerability affects other platform (e.g. Windows or Debian)
+CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# use when upstream acknowledged the vulnerability but does not plan to fix it
+CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
+
# Layers to be excluded
CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -88,6 +122,24 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE is deprecated in favor of CVE_STATUS")
+for cve in (d.getVar("CVE_CHECK_IGNORE") or "").split():
+d.setVarFlag("CVE_STATUS", cve, "ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
or description at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+cve_group = d.getVar(cve_status_group)
+if cve_group is not None:
+for cve in cve_group.split():
+d.setVarFlag("CVE_STATUS", cve
[OE-core][PATCH v7 2/3] oeqa/selftest/cve_check: rework test to new cve status handling
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26 +++
.../logrotate/logrotate_3.21.0.bb | 5 ++--
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c..60cecd1328 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,34 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"detail" : issue["detail"] if "detail" in issue else "",
+"description" : issue["description"] if "description" in
issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["detail"]), 0)
+self.assertEqual(len(found_cves["CVE-2011-1098"]["description"]),
0)
+detail = "not-applicable-platform"
+description = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1548"]["description"],
description)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1549"]["description"],
description)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1550"]["description"],
description)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60..b83f39b129 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,9 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "not-applicable-platform: CVE is debian, gentoo or
SUSE specific on the way logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183226):
https://lists.openembedded.org/g/openembedded-core/message/183226
Mute This Topic: https://lists.openembedded.org/mt/99693214/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v7 0/3] CVE-check handling
After discussion in all parallel threads we proposed following variant which covers both expressed requirements to have very small number of different cve statuses and also very large number of them at the same time. This is a compromise version which maybe is not ideal but deals with conflicting responses we got. Changes compare to version 6: - added conversion from CVE_CHECK_IGNORE to CVE_STATUS - added comments for all statuses - dropped "not-affected" status - conversion showed that it is not very usefull - added "disputed" status Documentation will be updated in separated repository. meta/classes/cve-check.bbclass| 99 - .../distro/include/cve-extra-exclusions.inc | 371 +- meta/lib/oe/cve_check.py | 25 ++ meta/lib/oeqa/selftest/cases/cve_check.py | 26 +- meta/recipes-bsp/grub/grub2.inc | 6 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 3 +- .../recipes-connectivity/bind/bind_9.18.15.bb | 2 +- .../bluez5/bluez5_5.66.bb | 4 +- .../openssh/openssh_9.3p1.bb | 9 +- .../openssl/openssl_3.1.1.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.3.bb | 4 +- meta/recipes-core/glibc/glibc_2.37.bb | 17 +- meta/recipes-core/libxml/libxml2_2.10.4.bb| 4 - meta/recipes-core/systemd/systemd_253.3.bb| 3 - meta/recipes-devtools/cmake/cmake.inc | 4 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 6 +- meta/recipes-devtools/gcc/gcc-13.1.inc| 3 +- meta/recipes-devtools/git/git_2.39.3.bb | 7 - meta/recipes-devtools/jquery/jquery_3.6.3.bb | 5 +- meta/recipes-devtools/ninja/ninja_1.11.1.bb | 3 +- .../recipes-devtools/python/python3_3.11.3.bb | 13 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 - meta/recipes-extended/cpio/cpio_2.14.bb | 3 +- meta/recipes-extended/cups/cups.inc | 17 +- .../ghostscript/ghostscript_10.01.1.bb| 3 +- .../iputils/iputils_20221126.bb | 5 +- .../libtirpc/libtirpc_1.3.3.bb| 3 +- .../logrotate/logrotate_3.21.0.bb | 5 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 - meta/recipes-extended/shadow/shadow_4.13.bb | 7 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 2 +- meta/recipes-extended/zip/zip_3.0.bb | 7 +- .../libnotify/libnotify_0.8.2.bb | 2 +- meta/recipes-gnome/librsvg/librsvg_2.56.0.bb | 3 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 19 +- .../linux/cve-exclusion_6.1.inc | 11 +- .../libpng/libpng_1.6.39.bb | 3 +- meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 9 +- .../libgcrypt/libgcrypt_1.10.2.bb | 4 +- .../recipes-support/libxslt/libxslt_1.1.38.bb | 4 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 3 - meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 7 - 46 files changed, 390 insertions(+), 374 deletions(-) -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183224): https://lists.openembedded.org/g/openembedded-core/message/183224 Mute This Topic: https://lists.openembedded.org/mt/99693212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v6 2/2] RFC: oeqa/selftest/cve_check: rework test to new cve status handling
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26 +++
.../logrotate/logrotate_3.21.0.bb | 5 ++--
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c..60cecd1328 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,34 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"detail" : issue["detail"] if "detail" in issue else "",
+"description" : issue["description"] if "description" in
issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["detail"]), 0)
+self.assertEqual(len(found_cves["CVE-2011-1098"]["description"]),
0)
+detail = "not-applicable-platform"
+description = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1548"]["description"],
description)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1549"]["description"],
description)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1550"]["description"],
description)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60..b83f39b129 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,9 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "not-applicable-platform: CVE is debian, gentoo or
SUSE specific on the way logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183140):
https://lists.openembedded.org/g/openembedded-core/message/183140
Mute This Topic: https://lists.openembedded.org/mt/99644854/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v6 1/2] RFC: cve-check: add option to add additional patched CVEs
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 86 +-
meta/lib/oe/cve_check.py | 25 ++
2 files changed, 98 insertions(+), 13 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..6710c1d6bb 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,14 +70,35 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional detail and description for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
#
+# CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
+# Possible options for CVE statuses
+CVE_CHECK_STATUSMAP[patched] = "Patched"
+CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+CVE_CHECK_STATUSMAP[backported-patch] = "Patched"
+CVE_CHECK_STATUSMAP[cpe-stable-backport] = "Patched"
+
+CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
+CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
+
+CVE_CHECK_STATUSMAP[ignored] = "Ignored"
+CVE_CHECK_STATUSMAP[cpe-incorrect] = "Ignored"
+CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
+CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored"
+CVE_CHECK_STATUSMAP[not-affected] = "Ignored"
+
# Layers to be excluded
CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -88,6 +109,24 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE is deprecated in favor of CVE_STATUS")
+for cve in (d.getVar("CVE_CHECK_IGNORE") or "").split():
+d.setVarFlag("CVE_STATUS", cve, "ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
or description at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+cve_group = d.getVar(cve_status_group)
+if cve_group is not None:
+for cve in cve_group.split():
+d.setVarFlag("CVE_STATUS", cve, d.getVarFlag(cve_status_group,
"status"))
+else:
+bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
cve_status_group)
+}
+
def generate_json_report(d, out_path, link_path):
if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
import json
@@ -260,7 +299,7 @@ def check_cves(d, patched_cves):
"""
Connect to the NVD database and find unpatched cves.
"""
-from oe.cve_check import Version, convert_cve_version
+from oe.cve_check import Version, convert_cve_version, decode_cve_status
pn = d.getVar("PN")
real_pv = d.getVar("PV")
@@ -282,7 +321,12 @@ def check_cves(d, patched_cves):
bb.note("Recipe has been skipped by cve-check")
return ([], [], [], [])
-cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# Convert CVE_STATUS into ignored CVEs and check validity
+cve_ignore = []
+for cve in (d.getVarFlags("CVE_STATUS") or {}):
+decoded_status, _, _ = decode_cve_st
[OE-core][PATCH v6 0/2] RFC: CVE-check handling
After discussion in all parallel threads we proposed following variant which covers both expressed requirements to have very small number of different cve statuses and also very large number of them at the same time. This is a compromise version which maybe is not ideal but deals with conflicting responses we got. This patches version is missing commit for CVE_CHECK_IGNORE to CVE_STATUS conversion as it is large effort and current implementation is still in discussion. Once the concept is agreed, that commit will be added in next patchset version. Documentation is not updated too while current implementation is still in discussion. meta/classes/cve-check.bbclass| 86 --- meta/lib/oe/cve_check.py | 25 ++ meta/lib/oeqa/selftest/cases/cve_check.py | 26 -- .../logrotate/logrotate_3.21.0.bb | 5 +- 4 files changed, 122 insertions(+), 20 deletions(-) -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183139): https://lists.openembedded.org/g/openembedded-core/message/183139 Mute This Topic: https://lists.openembedded.org/mt/99644853/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell][PATCH 2/2] curl: whitelists CVE-2022-42915, CVE-2022-42916 and CVE-2022-43551
This was sent by misstate, ignore it please.
Andrej
On Mon, 2023-06-12 at 13:57 +0200, Andrej Valek wrote:
> All mentioned CVEs are related to HSTS check feature, which is not
> implemented in version 7.69.1 .
>
> Signed-off-by: Andrej Valek
> ---
> meta/recipes-support/curl/curl_7.69.1.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-support/curl/curl_7.69.1.bb b/meta/recipes-
> support/curl/curl_7.69.1.bb
> index 899daf8eac..ea36c0bd3d 100644
> --- a/meta/recipes-support/curl/curl_7.69.1.bb
> +++ b/meta/recipes-support/curl/curl_7.69.1.bb
> @@ -56,6 +56,9 @@ CVE_CHECK_WHITELIST = "CVE-2021-22922 CVE-2021-22923 CVE-
> 2021-22926 CVE-2021-229
> # This CVE issue affects Windows only Hence whitelisting this CVE
> CVE_CHECK_WHITELIST += "CVE-2021-22897"
>
> +# HSTS check feature is not implemented
> +CVE_CHECK_WHITELIST += "CVE-2022-42915 CVE-2022-42916 CVE-2022-43551"
> +
> inherit autotools pkgconfig binconfig multilib_header
>
> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls
> libidn proxy threaded-resolver verbose zlib"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#182668):
https://lists.openembedded.org/g/openembedded-core/message/182668
Mute This Topic: https://lists.openembedded.org/mt/99481050/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v5 2/2] oeqa/selftest/cve_check: add check for opt "detail" and "description" values
- After introducing the CVE_STATUS_DETAIL and CVE_STATUS_DESCRIPTION flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26 +++
.../logrotate/logrotate_3.21.0.bb | 7 +++--
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c..60cecd1328 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,34 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"detail" : issue["detail"] if "detail" in issue else "",
+"description" : issue["description"] if "description" in
issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["detail"]), 0)
+self.assertEqual(len(found_cves["CVE-2011-1098"]["description"]),
0)
+detail = "not-applicable-platform"
+description = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1548"]["description"],
description)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1549"]["description"],
description)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1550"]["description"],
description)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60..48497138be 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,11 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "Ignored"
+CVE_STATUS_RECIPE[detail] = "not-applicable-platform"
+CVE_STATUS_RECIPE[description] = "CVE is debian, gentoo or SUSE specific on
the way logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#182667):
https://lists.openembedded.org/g/openembedded-core/message/182667
Mute This Topic: https://lists.openembedded.org/mt/99481068/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell][PATCH 2/2] curl: whitelists CVE-2022-42915, CVE-2022-42916 and CVE-2022-43551
All mentioned CVEs are related to HSTS check feature, which is not
implemented in version 7.69.1 .
Signed-off-by: Andrej Valek
---
meta/recipes-support/curl/curl_7.69.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
b/meta/recipes-support/curl/curl_7.69.1.bb
index 899daf8eac..ea36c0bd3d 100644
--- a/meta/recipes-support/curl/curl_7.69.1.bb
+++ b/meta/recipes-support/curl/curl_7.69.1.bb
@@ -56,6 +56,9 @@ CVE_CHECK_WHITELIST = "CVE-2021-22922 CVE-2021-22923
CVE-2021-22926 CVE-2021-229
# This CVE issue affects Windows only Hence whitelisting this CVE
CVE_CHECK_WHITELIST += "CVE-2021-22897"
+# HSTS check feature is not implemented
+CVE_CHECK_WHITELIST += "CVE-2022-42915 CVE-2022-42916 CVE-2022-43551"
+
inherit autotools pkgconfig binconfig multilib_header
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls
libidn proxy threaded-resolver verbose zlib"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#182666):
https://lists.openembedded.org/g/openembedded-core/message/182666
Mute This Topic: https://lists.openembedded.org/mt/99481050/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v5 1/2] cve-check: add option to add additional patched CVEs
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_DETAIL] +
[CVE_STATUS_DESCRIPTION] to be more flexible. CVE_STATUS should
contain flag for each CVE with accepted values "Ignored", "Patched"
or "Unpatched". It allows to add a status for each CVEs.
- Optional CVE_STATUS_DEATAIL flag variable may contain a detailed
status. Possible options for each status:
- Patched
- fixed-version, backported-patch, cpe-stable-backport or other
- Unpatched
- vulnerable-investigating or other
- Ignored
- cpe-incorrect, not-applicable-platform, upstream-wontfix
not-applicable-config, not-affected or other
- Optional CVE_STATUS_DESCRIPTION flag variable may contain a reason
why the CVE status was used. Both optionals will be added in csv/json
report like a new "detail" an "description" entries
- Settings the same status and reason for multiple CVEs is possible
via CVE_STATUS_GROUPS variable.
- All listed CVEs in CVE_CHECK_IGNORE are copied to CVE_STATUS with
value "Ignored" like a fallback.
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Patched" or "Unpatched"
CVE_STATUS[CVE-1234-0002] = "Ignored"
CVE_STATUS_DETAIL[CVE-1234-0002] = "not-applicable-platform"
CVE_STATUS_DESCRIPTION[CVE-1234-0002] = "Issue only applies on Windows"
CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0002"
CVE_STATUS_WIN[status] = "Ignored"
CVE_STATUS_DETAIL[detail] = "not-applicable-platform"
CVE_STATUS_WIN[description] = "Issue only applies on Windows"
CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-1234-0004"
CVE_STATUS_PATCHED[status] = "Patched"
CVE_STATUS_DETAIL[detail] = "fixed-version"
CVE_STATUS_PATCHED[description] = "Fixed externally"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 89 +-
meta/lib/oe/cve_check.py | 6 +++
2 files changed, 83 insertions(+), 12 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..62676ba5bc 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,12 +70,16 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional detail and description for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Patched" or "Unpatched"
+# CVE_STATUS[CVE-1234-0002] = "Ignored"
+# CVE_STATUS_DETAIL[CVE-1234-0002] = "not-applicable-platform"
+# CVE_STATUS_DESCRIPTION[CVE-1234-0002] = "Issue only applies on Windows"
#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
# Layers to be excluded
@@ -88,6 +92,47 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE is deprecated in favor of CVE_STATUS")
+set_cves_statuses(d, d.getVar("CVE_CHECK_IGNORE"), "Ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
or description at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+cve_group = d.getVar(cve_status_group)
+if cve_group is not None:
+set_cves_statuses(d, cve_group,
+ d.getVarFlag(cve_status_group, "status"),
+ d.getVarFlag(cve_status_group, "detail"),
+ d.getVarFlag(cve_status_group, "description"))
+else:
+bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
cve_status_group)
+}
+
+def set_cves_statuses(d, cves, status, detail="", description=""):
+for cve in cves.split():
+d.setVarFlag("CVE_STATUS", cve, status)
+d.setVarFlag("CVE_STATUS_DETAIL", cve, detail)
+d.setVarFlag("CVE_STATUS_DESCRIPTION", cve, description)
+
+def get_cve_detail(d, cve, status):
+detail = d.getVarFlag("CVE_STATUS
[OE-core][PATCH v5 0/2] CVE-check handling
After discussion in all parallel threads we proposed following variant which
covers both expressed requirements to have very small number of different cve
statuses and also very large number of them at the same time.
This is a compromise version which maybe is not ideal but deals with
conflicting responses we got.
Please guide us which direction do we need to go to get further with acceptance
of this patch series.
The CVE_CHECK_IGNORE variable is now deprecated in favor of CVE_STATUS variable.
The variable contains the same values like before ("Ignored", "Patched"
and "Unpatched"). The previous implementation has been extended by two
additional optional variables, CVE_STATUS_DETAIL and CVE_STATUS_DESCRIPTION.
meta/classes/cve-check.bbclass| 89 ---
meta/lib/oe/cve_check.py | 6 ++
meta/lib/oeqa/selftest/cases/cve_check.py | 26 --
.../logrotate/logrotate_3.21.0.bb | 7 +-
4 files changed, 109 insertions(+), 19 deletions(-)
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#182664):
https://lists.openembedded.org/g/openembedded-core/message/182664
Mute This Topic: https://lists.openembedded.org/mt/99481048/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs
Hello again Richard, Maybe this email was little bit unclear..., so I will try to recap it here. There are 2 open points, where some final decision has to be made. - Could we rename the CVE_STATUS_REASONING -> CVE_STATUS_REASON? The first idea came from you. - What is the final enum for CVE_STATUS? I would say "patched" and "ignored". Afaik, the "not applicable" status came also from you. Should we keep it, or remove it? Of course all others are just like an additions which could be implemented later on request. So please, take a look on it and made a final decision. Thank you, Andrej On Tue, 2023-05-23 at 10:41 +0200, Valek Andrej wrote: > Hello Richard, > > Could you please take a look on the latest revision a make a decision there? > There are still bunch of unclear statements. So please make a final design and > we will try to implement it. > > Thank you, > Andrej > > On Mon, 2023-05-22 at 10:57 +0300, Mikko Rapeli wrote: > > Hi, > > > > On Fri, May 19, 2023 at 03:11:57PM +0200, Marta Rybczynska wrote: > > > I'm missing a status to cover the situation when the NVD (or any other > > > database) has an incorrect entry. We have quite many of those. This might > > > be a temporary situation, but not always. > > > > > > SPDX (the 3.0 draft) has some other possible reasons > > > https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md > > > What looks like interesting ideas are: > > > * "Can't fix" / "Will not fix" > > > * "Not applicable" (SPDX language: Ineffective) when the code is not used > > > * "Invalid match" (this is our NVD mismatch case) > > > * "Mitigated" measures taken so that it cannot be exploited > > > * "Workarounded" > > > > To me the SPDX details don't seem very usable when actually maintaining > > a linux distro for a long time. Anyone from major Linux distro > > stable/security teams participating in the work? > > > > So I'd rather compare to Debian security tracker CVE status data and ask > > what our LTS and master branch maintainers and those in the community > > who maintain yocto based SW stacks need. Do the maintainers want to read > > SPDX output, for example? What common statuses do the maintainers want to > > encode for each CVE? > > > > Debian security tracker > > https://security-team.debian.org/security_tracker.html > > shows states: > > > > * vulnerable: binary package with specified version in their distro > > version is vulnerable to the issue > > > > * fixed: binary package in their distro version has fixed the issue > > > > * undetermined: it is not yet clear if the issue affects Debian and > > their version of the packages > > > > And "vulnerable" has sub states: > > > > * ignored: the issue does not impact Debian packages > > > > * postponed: no security patch updates will be provided, e.g. such a > > minor issue that update will happen for example via normal package > > version updates to next stable version > > > > There are a lot of additional "standards" and sub states when looking at > > CVE data in the tracker (info not public, no upstream fix available, not > > supported configuration etc), but those major high level states are enough. > > And then there are security relevant bugs without CVEs. > > > > I've been happy with "Unpatched", "Patched" and "Ignored" states for > > each CVE detected by cve-check.bbclass. There could be a few more sub > > stated to "Ignored" and the "Patched" state should better reflect reality, > > which this patch set helps. But I'm happy with that. > > > > I'm not so happy with the SPDX states names and meanings. > > > > Cheers, > > > > -Mikko > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181854): https://lists.openembedded.org/g/openembedded-core/message/181854 Mute This Topic: https://lists.openembedded.org/mt/99007092/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2] busybox: 1.36.0 -> 1.36.1
- regression on x86 is still in place
Signed-off-by: Andrej Valek
---
.../{busybox-inittab_1.36.0.bb => busybox-inittab_1.36.1.bb}| 0
.../busybox/{busybox_1.36.0.bb => busybox_1.36.1.bb}| 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-core/busybox/{busybox-inittab_1.36.0.bb =>
busybox-inittab_1.36.1.bb} (100%)
rename meta/recipes-core/busybox/{busybox_1.36.0.bb => busybox_1.36.1.bb} (96%)
diff --git a/meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
b/meta/recipes-core/busybox/busybox-inittab_1.36.1.bb
similarity index 100%
rename from meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
rename to meta/recipes-core/busybox/busybox-inittab_1.36.1.bb
diff --git a/meta/recipes-core/busybox/busybox_1.36.0.bb
b/meta/recipes-core/busybox/busybox_1.36.1.bb
similarity index 96%
rename from meta/recipes-core/busybox/busybox_1.36.0.bb
rename to meta/recipes-core/busybox/busybox_1.36.1.bb
index 8014a5c7bf..968dce65e4 100644
--- a/meta/recipes-core/busybox/busybox_1.36.0.bb
+++ b/meta/recipes-core/busybox/busybox_1.36.1.bb
@@ -53,4 +53,4 @@ SRC_URI =
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
SRC_URI:append:libc-musl = " file://musl.cfg "
# TODO http://lists.busybox.net/pipermail/busybox/2023-January/090078.html
SRC_URI:append:x86 = " file://sha_accel.cfg"
-SRC_URI[tarball.sha256sum] =
"542750c8af7cb2630e201780b4f99f3dcceeb06f505b479ec68241c1e6af61a5"
+SRC_URI[tarball.sha256sum] =
"b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181757):
https://lists.openembedded.org/g/openembedded-core/message/181757
Mute This Topic: https://lists.openembedded.org/mt/99144514/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs
Hello Richard, Could you please take a look on the latest revision a make a decision there? There are still bunch of unclear statements. So please make a final design and we will try to implement it. Thank you, Andrej On Mon, 2023-05-22 at 10:57 +0300, Mikko Rapeli wrote: > Hi, > > On Fri, May 19, 2023 at 03:11:57PM +0200, Marta Rybczynska wrote: > > I'm missing a status to cover the situation when the NVD (or any other > > database) has an incorrect entry. We have quite many of those. This might > > be a temporary situation, but not always. > > > > SPDX (the 3.0 draft) has some other possible reasons > > https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md > > What looks like interesting ideas are: > > * "Can't fix" / "Will not fix" > > * "Not applicable" (SPDX language: Ineffective) when the code is not used > > * "Invalid match" (this is our NVD mismatch case) > > * "Mitigated" measures taken so that it cannot be exploited > > * "Workarounded" > > To me the SPDX details don't seem very usable when actually maintaining > a linux distro for a long time. Anyone from major Linux distro > stable/security teams participating in the work? > > So I'd rather compare to Debian security tracker CVE status data and ask > what our LTS and master branch maintainers and those in the community > who maintain yocto based SW stacks need. Do the maintainers want to read > SPDX output, for example? What common statuses do the maintainers want to > encode for each CVE? > > Debian security tracker https://security-team.debian.org/security_tracker.html > shows states: > > * vulnerable: binary package with specified version in their distro > version is vulnerable to the issue > > * fixed: binary package in their distro version has fixed the issue > > * undetermined: it is not yet clear if the issue affects Debian and > their version of the packages > > And "vulnerable" has sub states: > > * ignored: the issue does not impact Debian packages > > * postponed: no security patch updates will be provided, e.g. such a > minor issue that update will happen for example via normal package > version updates to next stable version > > There are a lot of additional "standards" and sub states when looking at > CVE data in the tracker (info not public, no upstream fix available, not > supported configuration etc), but those major high level states are enough. > And then there are security relevant bugs without CVEs. > > I've been happy with "Unpatched", "Patched" and "Ignored" states for > each CVE detected by cve-check.bbclass. There could be a few more sub > stated to "Ignored" and the "Patched" state should better reflect reality, > which this patch set helps. But I'm happy with that. > > I'm not so happy with the SPDX states names and meanings. > > Cheers, > > -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181629): https://lists.openembedded.org/g/openembedded-core/message/181629 Mute This Topic: https://lists.openembedded.org/mt/99007092/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs
Hello Marta,
On Fri, 2023-05-19 at 15:11 +0200, Marta Rybczynska wrote:
Thank you for this work. I think we are going in a good direction. My comments
in the text.
In general, I would like that we come with the fixed list of possible statuses
and avoid adding new ones too frequently. Changing them will break my parsing
and status scripts each time.
On Fri, May 19, 2023 at 8:24 AM Andrej Valek via
lists.openembedded.org<http://lists.openembedded.org>
mailto:siemens@lists.openembedded.org>>
wrote:
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
more flexible. CVE_STATUS should contain flag for each CVE with accepted
values "Ignored", "Not applicable" or "Patched". It allows to add
a status for each CVEs.
I'm missing a status to cover the situation when the NVD (or any other
database) has an incorrect entry. We have quite many of those. This might be a
temporary situation, but not always.
SPDX (the 3.0 draft) has some other possible reasons
https://github.com/spdx/spdx-spec/blob/vulnerability-profile/chapters/profile-vulnerabilities.md
What looks like interesting ideas are:
* "Can't fix" / "Will not fix"
* "Not applicable" (SPDX language: Ineffective) when the code is not used
* "Invalid match" (this is our NVD mismatch case)
* "Mitigated" measures taken so that it cannot be exploited
* "Workarounded"
I would say, "Ignored", "Not applicable" or "Patched" are enough, because
everything important is covered. Of course we can extend some keywords in the
feature, but we shouldn't confuse users.
There is still one big missing part: related to configuration options. It could
be used with "Not applicable"/"Ineffective" code, but only in cases where it is
not possible to activate the code. If the user can switch between
vulnerable/not vulnerable versions by a packageconfig change or so, this is not
covered.
Addiional question: why CVE_STATUS_REASONING and not CVE_STATUS_REASON ?
(reason variable is used nearly everywhere)
See explanation here:
https://lists.openembedded.org/g/openembedded-core/message/181551 . Once we
have a decision, I can change it.
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445c..44462de7445 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,12 +70,15 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional reason for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
+# CVE_STATUS[CVE-1234-0002] = "Not applicable"
+# CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"
#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
# Layers to be excluded
@@ -88,6 +91,25 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE has been deprecated, use CVE_STATUS instead")
+set_cves_statuses(d, d.getVar("CVE_CHECK_IGNORE"), "Ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional reasons
at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+set_cves_statuses(d, d.getVar(cve_status_group) or "",
+ d.getVarFlag(cve_status_group, "status"),
+ d.getVarFlag(cve_status_group, "reason"))
+}
+
+def set_cves_statuses(d, cves, status, reason=""):
+for cve in cves.split():
+d.setVarFlag("CVE_STATUS", cve, status)
+d.setVarFlag("CVE_STATUS_REASONING", cve, reason)
+
def generate_json_report(d, out_path, link_path):
if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
import json
@@ -282,7 +304,13 @@ def check_cves(d, patched_cves):
bb.note("Recipe has been skipped by cve-check")
return ([], [], [], [])
-cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# Convert CVE
Re: [OE-core][PATCH v4 1/3] cve-check: add option to add additional patched CVEs
Hello Michael, I wanted to use a "CVE_STATUS_REASON", but it was advised here https://lists.openembedded.org/g/openembedded-core/message/181037 by Richard. So I was thinking, that it has to correct. Regards, Andrej On Fri, 2023-05-19 at 15:09 +0200, Michael Opdenacker wrote: > Hi Andrej, > > On 19.05.23 at 10:18, Andrej Valek via lists.openembedded.org wrote: > > - Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be > > more flexible. CVE_STATUS should contain flag for each CVE with accepted > > values "Ignored", "Not applicable" or "Patched". It allows to add > > a status for each CVEs. > > - Optional CVE_STATUS_REASONING flag variable may contain a reason > > why the CVE status was used. It will be added in csv/json report like > > a new "reason" entry. > > > I'm not a native English speaker, but what about just > "CVE_STATUS_REASON" instead of "CVE_STATUS_REASONING"? > > "Reasoning" is a mental process if I understand correctly. See > https://www.englishforums.com/English/ReasonVsReasoning/zdgdw/post.htm. > It seems to me that the term "reason" should be sufficient, as the > "reason" flag that you're using. > > I'd be interested in what others think about this... > Thanks in advance > Cheers > > Michael. > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181551): https://lists.openembedded.org/g/openembedded-core/message/181551 Mute This Topic: https://lists.openembedded.org/mt/99008417/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v4 3/3] cve_check: convert CVE_CHECK_IGNORE to CVE_STATUS and CVE_STATUS_REASONING
- Try to add convert and apply statuses for old CVEs - Drop some obsolete ignores, while they are not relevant for current version Signed-off-by: Andrej Valek Reviewed-by: Peter Marko --- .../distro/include/cve-extra-exclusions.inc | 281 +++--- meta/recipes-bsp/grub/grub2.inc | 9 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 4 +- .../recipes-connectivity/bind/bind_9.18.13.bb | 3 +- .../bluez5/bluez5_5.66.bb | 6 +- .../openssh/openssh_9.3p1.bb | 12 +- .../openssl/openssl_3.1.0.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.1.bb | 3 +- meta/recipes-core/glibc/glibc_2.37.bb | 12 +- meta/recipes-core/libxml/libxml2_2.10.4.bb| 3 +- meta/recipes-core/systemd/systemd_253.3.bb| 4 +- meta/recipes-devtools/cmake/cmake.inc | 5 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 3 +- meta/recipes-devtools/gcc/gcc-12.2.inc| 3 - meta/recipes-devtools/git/git_2.39.2.bb | 12 +- meta/recipes-devtools/jquery/jquery_3.6.3.bb | 6 +- .../recipes-devtools/python/python3_3.11.2.bb | 18 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 +- meta/recipes-extended/cpio/cpio_2.13.bb | 4 +- meta/recipes-extended/cups/cups.inc | 24 +- .../ghostscript/ghostscript_10.0.0.bb | 3 +- .../iputils/iputils_20221126.bb | 7 +- .../libtirpc/libtirpc_1.3.3.bb| 4 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 +- meta/recipes-extended/shadow/shadow_4.13.bb | 8 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 3 +- meta/recipes-extended/zip/zip_3.0.bb | 8 +- .../libnotify/libnotify_0.8.2.bb | 4 +- meta/recipes-gnome/librsvg/librsvg_2.54.5.bb | 4 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 13 +- .../linux/cve-exclusion_6.1.inc | 14 +- .../libpng/libpng_1.6.39.bb | 4 +- meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 10 +- .../libgcrypt/libgcrypt_1.10.1.bb | 6 +- .../recipes-support/libxslt/libxslt_1.1.37.bb | 5 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 4 +- meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 13 +- 41 files changed, 325 insertions(+), 230 deletions(-) diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc index 0ca75bae3ef..1cb32db814d 100644 --- a/meta/conf/distro/include/cve-extra-exclusions.inc +++ b/meta/conf/distro/include/cve-extra-exclusions.inc @@ -19,7 +19,8 @@ # strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006 # CVE is more than 20 years old with no resolution evident # broken links in CVE database references make resolution impractical -CVE_CHECK_IGNORE += "CVE-2000-0006" +CVE_STATUS[CVE-2000-0006] = "Ignored" +CVE_STATUS_REASONING[CVE-2000-0006] = "CVE is more than 20 years old with no resolution evident." # epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238 # The issue here is spoofing of domain names using characters from other character sets. @@ -28,31 +29,39 @@ CVE_CHECK_IGNORE += "CVE-2000-0006" # there is unlikely ever to be a single fix to webkit or epiphany which addresses this # problem. Ignore this CVE as there isn't any mitigation or fix or way to progress this further # we can seem to take. -CVE_CHECK_IGNORE += "CVE-2005-0238" +CVE_STATUS[CVE-2005-0238] = "Ignored" +CVE_STATUS_REASONING[CVE-2005-0238] = "There isn't any mitigation or fix or way to progress this further." # glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756 # Issue is memory exhaustion via glob() calls, e.g. from within an ftp server # Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681 # Upstream don't see it as a security issue, ftp servers shouldn't be passing # this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT or similar -CVE_CHECK_IGNORE += "CVE-2010-4756" +CVE_STATUS[CVE-2010-4756] = "Ignored" +CVE_STATUS_REASONING[CVE-2010-4756] = "Upstream have no plans to add BSD's GLOB_LIMIT or similar." # go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509 # go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511 # The encoding/xml package in go can potentially be used for security exploits if not used correctly # CVE applies to a netapp product as well as flagging a general issue. We don't ship anything # exposing this interface in an exploitable way -CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511" +CVE_STATUS[CVE-20
[OE-core][PATCH v4 2/3] oeqa/selftest/cve_check: add check for optional "reason" value
- After introducing the CVE_STATUS_REASONING flag variable, CVEs could
contain a reason for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 20 ++-
.../logrotate/logrotate_3.21.0.bb | 6 --
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c8..ea37beba031 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,28 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"reason" : issue["reason"] if "reason" in issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["reason"]), 0)
+reason = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["reason"], reason)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["reason"], reason)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["reason"], reason)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60f..633987ceed6 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,10 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "Ignored"
+CVE_STATUS_RECIPE[reason] = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181538):
https://lists.openembedded.org/g/openembedded-core/message/181538
Mute This Topic: https://lists.openembedded.org/mt/99008419/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v4 1/3] cve-check: add option to add additional patched CVEs
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
more flexible. CVE_STATUS should contain flag for each CVE with accepted
values "Ignored", "Not applicable" or "Patched". It allows to add
a status for each CVEs.
- Optional CVE_STATUS_REASONING flag variable may contain a reason
why the CVE status was used. It will be added in csv/json report like
a new "reason" entry.
- Settings the same status and reason for multiple CVEs is possible
via CVE_STATUS_GROUPS variable.
- All listed CVEs in CVE_CHECK_IGNORE are copied to CVE_STATUS with
value "Ignored" like a fallback.
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
CVE_STATUS[CVE-1234-0002] = "Not applicable"
CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"
CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0002"
CVE_STATUS_WIN[status] = "Not applicable"
CVE_STATUS_WIN[reason] = "Issue only applies on Windows"
CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-1234-0004"
CVE_STATUS_PATCHED[status] = "Patched"
CVE_STATUS_PATCHED[reason] = "Fixed externally"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 44 ++
meta/lib/oe/cve_check.py | 6 +
2 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445c..44462de7445 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,12 +70,15 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional reason for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
+# CVE_STATUS[CVE-1234-0002] = "Not applicable"
+# CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"
#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
# Layers to be excluded
@@ -88,6 +91,25 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE has been deprecated, use CVE_STATUS instead")
+set_cves_statuses(d, d.getVar("CVE_CHECK_IGNORE"), "Ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional reasons
at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+set_cves_statuses(d, d.getVar(cve_status_group) or "",
+ d.getVarFlag(cve_status_group, "status"),
+ d.getVarFlag(cve_status_group, "reason"))
+}
+
+def set_cves_statuses(d, cves, status, reason=""):
+for cve in cves.split():
+d.setVarFlag("CVE_STATUS", cve, status)
+d.setVarFlag("CVE_STATUS_REASONING", cve, reason)
+
def generate_json_report(d, out_path, link_path):
if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
import json
@@ -282,7 +304,13 @@ def check_cves(d, patched_cves):
bb.note("Recipe has been skipped by cve-check")
return ([], [], [], [])
-cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# Convert CVE_STATUS into ignored CVEs and check validity
+cve_ignore = []
+for cve, status in (d.getVarFlags("CVE_STATUS") or {}).items():
+if status in ["Not applicable", "Ignored"]:
+cve_ignore.append(cve)
+elif status not in ["Patched"]:
+bb.error("Unsupported status %s in CVE_STATUS[%s]" % (status, cve))
import sqlite3
db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
@@ -455,6 +483,9 @@ def cve_write_data_text(d, patched, unpatched, ignored,
cve_data):
else:
unpatched_cves.append(cve)
write_string += "CVE STATUS: Unpatched\n"
+reasoning = d.getVarFlag("
[OE-core][PATCH v3 3/3] cve_check: convert CVE_CHECK_IGNORE to CVE_STATUS and CVE_STATUS_REASONING
- Try to add convert and apply statuses for old CVEs Signed-off-by: Andrej Valek Reviewed-by: Peter Marko --- .../distro/include/cve-extra-exclusions.inc | 281 +++--- meta/recipes-bsp/grub/grub2.inc | 9 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 4 +- .../recipes-connectivity/bind/bind_9.18.13.bb | 3 +- .../bluez5/bluez5_5.66.bb | 6 +- .../openssh/openssh_9.3p1.bb | 12 +- .../openssl/openssl_3.1.0.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.1.bb | 3 +- meta/recipes-core/glibc/glibc_2.37.bb | 12 +- meta/recipes-core/libxml/libxml2_2.10.4.bb| 3 +- meta/recipes-core/systemd/systemd_253.3.bb| 4 +- meta/recipes-devtools/cmake/cmake.inc | 5 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 3 +- meta/recipes-devtools/gcc/gcc-12.2.inc| 3 - meta/recipes-devtools/git/git_2.39.2.bb | 12 +- meta/recipes-devtools/jquery/jquery_3.6.3.bb | 6 +- .../recipes-devtools/python/python3_3.11.2.bb | 18 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 +- meta/recipes-extended/cpio/cpio_2.13.bb | 4 +- meta/recipes-extended/cups/cups.inc | 24 +- .../ghostscript/ghostscript_10.0.0.bb | 3 +- .../iputils/iputils_20221126.bb | 7 +- .../libtirpc/libtirpc_1.3.3.bb| 4 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 +- meta/recipes-extended/shadow/shadow_4.13.bb | 8 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 3 +- meta/recipes-extended/zip/zip_3.0.bb | 8 +- .../libnotify/libnotify_0.8.2.bb | 4 +- meta/recipes-gnome/librsvg/librsvg_2.54.5.bb | 4 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 13 +- .../linux/cve-exclusion_6.1.inc | 14 +- .../libpng/libpng_1.6.39.bb | 4 +- meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 10 +- .../libgcrypt/libgcrypt_1.10.1.bb | 6 +- .../recipes-support/libxslt/libxslt_1.1.37.bb | 5 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 4 +- meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 13 +- 41 files changed, 325 insertions(+), 230 deletions(-) diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc index 0ca75bae3ef..1cb32db814d 100644 --- a/meta/conf/distro/include/cve-extra-exclusions.inc +++ b/meta/conf/distro/include/cve-extra-exclusions.inc @@ -19,7 +19,8 @@ # strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006 # CVE is more than 20 years old with no resolution evident # broken links in CVE database references make resolution impractical -CVE_CHECK_IGNORE += "CVE-2000-0006" +CVE_STATUS[CVE-2000-0006] = "Ignored" +CVE_STATUS_REASONING[CVE-2000-0006] = "CVE is more than 20 years old with no resolution evident." # epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238 # The issue here is spoofing of domain names using characters from other character sets. @@ -28,31 +29,39 @@ CVE_CHECK_IGNORE += "CVE-2000-0006" # there is unlikely ever to be a single fix to webkit or epiphany which addresses this # problem. Ignore this CVE as there isn't any mitigation or fix or way to progress this further # we can seem to take. -CVE_CHECK_IGNORE += "CVE-2005-0238" +CVE_STATUS[CVE-2005-0238] = "Ignored" +CVE_STATUS_REASONING[CVE-2005-0238] = "There isn't any mitigation or fix or way to progress this further." # glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756 # Issue is memory exhaustion via glob() calls, e.g. from within an ftp server # Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681 # Upstream don't see it as a security issue, ftp servers shouldn't be passing # this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT or similar -CVE_CHECK_IGNORE += "CVE-2010-4756" +CVE_STATUS[CVE-2010-4756] = "Ignored" +CVE_STATUS_REASONING[CVE-2010-4756] = "Upstream have no plans to add BSD's GLOB_LIMIT or similar." # go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509 # go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511 # The encoding/xml package in go can potentially be used for security exploits if not used correctly # CVE applies to a netapp product as well as flagging a general issue. We don't ship anything # exposing this interface in an exploitable way -CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511" +CVE_STATUS[CVE-2020-29509] = "Ignored" +CVE_STATUS_REASONING[CVE-2020-29509] = "We don't shi
[OE-core][PATCH v3 2/3] oeqa/selftest/cve_check: add check for optional "reason" value
- After introducing the CVE_STATUS_REASONING flag variable, CVEs could
contain a reason for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 20 ++-
.../logrotate/logrotate_3.21.0.bb | 6 --
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c8..ea37beba031 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,28 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"reason" : issue["reason"] if "reason" in issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["reason"]), 0)
+reason = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["reason"], reason)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["reason"], reason)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["reason"], reason)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60f..633987ceed6 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,10 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "Ignored"
+CVE_STATUS_RECIPE[reason] = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181532):
https://lists.openembedded.org/g/openembedded-core/message/181532
Mute This Topic: https://lists.openembedded.org/mt/99007095/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v3 1/3] cve-check: add option to add additional patched CVEs
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
more flexible. CVE_STATUS should contain flag for each CVE with accepted
values "Ignored", "Not applicable" or "Patched". It allows to add
a status for each CVEs.
- Optional CVE_STATUS_REASONING flag variable may contain a reason
why the CVE status was used. It will be added in csv/json report like
a new "reason" entry.
- Settings the same status and reason for multiple CVEs is possible
via CVE_STATUS_GROUPS variable.
- All listed CVEs in CVE_CHECK_IGNORE are copied to CVE_STATUS with
value "Ignored" like a fallback.
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "Ignored" # or "Not applicable" or "Patched"
CVE_STATUS[CVE-1234-0002] = "Not applicable"
CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on Windows"
CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0002"
CVE_STATUS_WIN[status] = "Not applicable"
CVE_STATUS_WIN[reason] = "Issue only applies on Windows"
CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-1234-0004"
CVE_STATUS_PATCHED[status] = "Patched"
CVE_STATUS_PATCHED[reason] = "Fixed externally"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
documentation/dev-manual/new-recipe.rst | 4 +-
documentation/dev-manual/vulnerabilities.rst | 11 ++---
documentation/ref-manual/classes.rst | 9 ++--
documentation/ref-manual/variables.rst | 33 ---
meta/classes/cve-check.bbclass | 44 +---
meta/lib/oe/cve_check.py | 6 +++
6 files changed, 87 insertions(+), 20 deletions(-)
diff --git a/documentation/dev-manual/new-recipe.rst
b/documentation/dev-manual/new-recipe.rst
index 4e74246a4e9..008f4b1ceb7 100644
--- a/documentation/dev-manual/new-recipe.rst
+++ b/documentation/dev-manual/new-recipe.rst
@@ -1253,8 +1253,8 @@ In the following example, ``lz4`` is a makefile-based
package::
S = "${WORKDIR}/git"
- # Fixed in r118, which is larger than the current version.
- CVE_CHECK_IGNORE += "CVE-2014-4715"
+ CVE_STATUS[CVE-2014-4715] = "Patched"
+ CVE_STATUS_REASONING[CVE-2014-4715] = "Fixed in r118, which is larger than
the current version"
EXTRA_OEMAKE = "PREFIX=${prefix} CC='${CC}' CFLAGS='${CFLAGS}' DESTDIR=${D}
LIBDIR=${libdir} INCLUDEDIR=${includedir} BUILD_STATIC=no"
diff --git a/documentation/dev-manual/vulnerabilities.rst
b/documentation/dev-manual/vulnerabilities.rst
index 0ee3ec52c5c..ca1ea87ba7e 100644
--- a/documentation/dev-manual/vulnerabilities.rst
+++ b/documentation/dev-manual/vulnerabilities.rst
@@ -158,7 +158,8 @@ CVE checker will then capture this information and change
the CVE status to ``Pa
in the generated reports.
If analysis shows that the CVE issue does not impact the recipe due to
configuration, platform,
-version or other reasons, the CVE can be marked as ``Ignored`` using the
:term:`CVE_CHECK_IGNORE` variable.
+version or other reasons, the CVE can be marked as ``Ignored`` or ``Not
applicable`` using
+the :term:`CVE_STATUS[]` variable flag.
As mentioned previously, if data in the CVE database is wrong, it is recommend
to fix those
issues in the CVE database directly.
@@ -182,11 +183,11 @@ products defined in :term:`CVE_PRODUCT`. Then, for each
found CVE:
- If the package name (:term:`PN`) is part of
:term:`CVE_CHECK_SKIP_RECIPE`, it is considered as ``Patched``.
-- If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
- set as ``Ignored``.
+- If the CVE ID has status :term:`CVE_STATUS[] = "Ignored"`, it is
+ set as ``Ignored`` as same as for :term:`CVE_STATUS[] = "Not
applicable"`.
-- If the CVE ID is part of the patched CVE for the recipe, it is
- already considered as ``Patched``.
+- If the CVE ID is part of the patched CVE for the recipe or has status
+ :term:`CVE_STATUS[] = "Patched"`, it is considered as ``Patched``.
- Otherwise, the code checks whether the recipe version (:term:`PV`)
is within the range of versions impacted by the CVE. If so, the CVE
diff --git a/documentation/ref-manual/classes.rst
b/documentation/ref-manual/classes.rst
index ab1628401e9..2811244b8f7 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -517,10 +517,13 @@ The ``Patched`` state of a CVE issue is detected from
patch files with the forma
``CVE-ID.patch``, e.g. ``CVE-2019-20633.patch``, in the :term:`SRC_URI` and
using
CVE metadata of format ``CVE: CVE-ID`` in the commit message of the patch file.
-If the recipe lists the ``CVE-ID`` in :term:`CVE_CHECK_IGNORE` variable, then
the CVE state is reported
-as ``Ignored``. Multiple CVEs can be listed separated by spaces. Example::
+If the recipe adds the ``CVE-ID`
[OE-core][PATCH v2] cve-check: add option to add additional patched CVEs
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
more flexible. CVE_STATUS should contains flag for each CVE with accepted
values "Ignored" or "Not applicable". It allows to add a status for CVEs
which could be fixed externally.
- Optional CVE_STATUS_REASONING flag variable could contains a reason
why the CVE status was used. It will be added in csv/json report like
a new "reason" entry.
- All listed CVEs in CVE_CHECK_IGNORE are copied to CVE_STATUS with
value "Ignored" like a fallback.
Example of usage:
CVE_STATUS[CVE-1234-0001] = "Not applicable" or "Ignored"
CVE_STATUS[CVE-1234-0002] = "Not applicable"
CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on windows"
Signed-off-by: Andrej Valek
---
meta/classes/cve-check.bbclass | 30 +-
meta/lib/oe/cve_check.py | 6 ++
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445c..e081095037c 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,13 +70,17 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Ignore the check for a given CVE. Each of CVE has to be mentioned
+# separately with optional reason, why it has to ignored.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "Not applicable" or "Ignored"
+# CVE_STATUS[CVE-1234-0002] = "Ignored"
+# CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on windows"
#
+# CVE_CHECK_IGNORE is depracated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE like a fallback.
CVE_CHECK_IGNORE ?= ""
+CVE_STATUS ?= ""
# Layers to be excluded
CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -88,6 +92,12 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+for cve in d.getVar("CVE_CHECK_IGNORE").split():
+d.setVarFlags("CVE_STATUS", {cve: "Ignored"})
+}
+
def generate_json_report(d, out_path, link_path):
if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
import json
@@ -282,7 +292,11 @@ def check_cves(d, patched_cves):
bb.note("Recipe has been skipped by cve-check")
return ([], [], [], [])
-cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# Convert CVE_STATUS into ignored CVEs
+cve_ignore = []
+for cve, status in (d.getVarFlags("CVE_STATUS") or {}).items():
+if status in ["Not applicable", "Ignored"]:
+cve_ignore.append(cve)
import sqlite3
db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
@@ -455,6 +469,9 @@ def cve_write_data_text(d, patched, unpatched, ignored,
cve_data):
else:
unpatched_cves.append(cve)
write_string += "CVE STATUS: Unpatched\n"
+has_reason = d.getVarFlag("CVE_STATUS_REASONING", cve)
+if has_reason:
+write_string += "CVE REASON: %s\n" % has_reason
write_string += "CVE SUMMARY: %s\n" % cve_data[cve]["summary"]
write_string += "CVSS v2 BASE SCORE: %s\n" % cve_data[cve]["scorev2"]
write_string += "CVSS v3 BASE SCORE: %s\n" % cve_data[cve]["scorev3"]
@@ -576,6 +593,9 @@ def cve_write_data_json(d, patched, unpatched, ignored,
cve_data, cve_status):
"status" : status,
"link": issue_link
}
+has_reason = d.getVarFlag("CVE_STATUS_REASONING", cve)
+if has_reason:
+cve_item["reason"] = has_reason
cve_list.append(cve_item)
package_data["issue"] = cve_list
diff --git a/meta/lib/oe/cve_check.py b/meta/lib/oe/cve_check.py
index dbaa0b373a3..f47dd9920ef 100644
--- a/meta/lib/oe/cve_check.py
+++ b/meta/lib/oe/cve_check.py
@@ -130,6 +130,12 @@ def get_patched_cves(d):
if not fname_match and not text_match:
bb.debug(2, "Patch %s doesn't solve CVEs" % patch_file)
+# Search for additional patched CVEs
+for cve, status in (d.getVarFlags("CVE_STATUS") or {}).items():
+if status == "Patched":
+bb.debug(2, "CVE %s is additionally patched" % cve)
+patched_cves.add(cve)
+
return patched_cves
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181444):
https://lists.openembedded.org/g/openembedded-core/message/181444
Mute This Topic: https://lists.openembedded.org/mt/98943046/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] cve-check: add option to add additional patched CVEs
On Fri, 2023-05-05 at 12:30 +0100, Richard Purdie wrote: > On Fri, 2023-05-05 at 13:18 +0200, Andrej Valek via > lists.openembedded.org wrote: > > CVE_CHECK_PATCHED - should contains an additional CVEs which have > > been > > fixed and shouldn't be mark as vulnerable nor ignored. > > > > Signed-off-by: Andrej Valek > > --- > > meta/classes/cve-check.bbclass | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve- > > check.bbclass > > index bd9e7e7445c..957ea0130dc 100644 > > --- a/meta/classes/cve-check.bbclass > > +++ b/meta/classes/cve-check.bbclass > > @@ -78,6 +78,11 @@ CVE_CHECK_SKIP_RECIPE ?= "" > > # > > CVE_CHECK_IGNORE ?= "" > > > > +# Usually a CVE gets treated as patched when a patch with the name > > of the CVE > > +# gets applied. Basically this variable should not be used. But if > > there are > > +# other reasons to mark a CVE as patched it can be added to this > > list. > > +CVE_CHECK_PATCHED ?= "" > > We're not adding variables which are documented as "Basically this > variable should not be used.". If you shouldn't need/use it, we don't > need it. Ok, maybe I should change the description a little bit. Do you have some other preference? > > Can't you just use the ignore variable for the same end result? Nope. If I use a ignore list, the output in the SBOM will be set to "ignored", which is wrong, because it has been fixed. And that's the reason. > > Cheers, > > Richard > Regards, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180913): https://lists.openembedded.org/g/openembedded-core/message/180913 Mute This Topic: https://lists.openembedded.org/mt/98703185/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] cve-check: add option to add additional patched CVEs
CVE_CHECK_PATCHED - should contains an additional CVEs which have been
fixed and shouldn't be mark as vulnerable nor ignored.
Signed-off-by: Andrej Valek
---
meta/classes/cve-check.bbclass | 8
1 file changed, 8 insertions(+)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445c..957ea0130dc 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -78,6 +78,11 @@ CVE_CHECK_SKIP_RECIPE ?= ""
#
CVE_CHECK_IGNORE ?= ""
+# Usually a CVE gets treated as patched when a patch with the name of the CVE
+# gets applied. Basically this variable should not be used. But if there are
+# other reasons to mark a CVE as patched it can be added to this list.
+CVE_CHECK_PATCHED ?= ""
+
# Layers to be excluded
CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -284,6 +289,9 @@ def check_cves(d, patched_cves):
cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# add additional patched CVEs into existing patched list
+patched_cves.update(d.getVar("CVE_CHECK_PATCHED").split())
+
import sqlite3
db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
conn = sqlite3.connect(db_file, uri=True)
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180911):
https://lists.openembedded.org/g/openembedded-core/message/180911
Mute This Topic: https://lists.openembedded.org/mt/98703185/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell][PATCH 2/2] curl: whitelists CVE-2022-42915, CVE-2022-42916 and CVE-2022-43551
Hello Steve,
Ok, looks like I received a wrong notification, sorry. So you can keep
there only the 42916.
Basically all the HSTS check features are not implemented in the 7.69.1
version.
Regards,
Andrej
On Tue, 2023-03-14 at 04:39 -1000, Steve Sakoman wrote:
> On Tue, Mar 14, 2023 at 4:26 AM Steve Sakoman via
> lists.openembedded.org
> wrote:
> >
> > On Thu, Mar 9, 2023 at 11:54 PM Andrej Valek
> > wrote:
> > >
> > > All mentioned CVEs are related to HSTS check feature, which is
> > > not
> > > implemented in version 7.69.1 .
> >
> > Is this due to an error in the CPE database? If so, perhaps the
> > better approach would be to send a version correction request to
> > cpe_diction...@nist.gov
>
> Hmmm . . . looking at the most recent dunfell CVE report I see that
> only CVE-2022-42916 is listed.
>
> The CPE database indicates the issue is present for versions 7.57.0
> onwards up to but not including 7.88.0
>
> Steve
>
>
> > > Signed-off-by: Andrej Valek
> > > ---
> > > meta/recipes-support/curl/curl_7.69.1.bb | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
> > > b/meta/recipes-support/curl/curl_7.69.1.bb
> > > index 899daf8eac..ea36c0bd3d 100644
> > > --- a/meta/recipes-support/curl/curl_7.69.1.bb
> > > +++ b/meta/recipes-support/curl/curl_7.69.1.bb
> > > @@ -56,6 +56,9 @@ CVE_CHECK_WHITELIST = "CVE-2021-22922 CVE-2021-
> > > 22923 CVE-2021-22926 CVE-2021-229
> > > # This CVE issue affects Windows only Hence whitelisting this
> > > CVE
> > > CVE_CHECK_WHITELIST += "CVE-2021-22897"
> > >
> > > +# HSTS check feature is not implemented
> > > +CVE_CHECK_WHITELIST += "CVE-2022-42915 CVE-2022-42916 CVE-2022-
> > > 43551"
> > > +
> > > inherit autotools pkgconfig binconfig multilib_header
> > >
> > > PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6',
> > > d)} gnutls libidn proxy threaded-resolver verbose zlib"
> > > --
> > > 2.39.2
> > >
> > >
> > >
> > >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178498):
https://lists.openembedded.org/g/openembedded-core/message/178498
Mute This Topic: https://lists.openembedded.org/mt/97516349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell][PATCH] libarchive: fix CVE-2022-26280
Backport fix from https://github.com/libarchive/libarchive/issues/1672
Signed-off-by: Andrej Valek
---
.../libarchive/CVE-2022-26280.patch | 29 +++
.../libarchive/libarchive_3.4.2.bb| 1 +
2 files changed, 30 insertions(+)
create mode 100644
meta/recipes-extended/libarchive/libarchive/CVE-2022-26280.patch
diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2022-26280.patch
b/meta/recipes-extended/libarchive/libarchive/CVE-2022-26280.patch
new file mode 100644
index 00..501fcc5848
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2022-26280.patch
@@ -0,0 +1,29 @@
+From cfaa28168a07ea4a53276b63068f94fce37d6aff Mon Sep 17 00:00:00 2001
+From: Tim Kientzle
+Date: Thu, 24 Mar 2022 10:35:00 +0100
+Subject: [PATCH] ZIP reader: fix possible out-of-bounds read in
+ zipx_lzma_alone_init()
+
+Fixes #1672
+
+CVE: CVE-2022-26280
+Upstream-Status: Backport
[https://github.com/libarchive/libarchive/commit/cfaa28168a07ea4a53276b63068f94fce37d6aff]
+Signed-off-by: Andrej Valek
+
+---
+ libarchive/archive_read_support_format_zip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libarchive/archive_read_support_format_zip.c
b/libarchive/archive_read_support_format_zip.c
+index 38ada70b5..9d6c900b2 100644
+--- a/libarchive/archive_read_support_format_zip.c
b/libarchive/archive_read_support_format_zip.c
+@@ -1667,7 +1667,7 @@ zipx_lzma_alone_init(struct archive_read *a, struct zip
*zip)
+*/
+
+ /* Read magic1,magic2,lzma_params from the ZIPX stream. */
+- if((p = __archive_read_ahead(a, 9, NULL)) == NULL) {
++ if(zip->entry_bytes_remaining < 9 || (p = __archive_read_ahead(a, 9,
NULL)) == NULL) {
+ archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
+ "Truncated lzma data");
+ return (ARCHIVE_FATAL);
diff --git a/meta/recipes-extended/libarchive/libarchive_3.4.2.bb
b/meta/recipes-extended/libarchive/libarchive_3.4.2.bb
index e0a6174d8b..582787d3f3 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.4.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.4.2.bb
@@ -39,6 +39,7 @@ SRC_URI =
"http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
file://CVE-2021-23177.patch \
file://CVE-2021-31566-01.patch \
file://CVE-2021-31566-02.patch \
+ file://CVE-2022-26280.patch \
file://CVE-2022-36227.patch \
"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178477):
https://lists.openembedded.org/g/openembedded-core/message/178477
Mute This Topic: https://lists.openembedded.org/mt/9759/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell][PATCH] curl: Fix CVE CVE-2021-22897
Hello Steve,
- patch
- I'm fine with explanation
- Cert error
- for example here:
https://autobuilder.yocto.io/pub/non-release/patchmetrics/cve-status-dunfell.txt
Regards,
Andrej
On Fri, 2023-03-10 at 04:40 -1000, Steve Sakoman wrote:
> On Fri, Mar 10, 2023 at 3:09 AM Valek, Andrej
> wrote:
> >
> > Hello again,
> >
> > Looks like that this patch showed some isses/open points:
> > - CVE-2021-22897 is white-listed already, but in hardknott is fixed
> > already
> > https://github.com/openembedded/openembedded-core/blob/hardknott/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> > - So do we have to ignore the patch, or apply and remove the
> > whitelist, or remove patch from hardknott?
>
> Hardknott is no longer being maintained, so nothing needs to be done
> there.
>
> Since this is a Windows only bug ("It can only trigger when Schannel
> is used, which is the native TLS library in Microsoft Windows") I
> think the existing whitelist is fine and we don't need this
> additional
> patch.
>
> > - Https certificate at yocto.io has been expired ;)
>
> Can you give me the url which is giving the expired certificate
> error?
>
> Thanks!
>
> Steve
>
> > Regards,
> > Andrej
> >
> > On Fri, 2023-03-10 at 13:45 +0100, Andrej Valek wrote:
> > > https://curl.se/docs/CVE-2021-22897.html
> > >
> > > Signed-off-by: Andrej Valek
> > > ---
> > > .../curl/curl/CVE-2021-22897.patch | 73
> > > +++
> > > meta/recipes-support/curl/curl_7.69.1.bb | 1 +
> > > 2 files changed, 74 insertions(+)
> > > create mode 100644 meta/recipes-support/curl/curl/CVE-2021-
> > > 22897.patch
> > >
> > > diff --git a/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> > > b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> > > new file mode 100644
> > > index 00..cbd6c067ce
> > > --- /dev/null
> > > +++ b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> > > @@ -0,0 +1,73 @@
> > > +From bbb71507b7bab52002f9b1e0880bed6a32834511 Mon Sep 17
> > > 00:00:00
> > > 2001
> > > +From: Daniel Stenberg
> > > +Date: Fri, 23 Apr 2021 10:54:10 +0200
> > > +Subject: [PATCH] schannel: don't use static to store selected
> > > ciphers
> > > +
> > > +CVE-2021-22897
> > > +
> > > +Bug: https://curl.se/docs/CVE-2021-22897.html
> > > +
> > > +Upstream-Status: Backport
> > > +[
> > > https://github.com/curl/curl/commit/bbb71507b7bab52002f9b1e0880bed6a3
> > > 2834511]
> > > +
> > > +CVE: CVE-2021-22897
> > > +
> > > +Signed-off-by: Daniel Stenberg
> > > +Signed-off-by: Khairul Rohaizzat Jamaluddin
> > >
> > > +Signed-off-by: Andrej Valek
> > > +---
> > > + lib/vtls/schannel.c | 9 +
> > > + lib/vtls/schannel.h | 3 +++
> > > + 2 files changed, 8 insertions(+), 4 deletions(-)
> > > +
> > > +diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
> > > +index 8c25ac5dd5a5..dba7072273a9 100644
> > > +--- a/lib/vtls/schannel.c
> > > b/lib/vtls/schannel.c
> > > +@@ -322,12 +322,12 @@ get_alg_id_by_name(char *name)
> > > + }
> > > +
> > > + static CURLcode
> > > +-set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers)
> > > ++set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers,
> > > ++ int *algIds)
> > > + {
> > > + char *startCur = ciphers;
> > > + int algCount = 0;
> > > +- static ALG_ID algIds[45]; /*There are 45 listed in the MS
> > > headers*/
> > > +- while(startCur && (0 != *startCur) && (algCount < 45)) {
> > > ++ while(startCur && (0 != *startCur) && (algCount <
> > > NUMOF_CIPHERS))
> > > {
> > > + long alg = strtol(startCur, 0, 0);
> > > + if(!alg)
> > > + alg = get_alg_id_by_name(startCur);
> > > +@@ -566,7 +566,8 @@ schannel_connect_step1(struct connectdat
> > > + }
> > > +
> > > + if(SSL_CONN_CONFIG(cipher_list)) {
> > > +- result = set_ssl_ciphers(_cred,
> > > SSL_CONN_CONFIG(cipher_list));
> > > ++ result = set_ssl_ciphers(_cred,
> > > SSL_CONN_CONFIG(cipher_list),
> > > ++ BACKEND->algIds);
> > > + if(CURLE_OK != result) {
> > > + failf(data, "Unable
Re: [OE-core][dunfell][PATCH] curl: Fix CVE CVE-2021-22897
Hello again,
Looks like that this patch showed some isses/open points:
- CVE-2021-22897 is white-listed already, but in hardknott is fixed
already
https://github.com/openembedded/openembedded-core/blob/hardknott/meta/recipes-support/curl/curl/CVE-2021-22897.patch
- So do we have to ignore the patch, or apply and remove the
whitelist, or remove patch from hardknott?
- Https certificate at yocto.io has been expired ;)
Regards,
Andrej
On Fri, 2023-03-10 at 13:45 +0100, Andrej Valek wrote:
> https://curl.se/docs/CVE-2021-22897.html
>
> Signed-off-by: Andrej Valek
> ---
> .../curl/curl/CVE-2021-22897.patch | 73
> +++
> meta/recipes-support/curl/curl_7.69.1.bb | 1 +
> 2 files changed, 74 insertions(+)
> create mode 100644 meta/recipes-support/curl/curl/CVE-2021-
> 22897.patch
>
> diff --git a/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> new file mode 100644
> index 00..cbd6c067ce
> --- /dev/null
> +++ b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
> @@ -0,0 +1,73 @@
> +From bbb71507b7bab52002f9b1e0880bed6a32834511 Mon Sep 17 00:00:00
> 2001
> +From: Daniel Stenberg
> +Date: Fri, 23 Apr 2021 10:54:10 +0200
> +Subject: [PATCH] schannel: don't use static to store selected
> ciphers
> +
> +CVE-2021-22897
> +
> +Bug: https://curl.se/docs/CVE-2021-22897.html
> +
> +Upstream-Status: Backport
> +[
> https://github.com/curl/curl/commit/bbb71507b7bab52002f9b1e0880bed6a3
> 2834511]
> +
> +CVE: CVE-2021-22897
> +
> +Signed-off-by: Daniel Stenberg
> +Signed-off-by: Khairul Rohaizzat Jamaluddin
>
> +Signed-off-by: Andrej Valek
> +---
> + lib/vtls/schannel.c | 9 +
> + lib/vtls/schannel.h | 3 +++
> + 2 files changed, 8 insertions(+), 4 deletions(-)
> +
> +diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
> +index 8c25ac5dd5a5..dba7072273a9 100644
> +--- a/lib/vtls/schannel.c
> b/lib/vtls/schannel.c
> +@@ -322,12 +322,12 @@ get_alg_id_by_name(char *name)
> + }
> +
> + static CURLcode
> +-set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers)
> ++set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers,
> ++ int *algIds)
> + {
> + char *startCur = ciphers;
> + int algCount = 0;
> +- static ALG_ID algIds[45]; /*There are 45 listed in the MS
> headers*/
> +- while(startCur && (0 != *startCur) && (algCount < 45)) {
> ++ while(startCur && (0 != *startCur) && (algCount < NUMOF_CIPHERS))
> {
> + long alg = strtol(startCur, 0, 0);
> + if(!alg)
> + alg = get_alg_id_by_name(startCur);
> +@@ -566,7 +566,8 @@ schannel_connect_step1(struct connectdat
> + }
> +
> + if(SSL_CONN_CONFIG(cipher_list)) {
> +- result = set_ssl_ciphers(_cred,
> SSL_CONN_CONFIG(cipher_list));
> ++ result = set_ssl_ciphers(_cred,
> SSL_CONN_CONFIG(cipher_list),
> ++ BACKEND->algIds);
> + if(CURLE_OK != result) {
> + failf(data, "Unable to set ciphers to passed via
> SSL_CONN_CONFIG");
> + return result;
> +diff --git a/lib/vtls/schannel.h b/lib/vtls/schannel.h
> +index 2952caa1a5a1..77853aa30f96 100644
> +--- a/lib/vtls/schannel.h
> b/lib/vtls/schannel.h
> +@@ -70,6 +70,8 @@ CURLcode Curl_verify_certificate(struct
> + #endif
> + #endif
> +
> ++#define NUMOF_CIPHERS 45 /* There are 45 listed in the MS headers
> */
> ++
> + struct curl_schannel_cred {
> + CredHandle cred_handle;
> + TimeStamp time_stamp;
> +@@ -101,6 +103,7 @@ struct ssl_backend_data {
> + #ifdef HAS_MANUAL_VERIFY_API
> + bool use_manual_cred_validation; /* true if manual cred
> validation is used */
> + #endif
> ++ ALG_ID algIds[NUMOF_CIPHERS];
> + };
> + #endif /* EXPOSE_SCHANNEL_INTERNAL_STRUCTS */
> +
> diff --git a/meta/recipes-support/curl/curl_7.69.1.bb b/meta/recipes-
> support/curl/curl_7.69.1.bb
> index ea36c0bd3d..384719dd15 100644
> --- a/meta/recipes-support/curl/curl_7.69.1.bb
> +++ b/meta/recipes-support/curl/curl_7.69.1.bb
> @@ -19,6 +19,7 @@ SRC_URI =
> "https://curl.haxx.se/download/curl-${PV}.tar.bz2 \
> file://CVE-2020-8286.patch \
> file://CVE-2021-22876.patch \
> file://CVE-2021-22890.patch \
> + file://CVE-2021-22897.patch \
> file://CVE-2021-22898.patch \
> file://CVE-2021-22924.patch \
> file://CVE-2021-22925.patch \
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178333):
https://lists.openembedded.org/g/openembedded-core/message/178333
Mute This Topic: https://lists.openembedded.org/mt/97518402/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell][PATCH] curl: Fix CVE CVE-2021-22897
https://curl.se/docs/CVE-2021-22897.html
Signed-off-by: Andrej Valek
---
.../curl/curl/CVE-2021-22897.patch| 73 +++
meta/recipes-support/curl/curl_7.69.1.bb | 1 +
2 files changed, 74 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2021-22897.patch
diff --git a/meta/recipes-support/curl/curl/CVE-2021-22897.patch
b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
new file mode 100644
index 00..cbd6c067ce
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
@@ -0,0 +1,73 @@
+From bbb71507b7bab52002f9b1e0880bed6a32834511 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg
+Date: Fri, 23 Apr 2021 10:54:10 +0200
+Subject: [PATCH] schannel: don't use static to store selected ciphers
+
+CVE-2021-22897
+
+Bug: https://curl.se/docs/CVE-2021-22897.html
+
+Upstream-Status: Backport
+[https://github.com/curl/curl/commit/bbb71507b7bab52002f9b1e0880bed6a32834511]
+
+CVE: CVE-2021-22897
+
+Signed-off-by: Daniel Stenberg
+Signed-off-by: Khairul Rohaizzat Jamaluddin
+Signed-off-by: Andrej Valek
+---
+ lib/vtls/schannel.c | 9 +
+ lib/vtls/schannel.h | 3 +++
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
+index 8c25ac5dd5a5..dba7072273a9 100644
+--- a/lib/vtls/schannel.c
b/lib/vtls/schannel.c
+@@ -322,12 +322,12 @@ get_alg_id_by_name(char *name)
+ }
+
+ static CURLcode
+-set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers)
++set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers,
++int *algIds)
+ {
+ char *startCur = ciphers;
+ int algCount = 0;
+- static ALG_ID algIds[45]; /*There are 45 listed in the MS headers*/
+- while(startCur && (0 != *startCur) && (algCount < 45)) {
++ while(startCur && (0 != *startCur) && (algCount < NUMOF_CIPHERS)) {
+ long alg = strtol(startCur, 0, 0);
+ if(!alg)
+ alg = get_alg_id_by_name(startCur);
+@@ -566,7 +566,8 @@ schannel_connect_step1(struct connectdat
+ }
+
+ if(SSL_CONN_CONFIG(cipher_list)) {
+- result = set_ssl_ciphers(_cred, SSL_CONN_CONFIG(cipher_list));
++ result = set_ssl_ciphers(_cred, SSL_CONN_CONFIG(cipher_list),
++ BACKEND->algIds);
+ if(CURLE_OK != result) {
+ failf(data, "Unable to set ciphers to passed via SSL_CONN_CONFIG");
+ return result;
+diff --git a/lib/vtls/schannel.h b/lib/vtls/schannel.h
+index 2952caa1a5a1..77853aa30f96 100644
+--- a/lib/vtls/schannel.h
b/lib/vtls/schannel.h
+@@ -70,6 +70,8 @@ CURLcode Curl_verify_certificate(struct
+ #endif
+ #endif
+
++#define NUMOF_CIPHERS 45 /* There are 45 listed in the MS headers */
++
+ struct curl_schannel_cred {
+ CredHandle cred_handle;
+ TimeStamp time_stamp;
+@@ -101,6 +103,7 @@ struct ssl_backend_data {
+ #ifdef HAS_MANUAL_VERIFY_API
+ bool use_manual_cred_validation; /* true if manual cred validation is used
*/
+ #endif
++ ALG_ID algIds[NUMOF_CIPHERS];
+ };
+ #endif /* EXPOSE_SCHANNEL_INTERNAL_STRUCTS */
+
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
b/meta/recipes-support/curl/curl_7.69.1.bb
index ea36c0bd3d..384719dd15 100644
--- a/meta/recipes-support/curl/curl_7.69.1.bb
+++ b/meta/recipes-support/curl/curl_7.69.1.bb
@@ -19,6 +19,7 @@ SRC_URI = "https://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://CVE-2020-8286.patch \
file://CVE-2021-22876.patch \
file://CVE-2021-22890.patch \
+ file://CVE-2021-22897.patch \
file://CVE-2021-22898.patch \
file://CVE-2021-22924.patch \
file://CVE-2021-22925.patch \
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178331):
https://lists.openembedded.org/g/openembedded-core/message/178331
Mute This Topic: https://lists.openembedded.org/mt/97518402/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell][PATCH 2/2] curl: whitelists CVE-2022-42915, CVE-2022-42916 and CVE-2022-43551
All mentioned CVEs are related to HSTS check feature, which is not
implemented in version 7.69.1 .
Signed-off-by: Andrej Valek
---
meta/recipes-support/curl/curl_7.69.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
b/meta/recipes-support/curl/curl_7.69.1.bb
index 899daf8eac..ea36c0bd3d 100644
--- a/meta/recipes-support/curl/curl_7.69.1.bb
+++ b/meta/recipes-support/curl/curl_7.69.1.bb
@@ -56,6 +56,9 @@ CVE_CHECK_WHITELIST = "CVE-2021-22922 CVE-2021-22923
CVE-2021-22926 CVE-2021-229
# This CVE issue affects Windows only Hence whitelisting this CVE
CVE_CHECK_WHITELIST += "CVE-2021-22897"
+# HSTS check feature is not implemented
+CVE_CHECK_WHITELIST += "CVE-2022-42915 CVE-2022-42916 CVE-2022-43551"
+
inherit autotools pkgconfig binconfig multilib_header
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls
libidn proxy threaded-resolver verbose zlib"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178321):
https://lists.openembedded.org/g/openembedded-core/message/178321
Mute This Topic: https://lists.openembedded.org/mt/97516349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell][PATCH 1/2] curl: Fix CVE CVE-2022-43552
https://curl.se/docs/CVE-2022-43552.html
Signed-off-by: Andrej Valek
---
.../curl/curl/CVE-2022-43552.patch| 79 +++
meta/recipes-support/curl/curl_7.69.1.bb | 1 +
2 files changed, 80 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2022-43552.patch
diff --git a/meta/recipes-support/curl/curl/CVE-2022-43552.patch
b/meta/recipes-support/curl/curl/CVE-2022-43552.patch
new file mode 100644
index 00..7dc7dfa5ae
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2022-43552.patch
@@ -0,0 +1,79 @@
+From 4f20188ac644afe174be6005ef4f6ffba232b8b2 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg
+Date: Mon, 19 Dec 2022 08:38:37 +0100
+Subject: [PATCH] smb/telnet: do not free the protocol struct in *_done()
+
+It is managed by the generic layer.
+
+Reported-by: Trail of Bits
+
+Closes #10112
+
+CVE: CVE-2022-43552
+Upstream-Status: Backport
[https://github.com/curl/curl/commit/4f20188ac644afe174be6005ef4f6ffba232b8b2]
+Signed-off-by: Ranjitsinh Rathod
+Signed-off-by: Andrej Valek
+
+---
+ lib/smb.c| 14 ++
+ lib/telnet.c | 3 ---
+ 2 files changed, 2 insertions(+), 15 deletions(-)
+
+diff --git a/lib/smb.c b/lib/smb.c
+index 2cfe041dff072..48d5a2fe006d5 100644
+--- a/lib/smb.c
b/lib/smb.c
+@@ -61,8 +61,6 @@ static CURLcode smb_connect(struct conne
+ static CURLcode smb_connection_state(struct connectdata *conn, bool *done);
+ static CURLcode smb_do(struct connectdata *conn, bool *done);
+ static CURLcode smb_request_state(struct connectdata *conn, bool *done);
+-static CURLcode smb_done(struct connectdata *conn, CURLcode status,
+- bool premature);
+ static CURLcode smb_disconnect(struct connectdata *conn, bool dead);
+ static int smb_getsock(struct connectdata *conn, curl_socket_t *socks);
+ static CURLcode smb_parse_url_path(struct connectdata *conn);
+@@ -74,7 +72,7 @@ const struct Curl_handler Curl_handler_s
+ "SMB",/* scheme */
+ smb_setup_connection, /* setup_connection */
+ smb_do, /* do_it */
+- smb_done, /* done */
++ ZERO_NULL,/* done */
+ ZERO_NULL,/* do_more */
+ smb_connect, /* connect_it */
+ smb_connection_state, /* connecting */
+@@ -99,7 +97,7 @@ const struct Curl_handler Curl_handler_s
+ "SMBS", /* scheme */
+ smb_setup_connection, /* setup_connection */
+ smb_do, /* do_it */
+- smb_done, /* done */
++ ZERO_NULL,/* done */
+ ZERO_NULL,/* do_more */
+ smb_connect, /* connect_it */
+ smb_connection_state, /* connecting */
+@@ -919,14 +917,6 @@ static CURLcode smb_request_state(struct
+ return CURLE_OK;
+ }
+
+-static CURLcode smb_done(struct connectdata *conn, CURLcode status,
+- bool premature)
+-{
+- (void) premature;
+- Curl_safefree(conn->data->req.protop);
+- return status;
+-}
+-
+ static CURLcode smb_disconnect(struct connectdata *conn, bool dead)
+ {
+ struct smb_conn *smbc = >proto.smbc;
+diff -Naurp curl-7.69.1.orig/lib/telnet.c curl-7.69.1/lib/telnet.c
+--- curl-7.69.1.orig/lib/telnet.c 2020-03-09 16:31:01.0 +0100
curl-7.69.1/lib/telnet.c 2023-03-10 10:35:27.978378949 +0100
+@@ -1290,8 +1290,6 @@ static CURLcode telnet_done(struct conne
+ curl_slist_free_all(tn->telnet_vars);
+ tn->telnet_vars = NULL;
+
+- Curl_safefree(conn->data->req.protop);
+-
+ return CURLE_OK;
+ }
+
\ No newline at end of file
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
b/meta/recipes-support/curl/curl_7.69.1.bb
index 63faae6296..899daf8eac 100644
--- a/meta/recipes-support/curl/curl_7.69.1.bb
+++ b/meta/recipes-support/curl/curl_7.69.1.bb
@@ -41,6 +41,7 @@ SRC_URI = "https://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://CVE-2022-35252.patch \
file://CVE-2022-32221.patch \
file://CVE-2022-35260.patch \
+ file://CVE-2022-43552.patch \
"
SRC_URI[md5sum] = "ec5fc263f898a3dfef08e805f1ecca42"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178320):
https://lists.openembedded.org/g/openembedded-core/message/178320
Mute This Topic: https://lists.openembedded.org/mt/97516348/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] curl
Hello Steve, I have a question about curl. Would it be possible to backport some fixes for CVEs from kirkstone to dunfell? CVE-2022-32221 CVE-2022-42915 CVE-2022-42916 CVE-2022-43552 CVE-2022-43551 Thank you, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178225): https://lists.openembedded.org/g/openembedded-core/message/178225 Mute This Topic: https://lists.openembedded.org/mt/97497830/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone] Google go CVEs
Hello Alex, Yes, that would an option, but afaik it wasn't working quite well. So I would still prefer a straight forward solution. Should I spend some time for creating such patches? Means if there will be a potential option for being accepted? Andrej On Tue, 2023-03-07 at 07:37 +0100, Alexander Kanavin wrote: > You probably should make a kirkstone mixin layer like we did for > dunfell. > https://git.yoctoproject.org/meta-lts-mixins/ > > Alex > > On Tue, 7 Mar 2023 at 07:32, Andrej Valek > wrote: > > > > Hello everyone, > > > > I would like to ask you how to proceed with multiple CVEs for > > Google Go > > component in kirkstone branch. > > > > CVEs in current version 1.17.13: > > - CVE-2022-41722 > > - CVE-2022-41725 > > - CVE-2022-41724 > > - CVE-2022-41723 > > > > They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are > > available for all of them too. Unfortunately there is more then > > ~1000 > > changed LOC. So not sure if this is the right approach to apply > > them. > > Not sure if the upgrade is acceptable. > > > > So how to proceed with this? > > > > I know, that they aren't a critical one, but would be nice to have > > them > > fixed. > > > > Regards, > > Andrej > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178094): https://lists.openembedded.org/g/openembedded-core/message/178094 Mute This Topic: https://lists.openembedded.org/mt/97444547/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone] Google go CVEs
Hello everyone, I would like to ask you how to proceed with multiple CVEs for Google Go component in kirkstone branch. CVEs in current version 1.17.13: - CVE-2022-41722 - CVE-2022-41725 - CVE-2022-41724 - CVE-2022-41723 They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are available for all of them too. Unfortunately there is more then ~1000 changed LOC. So not sure if this is the right approach to apply them. Not sure if the upgrade is acceptable. So how to proceed with this? I know, that they aren't a critical one, but would be nice to have them fixed. Regards, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178089): https://lists.openembedded.org/g/openembedded-core/message/178089 Mute This Topic: https://lists.openembedded.org/mt/97444547/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] busybox: 1.35.0 -> 1.36.0
I guess, we should wait a little bit with the merging here, because
this problem is known in the same busybox mailing list thread.
Andrej
On Wed, 2023-01-11 at 11:33 -0800, Khem Raj wrote:
> On Wed, Jan 11, 2023 at 2:54 AM Alexandre Belloni via
> lists.openembedded.org
> wrote:
> >
> > This generates a warning:
> >
> > WARNING: busybox-1.36.0-r0 do_package_qa: QA Issue: busybox: ELF
> > binary /bin/busybox.nosuid has relocations in .text [textrel]
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/6507/steps/11/logs/stdio
>
> hmmm yes. I think texrels is the fundamental problem originally. I
> will take a look and see if this one is harmless
>
> >
> > On 06/01/2023 12:05:05+0100, Andrej Valek wrote:
> > > - update to next (un)stable version 1.36.0
> > > - refresh defconfig
> > > - disable new applets (tree, tsort, seedrng)
> > > - use hw-accel for sha1/256 sums when available
> > > - remove and refresh already merged patches
> > >
> > > Signed-off-by: Andrej Valek
> > > ---
> > > ...ab_1.35.0.bb => busybox-inittab_1.36.0.bb} | 0
> > > .../0001-devmem-add-128-bit-width.patch | 128
> > > --
> > > .../busybox/busybox/CVE-2022-30065.patch | 29
> > > meta/recipes-core/busybox/busybox/defconfig | 10 +-
> > > .../busybox/busybox/recognize_connmand.patch | 10 +-
> > > meta/recipes-core/busybox/busybox/sha1sum.cfg | 2 +
> > > .../busybox/busybox/sha256sum.cfg | 1 +
> > > .../{busybox_1.35.0.bb => busybox_1.36.0.bb} | 4 +-
> > > 8 files changed, 17 insertions(+), 167 deletions(-)
> > > rename meta/recipes-core/busybox/{busybox-inittab_1.35.0.bb =>
> > > busybox-inittab_1.36.0.bb} (100%)
> > > delete mode 100644 meta/recipes-core/busybox/busybox/0001-
> > > devmem-add-128-bit-width.patch
> > > delete mode 100644 meta/recipes-core/busybox/busybox/CVE-2022-
> > > 30065.patch
> > > rename meta/recipes-core/busybox/{busybox_1.35.0.bb =>
> > > busybox_1.36.0.bb} (92%)
> > >
> > > diff --git a/meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
> > > b/meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
> > > similarity index 100%
> > > rename from meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
> > > rename to meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
> > > diff --git a/meta/recipes-core/busybox/busybox/0001-devmem-add-
> > > 128-bit-width.patch b/meta/recipes-core/busybox/busybox/0001-
> > > devmem-add-128-bit-width.patch
> > > deleted file mode 100644
> > > index 985e2bf1d9..00
> > > --- a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-
> > > width.patch
> > > +++ /dev/null
> > > @@ -1,128 +0,0 @@
> > > -From d432049f288c9acdc4a7caa729c68ceba3c5dca1 Mon Sep 17
> > > 00:00:00 2001
> > > -From: Aaro Koskinen
> > > -Date: Thu, 25 Aug 2022 18:47:02 +0300
> > > -Subject: [PATCH] devmem: add 128-bit width
> > > -
> > > -Add 128-bit width if the compiler provides the needed type.
> > > -
> > > -function old
> > > new delta
> > > -devmem_main 405
> > > 464 +59
> > > -.rodata 109025
> > > 109043 +18
> > > -
> > > --
> > > -(add/remove: 0/0 grow/shrink: 2/0 up/down: 77/0)
> > > Total: 77 bytes
> > > -
> > > -Upstream-Status: Backport
> > > [https://git.busybox.net/busybox/commit/?id=d432049f288c9acdc4a7caa729c68ceba3c5dca1
> > > ]
> > > -
> > > -Signed-off-by: Aaro Koskinen
> > > -Signed-off-by: Aaro Koskinen
> > > -Signed-off-by: Denys Vlasenko
> > > -Signed-off-by: Mingli Yu
> > >
> > > - miscutils/devmem.c | 68 ++-
> > > ---
> > > - 1 file changed, 44 insertions(+), 24 deletions(-)
> > > -
> > > -diff --git a/miscutils/devmem.c b/miscutils/devmem.c
> > > -index f9f0276bc..f21621bd6 100644
> > > a/miscutils/devmem.c
> > > -+++ b/miscutils/devmem.c
> > > -@@ -29,7 +29,6 @@ int devmem_main(int argc UNUSED_PARAM, char
> > > **argv)
> > > - {
> > > - void *map_base, *virt_addr;
> > > -
Re: [OE-core][PATCH] busybox: 1.35.0 -> 1.36.0
Ok, looks like the we aren't only one who have this problem
http://lists.busybox.net/pipermail/busybox/2023-January/090082.html .
Maybe we can disable the sha256 acceleration.
Can you make a try?
Regards,
Andrej
On Sun, 2023-01-08 at 06:34 -0800, Khem Raj wrote:
> On Sun, Jan 8, 2023 at 5:17 AM Valek, Andrej
> wrote:
> >
> > Hello Raj,
> >
> > Which applets have the problem, klogd and syslogd, or? I see there
> > some
> > kind of libc segmentation.
> >
> > Maybe we should unset the CONFIG_STATIC_LIBGCC=y which could be an
> > improvement at all.
>
> so far its klogd, syslogd and sh
>
> >
> > Regards,
> > Andrej
> >
> > On Fri, 2023-01-06 at 22:23 -0800, Khem Raj wrote:
> > > some applets are segfaulting on qemux86/musl
> > >
> > > [ 2.754687] klogd[202]: segfault at 56da7e ip b7f4d668 sp
> > > bfdb0300
> > > error 7 in libc.so[b7eda000+76000]
> > > [ 2.759018] syslogd[203]: segfault at 506a7e ip b7f74668 sp
> > > bf997dd0 error 7 in libc.so[b7f01000+76000]
> > > [ 61.264333] sh[279]: segfault at 4d4a7e ip b7f5d668 sp bfff6610
> > > error 7 in libc.so[b7eea000+76000]
> > >
> > > and it bails out logging in.
> > >
> > > On Fri, Jan 6, 2023 at 3:05 AM Andrej Valek
> > > wrote:
> > > >
> > > > - update to next (un)stable version 1.36.0
> > > > - refresh defconfig
> > > > - disable new applets (tree, tsort, seedrng)
> > > > - use hw-accel for sha1/256 sums when available
> > > > - remove and refresh already merged patches
> > > >
> > > > Signed-off-by: Andrej Valek
> > > > ---
> > > > ...ab_1.35.0.bb => busybox-inittab_1.36.0.bb} | 0
> > > > .../0001-devmem-add-128-bit-width.patch | 128
> > > > --
> > > >
> > > > .../busybox/busybox/CVE-2022-30065.patch | 29
> > > > meta/recipes-core/busybox/busybox/defconfig | 10 +-
> > > > .../busybox/busybox/recognize_connmand.patch | 10 +-
> > > > meta/recipes-core/busybox/busybox/sha1sum.cfg | 2 +
> > > > .../busybox/busybox/sha256sum.cfg | 1 +
> > > > .../{busybox_1.35.0.bb => busybox_1.36.0.bb} | 4 +-
> > > > 8 files changed, 17 insertions(+), 167 deletions(-)
> > > > rename meta/recipes-core/busybox/{busybox-inittab_1.35.0.bb =>
> > > > busybox-inittab_1.36.0.bb} (100%)
> > > > delete mode 100644 meta/recipes-core/busybox/busybox/0001-
> > > > devmem-
> > > > add-128-bit-width.patch
> > > > delete mode 100644 meta/recipes-core/busybox/busybox/CVE-2022-
> > > > 30065.patch
> > > > rename meta/recipes-core/busybox/{busybox_1.35.0.bb =>
> > > > busybox_1.36.0.bb} (92%)
> > > >
> > > > diff --git a/meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
> > > > b/meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
> > > > rename to meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
> > > > diff --git a/meta/recipes-core/busybox/busybox/0001-devmem-add-
> > > > 128-
> > > > bit-width.patch b/meta/recipes-core/busybox/busybox/0001-devmem-
> > > > add-128-bit-width.patch
> > > > deleted file mode 100644
> > > > index 985e2bf1d9..00
> > > > --- a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-
> > > > width.patch
> > > > +++ /dev/null
> > > > @@ -1,128 +0,0 @@
> > > > -From d432049f288c9acdc4a7caa729c68ceba3c5dca1 Mon Sep 17
> > > > 00:00:00
> > > > 2001
> > > > -From: Aaro Koskinen
> > > > -Date: Thu, 25 Aug 2022 18:47:02 +0300
> > > > -Subject: [PATCH] devmem: add 128-bit width
> > > > -
> > > > -Add 128-bit width if the compiler provides the needed type.
> > > > -
> > > > -function old new
> > > > delta
> > > > -devmem_main 405
> > > > 464 +59
> > > > -.rodata 109025
> > > > 109043 +18
> > > > -
> > > > --
> > > >
> > > > -(add/remove: 0/0
Re: [OE-core][PATCH] busybox: 1.35.0 -> 1.36.0
Hello Raj,
Which applets have the problem, klogd and syslogd, or? I see there some
kind of libc segmentation.
Maybe we should unset the CONFIG_STATIC_LIBGCC=y which could be an
improvement at all.
Regards,
Andrej
On Fri, 2023-01-06 at 22:23 -0800, Khem Raj wrote:
> some applets are segfaulting on qemux86/musl
>
> [ 2.754687] klogd[202]: segfault at 56da7e ip b7f4d668 sp bfdb0300
> error 7 in libc.so[b7eda000+76000]
> [ 2.759018] syslogd[203]: segfault at 506a7e ip b7f74668 sp
> bf997dd0 error 7 in libc.so[b7f01000+76000]
> [ 61.264333] sh[279]: segfault at 4d4a7e ip b7f5d668 sp bfff6610
> error 7 in libc.so[b7eea000+76000]
>
> and it bails out logging in.
>
> On Fri, Jan 6, 2023 at 3:05 AM Andrej Valek
> wrote:
> >
> > - update to next (un)stable version 1.36.0
> > - refresh defconfig
> > - disable new applets (tree, tsort, seedrng)
> > - use hw-accel for sha1/256 sums when available
> > - remove and refresh already merged patches
> >
> > Signed-off-by: Andrej Valek
> > ---
> > ...ab_1.35.0.bb => busybox-inittab_1.36.0.bb} | 0
> > .../0001-devmem-add-128-bit-width.patch | 128 --
> >
> > .../busybox/busybox/CVE-2022-30065.patch | 29
> > meta/recipes-core/busybox/busybox/defconfig | 10 +-
> > .../busybox/busybox/recognize_connmand.patch | 10 +-
> > meta/recipes-core/busybox/busybox/sha1sum.cfg | 2 +
> > .../busybox/busybox/sha256sum.cfg | 1 +
> > .../{busybox_1.35.0.bb => busybox_1.36.0.bb} | 4 +-
> > 8 files changed, 17 insertions(+), 167 deletions(-)
> > rename meta/recipes-core/busybox/{busybox-inittab_1.35.0.bb =>
> > busybox-inittab_1.36.0.bb} (100%)
> > delete mode 100644 meta/recipes-core/busybox/busybox/0001-devmem-
> > add-128-bit-width.patch
> > delete mode 100644 meta/recipes-core/busybox/busybox/CVE-2022-
> > 30065.patch
> > rename meta/recipes-core/busybox/{busybox_1.35.0.bb =>
> > busybox_1.36.0.bb} (92%)
> >
> > diff --git a/meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
> > b/meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
> > similarity index 100%
> > rename from meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
> > rename to meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
> > diff --git a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-
> > bit-width.patch b/meta/recipes-core/busybox/busybox/0001-devmem-
> > add-128-bit-width.patch
> > deleted file mode 100644
> > index 985e2bf1d9..00
> > --- a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-
> > width.patch
> > +++ /dev/null
> > @@ -1,128 +0,0 @@
> > -From d432049f288c9acdc4a7caa729c68ceba3c5dca1 Mon Sep 17 00:00:00
> > 2001
> > -From: Aaro Koskinen
> > -Date: Thu, 25 Aug 2022 18:47:02 +0300
> > -Subject: [PATCH] devmem: add 128-bit width
> > -
> > -Add 128-bit width if the compiler provides the needed type.
> > -
> > -function old new
> > delta
> > -devmem_main 405
> > 464 +59
> > -.rodata 109025
> > 109043 +18
> > ---
> >
> > -(add/remove: 0/0 grow/shrink: 2/0 up/down: 77/0)
> > Total: 77 bytes
> > -
> > -Upstream-Status: Backport
> > [https://git.busybox.net/busybox/commit/?id=d432049f288c9acdc4a7caa729c68ceba3c5dca1
> > ]
> > -
> > -Signed-off-by: Aaro Koskinen
> > -Signed-off-by: Aaro Koskinen
> > -Signed-off-by: Denys Vlasenko
> > -Signed-off-by: Mingli Yu
> >
> > - miscutils/devmem.c | 68 ++---
> > -
> > - 1 file changed, 44 insertions(+), 24 deletions(-)
> > -
> > -diff --git a/miscutils/devmem.c b/miscutils/devmem.c
> > -index f9f0276bc..f21621bd6 100644
> > a/miscutils/devmem.c
> > -+++ b/miscutils/devmem.c
> > -@@ -29,7 +29,6 @@ int devmem_main(int argc UNUSED_PARAM, char
> > **argv)
> > - {
> > - void *map_base, *virt_addr;
> > - uint64_t read_result;
> > -- uint64_t writeval = writeval; /* for compiler */
> > - off_t target;
> > - unsigned page_size, mapped_size, offset_in_page;
> > - int fd;
> > -@@ -64,9 +63,6 @@ int devmem_main(int argc UNUSED_PARAM, char
> > **argv)
> > - width = strchrnul(bhwl, (argv[2][0] |
> > 0x20)) - bhwl;
> > -
[OE-core][PATCH] busybox: 1.35.0 -> 1.36.0
- update to next (un)stable version 1.36.0
- refresh defconfig
- disable new applets (tree, tsort, seedrng)
- use hw-accel for sha1/256 sums when available
- remove and refresh already merged patches
Signed-off-by: Andrej Valek
---
...ab_1.35.0.bb => busybox-inittab_1.36.0.bb} | 0
.../0001-devmem-add-128-bit-width.patch | 128 --
.../busybox/busybox/CVE-2022-30065.patch | 29
meta/recipes-core/busybox/busybox/defconfig | 10 +-
.../busybox/busybox/recognize_connmand.patch | 10 +-
meta/recipes-core/busybox/busybox/sha1sum.cfg | 2 +
.../busybox/busybox/sha256sum.cfg | 1 +
.../{busybox_1.35.0.bb => busybox_1.36.0.bb} | 4 +-
8 files changed, 17 insertions(+), 167 deletions(-)
rename meta/recipes-core/busybox/{busybox-inittab_1.35.0.bb =>
busybox-inittab_1.36.0.bb} (100%)
delete mode 100644
meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch
delete mode 100644 meta/recipes-core/busybox/busybox/CVE-2022-30065.patch
rename meta/recipes-core/busybox/{busybox_1.35.0.bb => busybox_1.36.0.bb} (92%)
diff --git a/meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
b/meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
similarity index 100%
rename from meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
rename to meta/recipes-core/busybox/busybox-inittab_1.36.0.bb
diff --git
a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch
b/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch
deleted file mode 100644
index 985e2bf1d9..00
--- a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From d432049f288c9acdc4a7caa729c68ceba3c5dca1 Mon Sep 17 00:00:00 2001
-From: Aaro Koskinen
-Date: Thu, 25 Aug 2022 18:47:02 +0300
-Subject: [PATCH] devmem: add 128-bit width
-
-Add 128-bit width if the compiler provides the needed type.
-
-function old new delta
-devmem_main 405 464 +59
-.rodata 109025 109043 +18
---
-(add/remove: 0/0 grow/shrink: 2/0 up/down: 77/0) Total: 77 bytes
-
-Upstream-Status: Backport
[https://git.busybox.net/busybox/commit/?id=d432049f288c9acdc4a7caa729c68ceba3c5dca1]
-
-Signed-off-by: Aaro Koskinen
-Signed-off-by: Aaro Koskinen
-Signed-off-by: Denys Vlasenko
-Signed-off-by: Mingli Yu
- miscutils/devmem.c | 68 ++
- 1 file changed, 44 insertions(+), 24 deletions(-)
-
-diff --git a/miscutils/devmem.c b/miscutils/devmem.c
-index f9f0276bc..f21621bd6 100644
a/miscutils/devmem.c
-+++ b/miscutils/devmem.c
-@@ -29,7 +29,6 @@ int devmem_main(int argc UNUSED_PARAM, char **argv)
- {
- void *map_base, *virt_addr;
- uint64_t read_result;
-- uint64_t writeval = writeval; /* for compiler */
- off_t target;
- unsigned page_size, mapped_size, offset_in_page;
- int fd;
-@@ -64,9 +63,6 @@ int devmem_main(int argc UNUSED_PARAM, char **argv)
- width = strchrnul(bhwl, (argv[2][0] | 0x20)) - bhwl;
- width = sizes[width];
- }
-- /* VALUE */
-- if (argv[3])
-- writeval = bb_strtoull(argv[3], NULL, 0);
- } else { /* argv[2] == NULL */
- /* make argv[3] to be a valid thing to fetch */
- argv--;
-@@ -96,28 +92,46 @@ int devmem_main(int argc UNUSED_PARAM, char **argv)
- virt_addr = (char*)map_base + offset_in_page;
-
- if (!argv[3]) {
-- switch (width) {
-- case 8:
-- read_result = *(volatile uint8_t*)virt_addr;
-- break;
-- case 16:
-- read_result = *(volatile uint16_t*)virt_addr;
-- break;
-- case 32:
-- read_result = *(volatile uint32_t*)virt_addr;
-- break;
-- case 64:
-- read_result = *(volatile uint64_t*)virt_addr;
-- break;
-- default:
-- bb_simple_error_msg_and_die("bad width");
-+#ifdef __SIZEOF_INT128__
-+ if (width == 128) {
-+ unsigned __int128 rd =
-+ *(volatile unsigned __int128 *)virt_addr;
-+ printf("0x%016llX%016llX\n",
-+ (unsigned long long)(uint64_t)(rd >> 64),
-+ (unsigned long long)(uint64_t)rd
-+ );
-+ } else
-+#endif
-+ {
-+ switch (width) {
-+ case 8:
-+ read_result = *(volatile uint8_t*)virt_addr;
[OE-core] eSDK cherry-picks
Hello Steve, Would it be possible to include these commits https://git.yoctoproject.org/poky/commit/?id=4fd15f4e3ad50ba1830b20a5e339d75ebb74a4ce https://git.yoctoproject.org/poky/commit/?id=7e4b96e911f6b308aa1c970db37881d62ddefcac into kirkstone branch? I guess, some older branches are affected too. The dunfell branch is safe. Thanks, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#172146): https://lists.openembedded.org/g/openembedded-core/message/172146 Mute This Topic: https://lists.openembedded.org/mt/94577144/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] scripts: include all dependencies in eSDK
Without this recursive dependency on do_build task, eSDK includes only direct image dependencies and there for devtool recipe has to rebuild them all. Resolves: [YOCTO#14626] Signed-off-by: Andrej Valek Signed-off-by: Peter Marko --- scripts/oe-check-sstate | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/oe-check-sstate b/scripts/oe-check-sstate index f4cc5869de..5c185fa85e 100755 --- a/scripts/oe-check-sstate +++ b/scripts/oe-check-sstate @@ -52,7 +52,7 @@ def check(args): try: output = subprocess.check_output( -'bitbake -n %s' % ' '.join(args.target), +'bitbake -n --runall build %s' % ' '.join(args.target), stderr=subprocess.STDOUT, env=env, shell=True) -- 2.34.3 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171935): https://lists.openembedded.org/g/openembedded-core/message/171935 Mute This Topic: https://lists.openembedded.org/mt/94403115/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] eSDK dependencies
Hi Ross, I did that. current behavior: $ devtool modify busybox Initialising tasks: 100% |###| Time: 0:00:00 Sstate summary: Wanted 14 Local 0 Mirrors 0 Missed 14 Current 6 (0% match, 30% complete) NOTE: Executing Tasks ... your new behavior: @@ -52,7 +52,7 @@ def check(args): try: output = subprocess.check_output( -'bitbake -n %s' % ' '.join(args.target), +'bitbake --runall build -n %s' % ' '.join(args.target), stderr=subprocess.STDOUT, env=env, $ devtool modify busybox Initialising tasks: 100% |###| Time: 0:00:00 Sstate summary: Wanted 14 Local 4 Mirrors 0 Missed 10 Current 6 (28% match, 50% complete) NOTE: Executing Tasks ... It just start fetching, patching... tasks without any dependencies build. Looks like, that this is exactly what we wanted to achieve. Let me ask the question about the percentage... why is 28% of match? Regards, Andrej On Thu, 2022-10-13 at 10:15 +, Ross Burton wrote: > > > > On 13 Oct 2022, at 09:23, Andrej Valek via lists.openembedded.org > > wrote: > > I had some time and made some more testing. > > > > Looks like, that the problematic commits are here: > > https://github.com/openembedded/openembedded-core/commit/41d7f1aa2cc9ef5dba4db38435402d4c9c0a63e1 > > https://github.com/openembedded/openembedded-core/commit/6e2cbfc561dac89bf9183d24d90e52f7d9117826 > > https://github.com/openembedded/openembedded-core/commit/030d56e2e8ece93472adc51fe467221d846c9ac0 > > > > Means, that recursive do_build task is not being executed on image > > level anymore. After re-creating/adding the meta class and inheriting > > it in populate_sdk_base, the image now contains all the missing deps. > > > > I tried to execute the "bitbake my-image -c populate_sdk_ext --runall > > build", but "--runall" destroyed the populate_sdk_ext task, so in > > this > > case is unusable. > > > > So what's the right way to get it working again? > > So the good news is that a few others reported this issue and a bug was > filed: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14626 > > Annoyingly, nobody who saw the bug remembered this thread. > > My hunch was that dependency rationalisation meant less > do_populate_sysroot calls, based on how the eSDK creation is done. If > you’ve isolated it down to those commits then that’s an indication my > hunch was right. > > Can you test something for me? Switch back to pristine oe-core without > the reverts, and add the ‘—runall build’ option to the bitbake call in > scripts/oe-check-sstate (line ~54). > > Thanks, > Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171701): https://lists.openembedded.org/g/openembedded-core/message/171701 Mute This Topic: https://lists.openembedded.org/mt/92019337/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] eSDK dependencies
Hello again, I had some time and made some more testing. Looks like, that the problematic commits are here: https://github.com/openembedded/openembedded-core/commit/41d7f1aa2cc9ef5dba4db38435402d4c9c0a63e1 https://github.com/openembedded/openembedded-core/commit/6e2cbfc561dac89bf9183d24d90e52f7d9117826 https://github.com/openembedded/openembedded-core/commit/030d56e2e8ece93472adc51fe467221d846c9ac0 Means, that recursive do_build task is not being executed on image level anymore. After re-creating/adding the meta class and inheriting it in populate_sdk_base, the image now contains all the missing deps. I tried to execute the "bitbake my-image -c populate_sdk_ext --runall build", but "--runall" destroyed the populate_sdk_ext task, so in this case is unusable. So what's the right way to get it working again? Regards, Andrej On Tue, 2022-06-28 at 11:16 +0100, Richard Purdie wrote: > On Tue, 2022-06-28 at 07:55 +, Valek, Andrej wrote: > > Hello Richard and Alex, > > > > Richard: > > We tried to revert the commits which you mentioned and it didn't > > work. > > > > Alex: > > Yes, is fully reproducible on latest master. > > > > bitbake core-image-minimal -c populate_sdk_ext > > > > eSDK installed via: poky-glibc-x86_64-core-image-minimal- > > cortexa15t2hf- > > neon-qemuarm-toolchain-ext-4.1+snapshot.sh > > > > . environment-setup-cortexa15t2hf-neon-poky-linux-gnueabi > > devtool modify busybox > > > > Sstate summary: Wanted 14 Local 0 Mirrors 0 Missed 14 Current 6 (0% > > match, 30% complete) > > > > So it started a compilation of missing components. We are assuming, > > that eSDK will include all build deps for all components in the image > > and not just a deps for image itself. > > Ok. To confirm, SDK_EXT_TYPE is set to full in both cases? Could you > share the locked-sigs.inc file from both? I'd like to understand if the > tools are there but not being used or whether they're really not there > at all. Is there much of a size difference between the two eSDKs? > > I suspect some kind of bisection to track down the change causing the > issue will be necessary unfortunately but at least that test case is > relatively straightforward... > > Cheers, > > Richard > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171690): https://lists.openembedded.org/g/openembedded-core/message/171690 Mute This Topic: https://lists.openembedded.org/mt/92019337/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] eSDK dependencies
Hello Richard, Yes, but variants have set SDK_EXT_TYPE=full. Can't say about the pure poky eSDK, but with our layers, size is different. Let's say 2/3 of the "working" one. Do you really need locked-sigs.inc from both variant? I guess, you only need to know if some entries are missing and not the values. If yes, then I have to build the old "working" on based on dunfell. Regards, Andrej On Tue, 2022-06-28 at 11:16 +0100, Richard Purdie wrote: > On Tue, 2022-06-28 at 07:55 +, Valek, Andrej wrote: > > Hello Richard and Alex, > > > > Richard: > > We tried to revert the commits which you mentioned and it didn't > > work. > > > > Alex: > > Yes, is fully reproducible on latest master. > > > > bitbake core-image-minimal -c populate_sdk_ext > > > > eSDK installed via: poky-glibc-x86_64-core-image-minimal- > > cortexa15t2hf- > > neon-qemuarm-toolchain-ext-4.1+snapshot.sh > > > > . environment-setup-cortexa15t2hf-neon-poky-linux-gnueabi > > devtool modify busybox > > > > Sstate summary: Wanted 14 Local 0 Mirrors 0 Missed 14 Current 6 (0% > > match, 30% complete) > > > > So it started a compilation of missing components. We are assuming, > > that eSDK will include all build deps for all components in the > > image > > and not just a deps for image itself. > > Ok. To confirm, SDK_EXT_TYPE is set to full in both cases? Could you > share the locked-sigs.inc file from both? I'd like to understand if > the > tools are there but not being used or whether they're really not > there > at all. Is there much of a size difference between the two eSDKs? > > I suspect some kind of bisection to track down the change causing the > issue will be necessary unfortunately but at least that test case is > relatively straightforward... > > Cheers, > > Richard > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167370): https://lists.openembedded.org/g/openembedded-core/message/167370 Mute This Topic: https://lists.openembedded.org/mt/92019337/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] eSDK dependencies
Hello Richard and Alex, Richard: We tried to revert the commits which you mentioned and it didn't work. Alex: Yes, is fully reproducible on latest master. bitbake core-image-minimal -c populate_sdk_ext eSDK installed via: poky-glibc-x86_64-core-image-minimal-cortexa15t2hf- neon-qemuarm-toolchain-ext-4.1+snapshot.sh . environment-setup-cortexa15t2hf-neon-poky-linux-gnueabi devtool modify busybox Sstate summary: Wanted 14 Local 0 Mirrors 0 Missed 14 Current 6 (0% match, 30% complete) So it started a compilation of missing components. We are assuming, that eSDK will include all build deps for all components in the image and not just a deps for image itself. Regards, Andrej On Mon, 2022-06-27 at 14:35 +0100, Richard Purdie wrote: > On Mon, 2022-06-27 at 12:32 +, Valek, Andrej wrote: > > I have a question related to eSDK dependencies. We're using the > > dunfell > > branch were everything related to this eSDK topic works fine. Now > > we're > > in the transition phase to new LTS branch, where were we found one > > big > > difference between eSDKs. > > > > The old variant (dunfell) includes all application build > > dependencies, > > but the new variant (kirkstone/master) doesn't. Means if I > > installed > > the eSDK and used "devtool modify my-app" (application installed on > > the > > image) it works without any additional build deps recompilation. > > But now, if I do the same on the newer version it always recompile > > all > > build deps. > > I was already looked, what could be changed, but I didn't find so > > far > > something suspicious. So the question is, what has been changed, > > and > > how to bring the old variant back? > > Guessing is hard. Since you're asking me to guess: > > https://git.yoctoproject.org/poky/commit/?id=568f62214bca3ac6d35eef8d9f4562596fb4c9ab > > which was partially reverted here: > > https://git.yoctoproject.org/poky/commit/?id=f22e1fbdf7bed111e080d176fe5a39c5139308ed > > maybe? It could be something else. It wasn't a specific change to > remove such dependencies but I suspect it could have happened as an > unforeseen side effect of something else. > > You may need to come up with a simple test case and then bisect > between > the two releases to see which change it was. Once we understand what > change caused it, working out a solution would be easier, it is > premature to even try without knowing the cause. > > Cheers, > > Richard > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167333): https://lists.openembedded.org/g/openembedded-core/message/167333 Mute This Topic: https://lists.openembedded.org/mt/92019337/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] eSDK dependencies
Hello Richard! I have a question related to eSDK dependencies. We're using the dunfell branch were everything related to this eSDK topic works fine. Now we're in the transition phase to new LTS branch, where were we found one big difference between eSDKs. The old variant (dunfell) includes all application build dependencies, but the new variant (kirkstone/master) doesn't. Means if I installed the eSDK and used "devtool modify my-app" (application installed on the image) it works without any additional build deps recompilation. But now, if I do the same on the newer version it always recompile all build deps. I was already looked, what could be changed, but I didn't find so far something suspicious. So the question is, what has been changed, and how to bring the old variant back? Many thanks, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167319): https://lists.openembedded.org/g/openembedded-core/message/167319 Mute This Topic: https://lists.openembedded.org/mt/92019337/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] kernel: add missing path to search for debug files
ping
On Mon, 2022-01-24 at 08:19 +, Andrej Valek via
lists.openembedded.org wrote:
> Hello Richard,
>
> Fine, that we have it, but are you going to take a look on the patch
> :)
> ?
>
> Regards,
> Andrej
>
> On Fri, 2022-01-21 at 10:18 +0100, Michael Opdenacker wrote:
> >
> > On 1/19/22 5:48 PM, Richard Purdie wrote:
> > > On Wed, 2022-01-19 at 12:57 +0100, Andrej Valek wrote:
> > > > Since explicit debug package creation via
> > > > ${KERNEL_PACKAGE_NAME}-
> > > > dbg has
> > > > been added to kernel, it has to cover all
> > > > PACKAGE_DEBUG_SPLIT_STYLE
> > > > options. For ex. when the variable "debug-file-directory"
> > > > package
> > > > search
> > > > path has to be set explicitly, otherwise it will not find any
> > > > files.
> > > >
> > > > Signed-off-by: Andrej Valek
> > > > ---
> > > > meta/classes/kernel.bbclass | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/meta/classes/kernel.bbclass
> > > > b/meta/classes/kernel.bbclass
> > > > index 473e28be47..9ea201c936 100644
> > > > --- a/meta/classes/kernel.bbclass
> > > > +++ b/meta/classes/kernel.bbclass
> > > > @@ -647,6 +647,7 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > > FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map*
> > > > /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH}
> > > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > > FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-
> > > > ${KERNEL_VERSION_NAME}"
> > > > FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > +FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug
> > > > /usr/src/debug"
> > > This seems to highlight that we have no tests for
> > > KERNEL_PACKAGE_NAME. At the
> > > very least we need a bugzilla entry for creating some...
> >
> >
> > Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14700
> > Cheers
> > Michael
> >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165534):
https://lists.openembedded.org/g/openembedded-core/message/165534
Mute This Topic: https://lists.openembedded.org/mt/88532225/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] copy_buildsystem: allow more layer paths
Hi Daniel, thanks for the explanation. To be honest, when I was dealing with the layer structure, I didn't take a case about the layer outside of "work" directory. Basically it's the same as mine, but respect the external layers outside of work, right? So, your proposal makes sense to me. layers ├── meta-my-layer ├── meta-openembedded │ ├── meta-networking │ └── meta-oe └── poky └── meta Forget about the last variant. We don't want to remove the layer structure. Regards, Andrej On Fri, 2022-03-04 at 10:26 +0100, Daniel Wagenknecht wrote: > Hello Andrej, > > On Thu, 2022-03-03 at 06:35 +, Andrej Valek wrote: > > Hi Daniel, > > > > Could you please give here the examples how the layer structure looks > > before and after change? I want to see how transformation looks like. > > With a directory-structure like > > / > ├── repo > │ └── layers > │ └── meta-my-layer > └── work > ├── build > └── layers > └── external > ├── meta-openembedded > │ ├── meta-networking > │ └── meta-oe > └── poky > └── meta > > and > > # Set through bitbake itself > COREBASE = "/work/layers/external/poky" > TOPDIR = "/work/build" > # Set in bblayers.conf > BBLAYERS = " \ > /repo/layers/meta-my-layer \ > /work/layers/external/meta-openembedded/meta-networking \ > /work/layers/external/meta-openembedded/meta-oe \ > /work/layers/external/poky/meta" > > The resulting eSDK layers directory will look like this: > > . > ├── meta-my-layer > ├── meta-openembedded > │ ├── meta-networking > │ └── meta-oe > └── poky > └── meta > > Without this patch the /repo/meta-my-layer layer broke the build: > > > This patch resolves issues like > > > ERROR: my-image-1.0-r0 do_populate_sdk_ext: Failed to generate > > > filtered task list for extensible SDK: > > > > > > ### Shell environment set up for builds. ### > > > [...] > > > > > > ERROR: bitbake failed: > > > ERROR: The following layer directories do not exist: > > > ERROR: /build/tmp/work/my-board-linux/my-image/1.0-r0/sdk- > > > ext/image/tmp-renamed-sdk/layers/../../../repo/layers/meta-my-layer > > > ERROR: Please check BBLAYERS in /build/tmp/work/my-board- > > > linux/my- > > > image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf > > > ERROR: Logfile of failure stored in: /build/tmp/work/my-board- > > > linux/my-image/1.0-r0/temp/log.do_populate_sdk_ext.68844 > > > > > Without meta-my-layer this patch should not cause any change. > > The alternative > > > Alternative to this patch: > > > Delete the whole else / elseif block. This would lead to a layer > > > structure in > > > the eSDK like > > > layers/poky/meta > > > layers/meta-networking > > > layers/meta-oe > > > thus flattening the layer tree. > would remove the special casing in the implementation (except for > COREBASE > sublayers), thus resulting in the following layer structure in the > eSDKs layers > directory: > > . > ├── meta-my-layer > ├── meta-networking > ├── meta-oe > └── poky > └── meta > > -- > Sincerely > Daniel Wagenknecht > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#162713): https://lists.openembedded.org/g/openembedded-core/message/162713 Mute This Topic: https://lists.openembedded.org/mt/89508969/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] copy_buildsystem: allow more layer paths
Hi Daniel,
Could you please give here the examples how the layer structure looks
before and after change? I want to see how transformation looks like.
Regards,
Andrej
On Wed, 2022-03-02 at 20:05 +0100, Daniel Wagenknecht wrote:
> Layers could be located anywhere. The eSDK should work with them even
> if
> they are not located in TOPDIR or in the same parent directory as
> COREBASE.
>
> For layers located in the same parent directory as COREBASE this
> preserves
> the intent from the previous
> copy_buildsystem: include layer tree during build structure
> creation
> commit.
>
> Related OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b
>
> Signed-off-by: Daniel Wagenknecht
> ---
> This patch resolves issues like
> ERROR: my-image-1.0-r0 do_populate_sdk_ext: Failed to generate
> filtered task list for extensible SDK:
>
> ### Shell environment set up for builds. ###
> [...]
>
> ERROR: bitbake failed:
> ERROR: The following layer directories do not exist:
> ERROR: /build/tmp/work/my-board-linux/my-image/1.0-r0/sdk-
> ext/image/tmp-renamed-sdk/layers/../../../repo/layers/meta-my-layer
> ERROR: Please check BBLAYERS in /build/tmp/work/my-board-linux/my-
> image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf
> ERROR: Logfile of failure stored in: /build/tmp/work/my-board-
> linux/my-image/1.0-r0/temp/log.do_populate_sdk_ext.68844
>
> I tried to preserve the special casing to preserve the layer tree
> e.g. get the
> following layer-structure in the eSDK:
> layers/poky/meta
> layers/meta-openembedded/meta-networking
> layers/meta-openembedded/meta-oe
> For layers that are not located in a directory tree right next to
> COREBASE we
> don't have an anchor to determine what part of the layer tree we
> should keep,
> thus the layer tree will be flattened.
>
> Alternative to this patch:
> Delete the whole else / elseif block. This would lead to a layer
> structure in
> the eSDK like
> layers/poky/meta
> layers/meta-networking
> layers/meta-oe
> thus flattening the layer tree. I'm personally not opposed to this
> approach,
> but both 5a59a6997f41e606d088e3e86812de56f72f543b and
> 55ecf6988d3e3c0935cb6324a6ad2c75f1191a1d (OE-Core) show that there
> seems to be
> a need / preference for keeping the layer tree.
>
>
> meta/lib/oe/copy_buildsystem.py | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/meta/lib/oe/copy_buildsystem.py
> b/meta/lib/oe/copy_buildsystem.py
> index d97bf9d1b9..79642fd76a 100644
> --- a/meta/lib/oe/copy_buildsystem.py
> +++ b/meta/lib/oe/copy_buildsystem.py
> @@ -45,9 +45,6 @@ class BuildSystem(object):
>
> corebase = os.path.abspath(self.d.getVar('COREBASE'))
> layers.append(corebase)
> - # Get relationship between TOPDIR and COREBASE
> - # Layers should respect it
> - corebase_relative =
> os.path.dirname(os.path.relpath(os.path.abspath(self.d.getVar('TOPDIR
> ')), corebase))
> # The bitbake build system uses the meta-skeleton layer as a
> layout
> # for common recipies, e.g: the recipetool script to create
> kernel recipies
> # Add the meta-skeleton layer to be included as part of the
> eSDK installation
> @@ -100,11 +97,10 @@ class BuildSystem(object):
> layerdestpath = destdir
> if corebase == os.path.dirname(layer):
> layerdestpath += '/' + os.path.basename(corebase)
> - else:
> - layer_relative = os.path.relpath(layer, corebase)
> - if os.path.dirname(layer_relative) ==
> corebase_relative:
> - layer_relative =
> os.path.dirname(corebase_relative) + '/' + layernewname
> - layer_relative = os.path.basename(corebase) + '/' +
> layer_relative
> + # If the layer is located somewhere under the same
> parent directory
> + # as corebase we keep the layer structure.
> + elif os.path.commonpath([layer, corebase]) ==
> os.path.dirname(corebase):
> + layer_relative = os.path.relpath(layer,
> os.path.dirname(corebase))
> if os.path.dirname(layer_relative) != layernewname:
> layerdestpath += '/' +
> os.path.dirname(layer_relative)
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162635):
https://lists.openembedded.org/g/openembedded-core/message/162635
Mute This Topic: https://lists.openembedded.org/mt/89508969/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "featimage: refactor style"
Hello Marek,
I think, we have to stop the discussion now, because it is not leading
into any conclusion. Anyway, both of us have a different opinion.
Maybe rewriting into python will solve it, I won't do that.
Cheers,
Andrej
On Wed, 2022-02-02 at 09:17 +0100, Marek Vasut wrote:
> On 2/2/22 07:51, Valek, Andrej wrote:
> > Marek,
>
> Hello Andrej,
>
> > Sorry, but these are still not an arguments, why to do that.
>
> I'm sorry, I am lost and confused ... what part of the email are you
> referring to ?
>
> > On Mon, 2022-01-31 at 10:39 +0100, Marek Vasut wrote:
> > > On 1/31/22 08:01, Valek, Andrej wrote:
> > > > Hi,
> > >
> > > Hello Andrej,
> > >
> > > (please avoid top-posting)
> > >
> > > > Sorry, but personally I don't like your idea. What's the
> > > > benefit of
> > > > reverting this? I would keep the ${} for bitbake and $ for
> > > > shell. The
> > > > {} has to be placed only for variables like $a${b}c.
> > >
> > > That's exactly the benefit of using ${} in shell scripts
> > > consistently -
> > > -
> > > you don't have to worry about variable names being accidentally
> > > conflated with surrounding strings, either due to your own
> > > mistake, or
> > > some automated transformation that was applied incorrectly .
> > >
> > > > We should respect the workflow on all recipes otherwise we're
> > > > braking
> > > > the "unwritten" rules.
> > >
> > > The workflow on all recipes ? What does this mean ?
> > >
> > > broken by people. Better update the documentation.
> > >
> > > There is one technical counter-argument to this revert from
> > > Peter,
> > > quote:
> > > "
> > > There is actually a technical reason to not use ${foo} for shell
> > > variables unless necessary in bitbake files and it is because
> > > bitbake will treat them all as potential bitbake variables. This
> > > means they are unnecessarily included in the taskhashes that
> > > bitbake calculates.
> > > "
> > >
> > > But the patch being reverted here addresses the problem only
> > > partly,
> > > because it still contains remnants like this:
> > > "
> > > conf_desc="$conf_desc${sep}setup"
> > > "
> > Just for your information, this is not remnants, this is exactly
> > the
> > right {} usage. If you didn't place the {}, it will be
> > conf_desc="$conf_desc$sepsetup", which doesn't make any sense.
>
> OK, one more time then.
>
> Either your patch attempted to change the coding style of this script
> to
> match your personal preference, and did it only partly, so the result
> is
> inconsistent.
>
> Or
>
> You were fixing the aforementioned taskhash issue, in which case the
> taskhash issue is also fixed only partly.
>
> The commit message is not clear on what the intention was.
>
> [...]
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161187):
https://lists.openembedded.org/g/openembedded-core/message/161187
Mute This Topic: https://lists.openembedded.org/mt/88758521/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "featimage: refactor style"
Marek,
Sorry, but these are still not an arguments, why to do that.
On Mon, 2022-01-31 at 10:39 +0100, Marek Vasut wrote:
> On 1/31/22 08:01, Valek, Andrej wrote:
> > Hi,
>
> Hello Andrej,
>
> (please avoid top-posting)
>
> > Sorry, but personally I don't like your idea. What's the benefit of
> > reverting this? I would keep the ${} for bitbake and $ for shell. The
> > {} has to be placed only for variables like $a${b}c.
>
> That's exactly the benefit of using ${} in shell scripts consistently -
> -
> you don't have to worry about variable names being accidentally
> conflated with surrounding strings, either due to your own mistake, or
> some automated transformation that was applied incorrectly .
>
> > We should respect the workflow on all recipes otherwise we're braking
> > the "unwritten" rules.
>
> The workflow on all recipes ? What does this mean ?
>
> broken by people. Better update the documentation.
>
> There is one technical counter-argument to this revert from Peter,
> quote:
> "
> There is actually a technical reason to not use ${foo} for shell
> variables unless necessary in bitbake files and it is because
> bitbake will treat them all as potential bitbake variables. This
> means they are unnecessarily included in the taskhashes that
> bitbake calculates.
> "
>
> But the patch being reverted here addresses the problem only partly,
> because it still contains remnants like this:
> "
> conf_desc="$conf_desc${sep}setup"
> "
Just for your information, this is not remnants, this is exactly the
right {} usage. If you didn't place the {}, it will be
conf_desc="$conf_desc$sepsetup", which doesn't make any sense.
>
> [...]
>
> > > > > third alternative ? I mean, besides rewriting the fitimage
> > > > > generation into python, which might make it more flexible too.
> > > >
> > > > Replacing shell code that has grown beyond a couple of hundred
> > > > (tens?) lines with something written in a better language is
> > > > almost always a good idea.
> > >
> > > It's grown to almost 800 LoC, so maybe it is time to reevaluate the
> > > python conversion then.
>
> So a rewrite into something more suitable might be a good idea ^ ,
> probably python in this case.
But anyway, if you want to do that, then do not forget for other kernel
classes, where the same commits have been applied by someone else.
So from my point of view, it has to stay like it is.
Cheers,
Andrej
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161178):
https://lists.openembedded.org/g/openembedded-core/message/161178
Mute This Topic: https://lists.openembedded.org/mt/88758521/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] dhcpcd: add option to set DBDIR location
This will allow to use the different DBDIR location, because the /var/lib
could be used as a read-only location.
Signed-off-by: Andrej Valek
---
meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
index 4007a4bd2d..ab6ffe986c 100644
--- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
+++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
@@ -32,8 +32,11 @@ PACKAGECONFIG[ntp] = "--with-hook=ntp, , ,ntp"
PACKAGECONFIG[chrony] = "--with-hook=ntp, , ,chrony"
PACKAGECONFIG[ypbind] = "--with-eghook=yp, , ,ypbind-mt"
+# add option to override DBDIR location
+DBDIR ?= "${localstatedir}/lib/${BPN}"
+
EXTRA_OECONF = "--enable-ipv4 \
---dbdir=${localstatedir}/lib/${BPN} \
+--dbdir=${DBDIR} \
--sbindir=${base_sbindir} \
--runstatedir=/run \
--enable-privsep \
@@ -43,15 +46,15 @@ EXTRA_OECONF = "--enable-ipv4 \
"
USERADD_PACKAGES = "${PN}"
-USERADD_PARAM:${PN} = "--system -d ${localstatedir}/lib/${BPN} -M -s
/bin/false -U dhcpcd"
+USERADD_PARAM:${PN} = "--system -d ${DBDIR} -M -s /bin/false -U dhcpcd"
do_install:append () {
# install systemd unit files
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/dhcpcd*.service ${D}${systemd_system_unitdir}
-chmod 700 ${D}${localstatedir}/lib/${BPN}
-chown dhcpcd:dhcpcd ${D}${localstatedir}/lib/${BPN}
+chmod 700 ${D}${DBDIR}
+chown dhcpcd:dhcpcd ${D}${DBDIR}
}
FILES:${PN}-dbg += "${libdir}/dhcpcd/dev/.debug"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161157):
https://lists.openembedded.org/g/openembedded-core/message/161157
Mute This Topic: https://lists.openembedded.org/mt/88834745/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "featimage: refactor style"
Hi,
Sorry, but personally I don't like your idea. What's the benefit of
reverting this? I would keep the ${} for bitbake and $ for shell. The
{} has to be placed only for variables like $a${b}c.
We should respect the workflow on all recipes otherwise we're braking
the "unwritten" rules.
Regards,
Andrej
On Sat, 2022-01-29 at 03:36 +0100, Marek Vasut wrote:
> On 1/29/22 03:01, Peter Kjellerstedt wrote:
>
> Hi,
>
> [...]
>
> > Personally I do not see it as inconsistent, it is just the way
> > shell handles variables. It is just something to get used to (I
> > also had a colleague who would review any shell code changes we
> > made and comment on every single unnecessary character so one
> > quickly learned to use $foo everywhere possible rather than
> > ${foo}...)
>
> quickly start putting the {} everywhere. That's my case.
>
> (we should likely stop this ^ discussion thread before it turns into
> a
> flamewar)
>
> > That said, I have never looked at this code so I
> > have no real idea of how bad it is or isn't.
>
> This patch lists pretty much all the vars, so you can get a pretty
> decent idea from just looking at that.
>
> > > third alternative ? I mean, besides rewriting the fitimage
> > > generation into python, which might make it more flexible too.
> >
> > Replacing shell code that has grown beyond a couple of hundred
> > (tens?) lines with something written in a better language is
> > almost always a good idea.
>
> It's grown to almost 800 LoC, so maybe it is time to reevaluate the
> python conversion then.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161117):
https://lists.openembedded.org/g/openembedded-core/message/161117
Mute This Topic: https://lists.openembedded.org/mt/88758521/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Hello Bryan, So looks like, there is some kind of problem. Was you able to run the busybox command after upgrade like, "busybox ls /" ? - If yes, there is a problem, that update alternatives hasn't been processed correctly. Try direct command after reboot, if possible - If no, lets continue with patch creation based on the master branch Cheers, Andrej On Thu, 2022-01-27 at 14:39 +, Bryan Evenson wrote: > Andrej, > > > -Original Message- > > From: Valek, Andrej > > Sent: Saturday, January 22, 2022 2:26 AM > > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary > > busybox > > links during install > > > > Hello again, > > > > Maybe a general question. Is it working in current master? I do not > > want to > > brake dunfell, just applying something, which will create a lot of > > divergence. > > > > I wasn't able to build an image based on the latest master as of > Monday. From the error messages I think it had something to do with > the addition of setuptools3-base that wasn't complete yet. I was > able to build and run an image based on the latest honister branch. > The master branch has four commits for busybox that honsiter does not > have. In those four commits, I see no changes to any of the > installation steps. Based on this information, I'd say its safe to > say that testing on the latest honister branch should confirm whether > the problem is still present or not. > > To test, I first built my image and directly programmed it on my > hardware. My image is based upon core-image-minimal, uses sysvinit > for an init system and opkg for a package manager. I have also added > bash, cronie, dhcpcd and util-linux to my image; I've added others > but these seem to produce the most obvious errors. > > After programming the image on my hardware, I added PR="r1" to the > gcc recipe. This forced all the packages to get rebuilt and > increment the version number (if anyone knows a simpler way to > accomplish this, let me know). I then created a package feed with > this update and attempted an upgrade. > > To upgrade, I did: > opkg update > opkg --download-only upgrade > opkg upgrade > full_upgrade.txt 2>&1 & > > I download all the packages to be upgraded first. I then sent the > upgrade process to the background so I could check other things > during the upgrade process. > > During the upgrade, I would occasionally execute "ls -l" to verify > that the file full_upgrade.txt existed and was still growing. About > a minute into the upgrade process when I executed "ls -l" I got the > error message: > > ls: not found > > From that point on until upgrade was complete I had to execute > "busybox ls -l" to see the current directory file list. After > upgrade was complete, I checked full_upgrade.txt for error messages. > I saw the following: > > /usr/bin/update-alternatives: line 1: sed: not found (occurred 102 > times) > /usr/sbin/update-rc.d: line 54: rm: not found (occurred 36 times) > Stopping crond: /etc/init.d/crond: line 37: start-stop-daemon: not > found > /tmp/opkg-yBH1Ta/cronie-zHpym4/preinst: line 1: tr: not found > /etc/init.d/udev: line 74: start-stop-daemon: not found > /tmp/opkg-yBH1Ta/dhcpcd-c86ca9/preinst: line 1: tr: not found > > In this case, a lot of alternatives and init scripts may not be setup > correctly because either the old ones were not removed or the new > ones were not installed. Prior to my patch below, I saw similar > errors when upgrading my image from a build based off the morty > branch to one based off dunfell (and my system was not operational > after the upgrade). After my patch, I performed the same upgrade > with no errors and my system was fully operational. > > I'm up for any thoughts on a different approach that accomplishes the > same goal. Otherwise, I'm going to work with what I have and update > my changes so they patch cleanly on master. > > Thanks, > Bryan > > > Cheers, > > Andrej > > > > On Fri, 2022-01-21 at 15:02 +, Bryan Evenson wrote: > > > Andrej, > > > > > > Thanks for the response. This is an attempt to fix a problem I > > > am > > > having with automated firmware upgrades for my system. I am > > > using > > > opkg for a package manager; not sure if the same problem exists > > > with > > > other package managers. I run into problems whenever busybox is > > > one > > > of the packages that needs to get updated. I enact my > > > distribution > > > firmware upgrade by calling "opkg --download-only upgrade; opkg > > > upgrade". What I see happen is: > > > > > > 1. In the busybox pkg_prerm stage sets up some soft links for > > > some > > > common applets in a temporary directory and exports a path to > > > that > > > directory. It might also setup a temporary alternative to > > > /bin/sh if > > > it is the last shell. > > > 2. After the remove stage, the busybox binary is gone. The > > > softlinks > > > created in the prerm
[OE-core][PATCH] oeqa: qemu: create missing directory for _write_dump
| Failed to dump QMP CMD: query-status with | Exception: [Errno 2] No such file or directory: '.../tmp/log/runtime-hostdump/qmp_00_query-status' | Failed to dump QMP CMD: query-block with | Exception: [Errno 2] No such file or directory: '.../tmp/log/runtime-hostdump/qmp_00_query-block' | Failed to dump QMP CMD: dump-guest-memory with | Exception: [Errno 2] No such file or directory: '.../tmp/log/runtime-hostdump/qmp_00_dump-guest-memory' The qmp dump commands could fail, because of missing root directory. So create it before any log writing. Signed-off-by: Andrej Valek --- meta/lib/oeqa/utils/dump.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oeqa/utils/dump.py b/meta/lib/oeqa/utils/dump.py index dc8757807e..95a79a571c 100644 --- a/meta/lib/oeqa/utils/dump.py +++ b/meta/lib/oeqa/utils/dump.py @@ -66,6 +66,7 @@ class BaseDumper(object): def _write_dump(self, command, output): fullname = self._construct_filename(command) +os.makedirs(os.path.dirname(fullname), exist_ok=True) if isinstance(self, MonitorDumper): with open(fullname, 'w') as json_file: json.dump(output, json_file, indent=4) -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161074): https://lists.openembedded.org/g/openembedded-core/message/161074 Mute This Topic: https://lists.openembedded.org/mt/88741618/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] kernel: add missing path to search for debug files
Hello Richard,
Fine, that we have it, but are you going to take a look on the patch :)
?
Regards,
Andrej
On Fri, 2022-01-21 at 10:18 +0100, Michael Opdenacker wrote:
>
> On 1/19/22 5:48 PM, Richard Purdie wrote:
> > On Wed, 2022-01-19 at 12:57 +0100, Andrej Valek wrote:
> > > Since explicit debug package creation via ${KERNEL_PACKAGE_NAME}-
> > > dbg has
> > > been added to kernel, it has to cover all
> > > PACKAGE_DEBUG_SPLIT_STYLE
> > > options. For ex. when the variable "debug-file-directory" package
> > > search
> > > path has to be set explicitly, otherwise it will not find any
> > > files.
> > >
> > > Signed-off-by: Andrej Valek
> > > ---
> > > meta/classes/kernel.bbclass | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/classes/kernel.bbclass
> > > b/meta/classes/kernel.bbclass
> > > index 473e28be47..9ea201c936 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -647,6 +647,7 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map*
> > > /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH}
> > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-
> > > ${KERNEL_VERSION_NAME}"
> > > FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > +FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug
> > > /usr/src/debug"
> > This seems to highlight that we have no tests for
> > KERNEL_PACKAGE_NAME. At the
> > very least we need a bugzilla entry for creating some...
>
>
> Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14700
> Cheers
> Michael
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160872):
https://lists.openembedded.org/g/openembedded-core/message/160872
Mute This Topic: https://lists.openembedded.org/mt/88532225/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] busybox: refresh defconfig
- extend find command
- disable rootfs skip
- busybox-inittab_1.34.1 -> busybox-inittab_1.35.0
Signed-off-by: Andrej Valek
---
...ab_1.34.1.bb => busybox-inittab_1.35.0.bb} | 0
meta/recipes-core/busybox/busybox/defconfig | 70 +++
2 files changed, 39 insertions(+), 31 deletions(-)
rename meta/recipes-core/busybox/{busybox-inittab_1.34.1.bb =>
busybox-inittab_1.35.0.bb} (100%)
diff --git a/meta/recipes-core/busybox/busybox-inittab_1.34.1.bb
b/meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
similarity index 100%
rename from meta/recipes-core/busybox/busybox-inittab_1.34.1.bb
rename to meta/recipes-core/busybox/busybox-inittab_1.35.0.bb
diff --git a/meta/recipes-core/busybox/busybox/defconfig
b/meta/recipes-core/busybox/busybox/defconfig
index 16c61a84b2..5e1e1f5638 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Busybox version: 1.34.0
-# Wed Aug 23 09:07:25 2021
+# Busybox version: 1.35.0
+# Sun Dec 26 16:55:55 2021
#
CONFIG_HAVE_DOT_CONFIG=y
@@ -94,9 +94,12 @@ CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SMALL=1
CONFIG_SHA3_SMALL=1
-CONFIG_FEATURE_FAST_TOP=y
-# CONFIG_FEATURE_ETC_NETWORKS is not set
-# CONFIG_FEATURE_ETC_SERVICES is not set
+CONFIG_FEATURE_NON_POSIX_CP=y
+# CONFIG_FEATURE_VERBOSE_CP_MESSAGE is not set
+CONFIG_FEATURE_USE_SENDFILE=y
+CONFIG_FEATURE_COPYBUF_KB=4
+CONFIG_MONOTONIC_SYSCALL=y
+CONFIG_IOCTL_HEX2STR_ERROR=y
CONFIG_FEATURE_EDITING=y
CONFIG_FEATURE_EDITING_MAX_LEN=1024
# CONFIG_FEATURE_EDITING_VI is not set
@@ -120,14 +123,6 @@ CONFIG_UNICODE_WIDE_WCHARS=y
# CONFIG_UNICODE_BIDI_SUPPORT is not set
# CONFIG_UNICODE_NEUTRAL_TABLE is not set
# CONFIG_UNICODE_PRESERVE_BROKEN is not set
-CONFIG_FEATURE_NON_POSIX_CP=y
-# CONFIG_FEATURE_VERBOSE_CP_MESSAGE is not set
-CONFIG_FEATURE_USE_SENDFILE=y
-CONFIG_FEATURE_COPYBUF_KB=4
-CONFIG_FEATURE_SKIP_ROOTFS=y
-CONFIG_MONOTONIC_SYSCALL=y
-CONFIG_IOCTL_HEX2STR_ERROR=y
-CONFIG_FEATURE_HWIB=y
#
# Applets
@@ -162,6 +157,8 @@ CONFIG_FEATURE_BZIP2_DECOMPRESS=y
CONFIG_CPIO=y
# CONFIG_FEATURE_CPIO_O is not set
# CONFIG_FEATURE_CPIO_P is not set
+# CONFIG_FEATURE_CPIO_IGNORE_DEVNO is not set
+# CONFIG_FEATURE_CPIO_RENUMBER_INODES is not set
# CONFIG_DPKG is not set
# CONFIG_DPKG_DEB is not set
CONFIG_GZIP=y
@@ -197,6 +194,22 @@ CONFIG_FEATURE_UNZIP_CDF=y
#
# Coreutils
#
+CONFIG_FEATURE_VERBOSE=y
+
+#
+# Common options for date and touch
+#
+# CONFIG_FEATURE_TIMEZONE is not set
+
+#
+# Common options for cp and mv
+#
+# CONFIG_FEATURE_PRESERVE_HARDLINKS is not set
+
+#
+# Common options for df, du, ls
+#
+CONFIG_FEATURE_HUMAN_READABLE=y
CONFIG_BASENAME=y
CONFIG_CAT=y
CONFIG_FEATURE_CATN=y
@@ -225,6 +238,7 @@ CONFIG_FEATURE_DD_SIGNAL_HANDLING=y
# CONFIG_FEATURE_DD_STATUS is not set
CONFIG_DF=y
# CONFIG_FEATURE_DF_FANCY is not set
+# CONFIG_FEATURE_SKIP_ROOTFS is not set
CONFIG_DIRNAME=y
# CONFIG_DOS2UNIX is not set
# CONFIG_UNIX2DOS is not set
@@ -343,21 +357,6 @@ CONFIG_USERS=y
CONFIG_WHOAMI=y
CONFIG_YES=y
-#
-# Common options
-#
-CONFIG_FEATURE_VERBOSE=y
-
-#
-# Common options for cp and mv
-#
-# CONFIG_FEATURE_PRESERVE_HARDLINKS is not set
-
-#
-# Common options for df, du, ls
-#
-CONFIG_FEATURE_HUMAN_READABLE=y
-
#
# Console Utilities
#
@@ -448,7 +447,11 @@ CONFIG_FEATURE_ALLOW_EXEC=y
CONFIG_FIND=y
CONFIG_FEATURE_FIND_PRINT0=y
CONFIG_FEATURE_FIND_MTIME=y
+CONFIG_FEATURE_FIND_ATIME=y
+CONFIG_FEATURE_FIND_CTIME=y
CONFIG_FEATURE_FIND_MMIN=y
+CONFIG_FEATURE_FIND_AMIN=y
+CONFIG_FEATURE_FIND_CMIN=y
CONFIG_FEATURE_FIND_PERM=y
CONFIG_FEATURE_FIND_TYPE=y
CONFIG_FEATURE_FIND_EXECUTABLE=y
@@ -456,6 +459,7 @@ CONFIG_FEATURE_FIND_XDEV=y
CONFIG_FEATURE_FIND_MAXDEPTH=y
CONFIG_FEATURE_FIND_NEWER=y
# CONFIG_FEATURE_FIND_INUM is not set
+CONFIG_FEATURE_FIND_SAMEFILE=y
CONFIG_FEATURE_FIND_EXEC=y
CONFIG_FEATURE_FIND_EXEC_PLUS=y
CONFIG_FEATURE_FIND_USER=y
@@ -851,6 +855,9 @@ CONFIG_FEATURE_IPV6=y
# CONFIG_FEATURE_UNIX_LOCAL is not set
CONFIG_FEATURE_PREFER_IPV4_ADDRESS=y
# CONFIG_VERBOSE_RESOLUTION_ERRORS is not set
+# CONFIG_FEATURE_ETC_NETWORKS is not set
+# CONFIG_FEATURE_ETC_SERVICES is not set
+CONFIG_FEATURE_HWIB=y
# CONFIG_FEATURE_TLS_SHA1 is not set
# CONFIG_ARP is not set
# CONFIG_ARPING is not set
@@ -1024,17 +1031,19 @@ CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -b"
#
# Mail Utilities
#
+CONFIG_FEATURE_MIME_CHARSET=""
# CONFIG_MAKEMIME is not set
# CONFIG_POPMAILDIR is not set
# CONFIG_FEATURE_POPMAILDIR_DELIVERY is not set
# CONFIG_REFORMIME is not set
# CONFIG_FEATURE_REFORMIME_COMPAT is not set
# CONFIG_SENDMAIL is not set
-CONFIG_FEATURE_MIME_CHARSET=""
#
# Process Utilities
#
+CONFIG_FEATURE_FAST_TOP=y
+# CONFIG_FEATURE_SHOW_THREADS is not set
CONFIG_FREE=y
CONFIG_FUSER=y
# CONFIG_IOSTAT is not set
@@ -1073,7 +1082,6 @@ CONFIG_FEATURE_TOP
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Hello again, Maybe a general question. Is it working in current master? I do not want to brake dunfell, just applying something, which will create a lot of divergence. Cheers, Andrej On Fri, 2022-01-21 at 15:02 +, Bryan Evenson wrote: > Andrej, > > Thanks for the response. This is an attempt to fix a problem I am > having with automated firmware upgrades for my system. I am using > opkg for a package manager; not sure if the same problem exists with > other package managers. I run into problems whenever busybox is one > of the packages that needs to get updated. I enact my distribution > firmware upgrade by calling "opkg --download-only upgrade; opkg > upgrade". What I see happen is: > > 1. In the busybox pkg_prerm stage sets up some soft links for some > common applets in a temporary directory and exports a path to that > directory. It might also setup a temporary alternative to /bin/sh if > it is the last shell. > 2. After the remove stage, the busybox binary is gone. The softlinks > created in the prerm stage are useless since they point to binary > that no longer exists. > 3. opkg continues with upgrade on other packages which may depend on > a command provided by busybox in a prerm, postrm, preinst or postinst > script. These upgrades then fail since the commands are no longer > available. > 4. The busybox upgrade completes, which may or may not complete > successfully. For what I am attempting, I am upgrading my system > from the morty branch to dunfell. I have util-linux on my system > which shares some alternatives with busybox. The util-linux upgrade > fails because it needs some busybox applets during its upgrade > process. Then the busybox upgrade fails because the final update- > alternatives doesn’t work; some files still exist that util-linux > couldn't remove during its upgrade that clash with busybox's > alternatives. > > After trying several ways to get my upgrade to work, I landed on the > approach below. I'm creating a temporary directory and copying the > busybox binary and the busybox.links files to that directory. I then > install an alternative for every applet for busybox listed in all of > its busybox.links files that points to the temporary copy of the > busybox binary. This means that any package that uses a busybox > applet during its install process should still work. Then during the > postinst step I am removing all the temporary alternative links. I > use the temporary busybox.links files for removing the alternative > links in case the upgraded busybox is now configured with a different > set of applets. > > This is a heavy handed approach, and it does extend the upgrade > process for me by a few minutes since it runs through update- > alternatives for busybox two more times. But, the approach works for > me and I think would be more resilient than past approaches. I tried > to mimic the existing code in my additions. If a more widescale > rewrite makes sense than that works for me also. > > Thanks, > Bryan > > > > -Original Message- > > From: Valek, Andrej > > Sent: Friday, January 21, 2022 9:01 AM > > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary > > busybox > > links during install > > > > Hi Bryan, > > > > Sorry, maybe I didn't fully understand the use-case. Are you trying > > to > > upgrade the busybox on demand? If yes, that is not a good idea. > > > > I'm little bit scary about doing "export PATH=$busybox_rmdir:$PATH" > > and > > creating a custom locks is not a good at all. > > > > Cheers, > > Andrej > > > > On Fri, 2022-01-21 at 13:29 +, Bryan Evenson wrote: > > > All, > > > > > > Ping on this RFC. It works for me, but I have a feeling there is > > > a > > > better way to do this. It still seems a little messy and could > > > probably be simplified for the same effect. > > > > > > Thanks, > > > Bryan > > > > > > > -Original Message- > > > > From: Bryan Evenson > > > > Sent: Thursday, December 23, 2021 9:50 AM > > > > To: openembedded-core@lists.openembedded.org > > > > Subject: [dunfell][PATCH RFC] busybox.inc: Create temporary > > > > busybox > > > > links during install > > > > > > > > Busybox upgrades sometimes fail, especially if there is a major > > > > distribution upgrade and all packages need to be updated. > > > > Success > > > > is highly dependent on the package upgrade order. > > > > > > > > Commit [1] attempts to ensure a shell is still present by > > > > adding an > > > > alternative to /bin/sh if busybox is the only shell. However, > > > > if > > > > busybox is not the only shell present and the other shells are > > > > upgrading, it may then be possible that all shells will be > > > > removed > > > > during the upgrade process. > > > > > > > > Commit [2] creates temporary symbolic links for all the busybox > > > > links during busybox's postinst step. However, this is too > > > > late in > > >
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Hi Bryan,
Sorry, maybe I didn't fully understand the use-case. Are you trying to
upgrade the busybox on demand? If yes, that is not a good idea.
I'm little bit scary about doing "export PATH=$busybox_rmdir:$PATH" and
creating a custom locks is not a good at all.
Cheers,
Andrej
On Fri, 2022-01-21 at 13:29 +, Bryan Evenson wrote:
> All,
>
> Ping on this RFC. It works for me, but I have a feeling there is a
> better way to do this. It still seems a little messy and could
> probably be simplified for the same effect.
>
> Thanks,
> Bryan
>
> > -Original Message-
> > From: Bryan Evenson
> > Sent: Thursday, December 23, 2021 9:50 AM
> > To: openembedded-core@lists.openembedded.org
> > Subject: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox
> > links
> > during install
> >
> > Busybox upgrades sometimes fail, especially if there is a major
> > distribution
> > upgrade and all packages need to be updated. Success is highly
> > dependent
> > on the package upgrade order.
> >
> > Commit [1] attempts to ensure a shell is still present by adding an
> > alternative
> > to /bin/sh if busybox is the only shell. However, if busybox is
> > not the only
> > shell present and the other shells are upgrading, it may then be
> > possible that
> > all shells will be removed during the upgrade process.
> >
> > Commit [2] creates temporary symbolic links for all the busybox
> > links during
> > busybox's postinst step. However, this is too late in the process
> > as some
> > packages attempt to use 'rm' and 'sed' after update-alternatives
> > removes
> > the old links and prior to when busybox's postinst step runs.
> >
> > This fix is similar to [2] but runs during the preinst step. For
> > opkg, this is the
> > first step that is guaranteed to run from the new package (prerm is
> > run from
> > the old package) and will therefore be a backwards-compatible fix
> > for
> > upgrading older systems.
> >
> > Copies the existing busybox binary and the busybox.links files to a
> > temporary
> > directory and then creates alternative links for all installed
> > busybox
> > commands. The temporary links and directory are cleaned up during
> > the
> > postinst step.
> >
> > RFC: This works for me, but there may be room for improvement. I
> > don't
> > know if the current pkg_prerm steps are necessary anymore.
> > However, in
> > my testing I did need the links for update-alternatives to work in
> > the preinst
> > step. I am also not certain if the
> > populate_packages_updatealternatives_append
> > step is necessary anymore. I have also only tested this fix on
> > dunfell, as I
> > don't have a working image based on master yet. It may be more
> > appropriate for this to go to master and then be backported to
> > dunfell, but I
> > would need assistance in testing.
> >
> > [1] https://git.openembedded.org/openembedded-
> > core/commit/meta/recipes-
> > core/busybox/busybox.inc?id=a9d2af8f5b3da8239cf00a52883ca596a19ea23
> > a
> > [2] https://git.openembedded.org/openembedded-
> > core/commit/meta/recipes-
> > core/busybox/busybox.inc?id=3a035bd0a06a6ded4d0ce7e35a3bce42245727
> > d2
> >
> > Signed-off-by: Bryan Evenson
> > ---
> > meta/recipes-core/busybox/busybox.inc | 57
> > ++-
> > 1 file changed, 55 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
> > core/busybox/busybox.inc
> > index e0522be729..c85402411b 100644
> > --- a/meta/recipes-core/busybox/busybox.inc
> > +++ b/meta/recipes-core/busybox/busybox.inc
> > @@ -441,12 +441,28 @@ pkg_postinst_${PN}_prepend () { }
> >
> > pkg_postinst_${PN}_append () {
> > - # If busybox exists in the remove directory it is because
> > it was the only
> > shell left.
> > if [ "x$D" = "x" ] ; then
> > + # If busybox exists in the remove directory it is
> > because it was the only
> > shell left.
> > if [ "x$BUSYBOX" != "x" ] ; then
> > update-alternatives --remove sh $BUSYBOX
> > - rm -f $BUSYBOX
> > fi
> > + # Remove the temporary alternatives
> > + for busybox_preinstdir in /tmp/busyboxpreinst-*; do
> > + if [ "$busybox_preinstdir" != '/tmp/busyboxpreinst-
> > *' ] ; then
> > + BUSYBOX_PREINST_DIR="$busybox_preinstdir"
> > + BUSYBOX="$BUSYBOX_PREINST_DIR/busybox"
> > + if [ -e $BUSYBOX ] ; then
> > + for suffix in "" ".nosuid" ".suid"; do
> > + if [ -e
> > $BUSYBOX_PREINST_DIR/busybox.links$suffix ] ; then
> > + while read link; do
> > + update-alternatives --remove
> > $($BUSYBOX basename
> > $link) $BUSYBOX
> > + done <
> > $BUSYBOX_PREINST_DIR/busybox.links$suffix
> > + fi
> > + done
> > + fi
> > +
Re: [OE-core] qemu tests
Hello Richard, Thanks for the response. In other words, take a care about your machine by yourself => no other pending questions... ;) . Regards Andrej On Fri, 2022-01-21 at 11:36 +, Richard Purdie wrote: > On Fri, 2022-01-21 at 11:32 +, Valek, Andrej wrote: > > Hi all, > > > > I have a generic question about testimage task. Currently > > 'TESTIMAGEDEPENDS:append:qemuall = " qemu- > > native:do_populate_sysroot > > qemu-helper-native:do_populate_sysroot qemu-helper- > > native:do_addto_recipe_sysroot"' means that no other machine then > > qemu* > > has the feature available. So when "rm_work" is enabled and '-c > > testimage' is going to be run, ti fail, because sysroot-native > > stuff is > > not available. Does it means, that I have to add the those content > > to > > my not-qemu machine, or it's a feature? > > > > Maybe it could be transferred into variable like: > > "TESTIMAGEDEPENDS_qemu" and then I can it assign to my machine as > > well. > > > > How to deal with that? > > The qemu machines are by definition able to run under qemu but we > have no such > guarantees about any other machine. If they are able to, even then we > don't know > what dependencies they might have and if the ones above are correct > or not. > > I guess it could be abstracted but I'm not thrilled at the idea. The > suggested > name above is certainly doesn't look right to me. > > Cheers, > > Richard > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160820): https://lists.openembedded.org/g/openembedded-core/message/160820 Mute This Topic: https://lists.openembedded.org/mt/88580938/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] qemu tests
Hi all, I have a generic question about testimage task. Currently 'TESTIMAGEDEPENDS:append:qemuall = " qemu-native:do_populate_sysroot qemu-helper-native:do_populate_sysroot qemu-helper- native:do_addto_recipe_sysroot"' means that no other machine then qemu* has the feature available. So when "rm_work" is enabled and '-c testimage' is going to be run, ti fail, because sysroot-native stuff is not available. Does it means, that I have to add the those content to my not-qemu machine, or it's a feature? Maybe it could be transferred into variable like: "TESTIMAGEDEPENDS_qemu" and then I can it assign to my machine as well. How to deal with that? Regards, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#160817): https://lists.openembedded.org/g/openembedded-core/message/160817 Mute This Topic: https://lists.openembedded.org/mt/88580938/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] kernel: add missing path to search for debug files
Since explicit debug package creation via ${KERNEL_PACKAGE_NAME}-dbg has
been added to kernel, it has to cover all PACKAGE_DEBUG_SPLIT_STYLE
options. For ex. when the variable "debug-file-directory" package search
path has to be set explicitly, otherwise it will not find any files.
Signed-off-by: Andrej Valek
---
meta/classes/kernel.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 473e28be47..9ea201c936 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -647,6 +647,7 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers*
/boot/config* ${KERNEL_SRC_PATH}
${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
FILES:${KERNEL_PACKAGE_NAME}-modules = ""
+FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (=
${EXTENDPKGV})"
# Allow machines to override this dependency if kernel image files are
# not wanted in images as standard
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160734):
https://lists.openembedded.org/g/openembedded-core/message/160734
Mute This Topic: https://lists.openembedded.org/mt/88532225/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v4 2/2] kernel-fitimage: use correct kernel image
Even if initramfs_bundle_path was used, a wrong compression was reflected
in output its template file. Use linux.bin as universal kernel image.
The linux.bin file covers both cases because it's beying created from
vmlinux.
We know, that vmlinux is created inside compressed directory already,
so no external compression will be used.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17 +
meta/lib/oeqa/selftest/cases/fitimage.py | 8
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 886ed13029..8718ce7e16 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -495,22 +495,7 @@ fitimage_assemble() {
fitimage_emit_section_maint $1 imagestart
uboot_prep_kimage
-
- if [ "${INITRAMFS_IMAGE_BUNDLE}" = "1" ]; then
-
initramfs_bundle_path="arch/"${UBOOT_ARCH}"/boot/"${KERNEL_IMAGETYPE_REPLACEMENT}".initramfs"
- if [ -e "$initramfs_bundle_path" ]; then
-
- #
- # Include the kernel/rootfs bundle.
- #
-
- fitimage_emit_section_kernel $1 $kernelcount
"$initramfs_bundle_path" "$linux_comp"
- else
- bbwarn "$initramfs_bundle_pat not found."
- fi
- else
- fitimage_emit_section_kernel $1 $kernelcount linux.bin
"$linux_comp"
- fi
+ fitimage_emit_section_kernel $1 $kernelcount linux.bin "$linux_comp"
#
# Step 2: Prepare a DTB image section
diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py
b/meta/lib/oeqa/selftest/cases/fitimage.py
index 184c8778d2..f6f6a8e795 100644
--- a/meta/lib/oeqa/selftest/cases/fitimage.py
+++ b/meta/lib/oeqa/selftest/cases/fitimage.py
@@ -742,6 +742,7 @@ UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_EXTLINUX = "0"
FIT_GENERATE_KEYS = "1"
KERNEL_IMAGETYPE_REPLACEMENT = "zImage"
+FIT_KERNEL_COMP_ALG = "none"
FIT_HASH_ALG = "sha256"
"""
self.write_config(config)
@@ -763,9 +764,8 @@ FIT_HASH_ALG = "sha256"
kernel_load = str(get_bb_var('UBOOT_LOADADDRESS'))
kernel_entry = str(get_bb_var('UBOOT_ENTRYPOINT'))
-initramfs_bundle_format =
str(get_bb_var('KERNEL_IMAGETYPE_REPLACEMENT'))
+kernel_compression = str(get_bb_var('FIT_KERNEL_COMP_ALG'))
uboot_arch = str(get_bb_var('UBOOT_ARCH'))
-initramfs_bundle = "arch/" + uboot_arch + "/boot/" +
initramfs_bundle_format + ".initramfs"
fit_hash_alg = str(get_bb_var('FIT_HASH_ALG'))
its_file = open(fitimage_its_path)
@@ -775,11 +775,11 @@ FIT_HASH_ALG = "sha256"
exp_node_lines = [
'kernel-1 {',
'description = "Linux kernel";',
-'data = /incbin/("' + initramfs_bundle + '");',
+'data = /incbin/("linux.bin");',
'type = "kernel";',
'arch = "' + uboot_arch + '";',
'os = "linux";',
-'compression = "none";',
+'compression = "' + kernel_compression + '";',
'load = <' + kernel_load + '>;',
'entry = <' + kernel_entry + '>;',
'hash-1 {',
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157020):
https://lists.openembedded.org/g/openembedded-core/message/157020
Mute This Topic: https://lists.openembedded.org/mt/86378697/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v4 1/2] featimage: refactor style
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose
Signed-off-by: Andrej Valek
---
meta/classes/kernel-fitimage.bbclass | 297 ++-
meta/classes/uboot-sign.bbclass | 56 ++---
2 files changed, 178 insertions(+), 175 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 38e05153e3..886ed13029 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
#
# $1 ... .its filename
fitimage_emit_fit_header() {
- cat << EOF >> ${1}
+ cat << EOF >> $1
/dts-v1/;
/ {
@@ -94,24 +94,24 @@ EOF
fitimage_emit_section_maint() {
case $2 in
imagestart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
images {
EOF
;;
confstart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
configurations {
EOF
;;
sectend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
fitend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
@@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print "0x"$1;exit}'`
fi
- cat << EOF >> ${1}
-kernel-${2} {
+ cat << EOF >> $1
+kernel-$2 {
description = "Linux kernel";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "kernel";
arch = "${UBOOT_ARCH}";
os = "linux";
-compression = "${4}";
+compression = "$4";
load = <${UBOOT_LOADADDRESS}>;
-entry = <${ENTRYPOINT}>;
+entry = <$ENTRYPOINT>;
hash-1 {
-algo = "${kernel_csum}";
+algo = "$kernel_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${kernel_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "$kernel_sign_keyname" ] ; then
+ sed -i '$ d' $1
+ cat << EOF >> $1
signature-1 {
-algo = "${kernel_csum},${kernel_sign_algo}";
-key-name-hint = "${kernel_sign_keyname}";
+algo = "$kernel_csum,$kernel_sign_algo";
+key-name-hint = "$kernel_sign_keyname";
};
};
EOF
@@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
fi
- cat << EOF >> ${1}
-fdt-${2} {
+ cat << EOF >> $1
+fdt-$2 {
description = "Flattened Device Tree blob";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "flat_dt";
arch = "${UBOOT_ARCH}";
compression = "none";
-${dtb_loadline}
+$dtb_loadline
hash-1 {
-algo = "${dtb_csum}";
+algo = "$dtb_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${dtb_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}
[OE-core][dunfell][PATCH] libpsl: Add config knobs for runtime/builtin conversion choices
Based on d22d87b9c4ac85ffb3506e2acaf2a8a627f55e8e, but kept idn2 as default. Signed-off-by: Andrej Valek --- meta/recipes-support/libpsl/libpsl_0.21.0.bb | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/meta/recipes-support/libpsl/libpsl_0.21.0.bb b/meta/recipes-support/libpsl/libpsl_0.21.0.bb index b2dda191ce..66e64f785c 100644 --- a/meta/recipes-support/libpsl/libpsl_0.21.0.bb +++ b/meta/recipes-support/libpsl/libpsl_0.21.0.bb @@ -19,11 +19,10 @@ SRC_URI[sha256sum] = "41bd1c75a375b85c337b59783f5deb93dbb443fb0a52d257f403df7bd6 UPSTREAM_CHECK_URI = "https://github.com/rockdaboot/libpsl/releases; -DEPENDS = "libidn2" - inherit autotools gettext gtk-doc manpages pkgconfig lib_package -PACKAGECONFIG ??= "" +PACKAGECONFIG ?= "idn2" PACKAGECONFIG[manpages] = "--enable-man,--disable-man,libxslt-native" - +PACKAGECONFIG[icu] = "--enable-runtime=libicu --enable-builtin=libicu,,icu" +PACKAGECONFIG[idn2] = "--enable-runtime=libidn2 --enable-builtin=libidn2,,libidn2 libunistring" BBCLASSEXTEND = "native nativesdk" -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157016): https://lists.openembedded.org/g/openembedded-core/message/157016 Mute This Topic: https://lists.openembedded.org/mt/86377255/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] libpsl: Add config knobs for runtime/builtin conversion choices
Ok, but I've just copied the existing commit from master. So I have to send a different configuration for dunfell? Andrej On Fri, 2021-10-15 at 10:58 +0100, Richard Purdie wrote: > On Fri, 2021-10-15 at 06:15 +0000, Andrej Valek wrote: > > The reason, why I want to apply it here, to switch replace libidn2 > > with > > icu. According to libpsl documentation, you can chose who will > > generate > > the PSL database (libidn, libidn2, icu). So I don't want to install > > a > > new component if there is a valid replacement which is already > > installed. > > I think what Steve is suggesting is a tweaked version which doesn't > change the > current situation, just adds the PACKAGECONFIG options but doesn't > change the > current default. > > You could then change the configuration in your distro. > > Cheers, > > Richard > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156989): https://lists.openembedded.org/g/openembedded-core/message/156989 Mute This Topic: https://lists.openembedded.org/mt/86296104/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] libpsl: Add config knobs for runtime/builtin conversion choices
The reason, why I want to apply it here, to switch replace libidn2 with icu. According to libpsl documentation, you can chose who will generate the PSL database (libidn, libidn2, icu). So I don't want to install a new component if there is a valid replacement which is already installed. Regards, Andrej On Thu, 2021-10-14 at 07:36 -1000, Steve Sakoman wrote: > On Wed, Oct 13, 2021 at 9:14 AM Valek, Andrej > wrote: > > > Would it be possible to include this commit > > https://lists.openembedded.org/g/openembedded-core/message/150627 i > > nto > > dunfell branch? > > At first glance this seems to change the default behavior. Perhaps a > version of the patch that adds the knobs but keeps the same behavior? > > I may be mistaken since I'm not really familiar with this package, so > would love input from those who are! > > Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156987): https://lists.openembedded.org/g/openembedded-core/message/156987 Mute This Topic: https://lists.openembedded.org/mt/86296104/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] libpsl: Add config knobs for runtime/builtin conversion choices
Hello Steve, Would it be possible to include this commit https://lists.openembedded.org/g/openembedded-core/message/150627 into dunfell branch? Thanks, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156920): https://lists.openembedded.org/g/openembedded-core/message/156920 Mute This Topic: https://lists.openembedded.org/mt/86296104/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v3 2/2] kernel-fitimage: use correct kernel image
Even if initramfs_bundle_path was used, a wrong compression was reflected
in output its template file. Use linux.bin as universal kernel image.
The linux.bin file covers both cases.
Use linux.bin as a replacement for zImage in selftest. We know,
that zImage is a compressed one, so get the compression type.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17 +
meta/lib/oeqa/selftest/cases/fitimage.py | 8 +++-
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 886ed13029..8718ce7e16 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -495,22 +495,7 @@ fitimage_assemble() {
fitimage_emit_section_maint $1 imagestart
uboot_prep_kimage
-
- if [ "${INITRAMFS_IMAGE_BUNDLE}" = "1" ]; then
-
initramfs_bundle_path="arch/"${UBOOT_ARCH}"/boot/"${KERNEL_IMAGETYPE_REPLACEMENT}".initramfs"
- if [ -e "$initramfs_bundle_path" ]; then
-
- #
- # Include the kernel/rootfs bundle.
- #
-
- fitimage_emit_section_kernel $1 $kernelcount
"$initramfs_bundle_path" "$linux_comp"
- else
- bbwarn "$initramfs_bundle_pat not found."
- fi
- else
- fitimage_emit_section_kernel $1 $kernelcount linux.bin
"$linux_comp"
- fi
+ fitimage_emit_section_kernel $1 $kernelcount linux.bin "$linux_comp"
#
# Step 2: Prepare a DTB image section
diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py
b/meta/lib/oeqa/selftest/cases/fitimage.py
index 184c8778d2..39c1cf9dd1 100644
--- a/meta/lib/oeqa/selftest/cases/fitimage.py
+++ b/meta/lib/oeqa/selftest/cases/fitimage.py
@@ -741,7 +741,6 @@ UBOOT_ARCH = "arm"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_EXTLINUX = "0"
FIT_GENERATE_KEYS = "1"
-KERNEL_IMAGETYPE_REPLACEMENT = "zImage"
FIT_HASH_ALG = "sha256"
"""
self.write_config(config)
@@ -763,9 +762,8 @@ FIT_HASH_ALG = "sha256"
kernel_load = str(get_bb_var('UBOOT_LOADADDRESS'))
kernel_entry = str(get_bb_var('UBOOT_ENTRYPOINT'))
-initramfs_bundle_format =
str(get_bb_var('KERNEL_IMAGETYPE_REPLACEMENT'))
+kernel_compression = str(get_bb_var('FIT_KERNEL_COMP_ALG'))
uboot_arch = str(get_bb_var('UBOOT_ARCH'))
-initramfs_bundle = "arch/" + uboot_arch + "/boot/" +
initramfs_bundle_format + ".initramfs"
fit_hash_alg = str(get_bb_var('FIT_HASH_ALG'))
its_file = open(fitimage_its_path)
@@ -775,11 +773,11 @@ FIT_HASH_ALG = "sha256"
exp_node_lines = [
'kernel-1 {',
'description = "Linux kernel";',
-'data = /incbin/("' + initramfs_bundle + '");',
+'data = /incbin/("linux.bin");',
'type = "kernel";',
'arch = "' + uboot_arch + '";',
'os = "linux";',
-'compression = "none";',
+'compression = "' + kernel_compression + '";',
'load = <' + kernel_load + '>;',
'entry = <' + kernel_entry + '>;',
'hash-1 {',
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156902):
https://lists.openembedded.org/g/openembedded-core/message/156902
Mute This Topic: https://lists.openembedded.org/mt/86286120/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v3 1/2] featimage: refactor style
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose
Signed-off-by: Andrej Valek
---
meta/classes/kernel-fitimage.bbclass | 297 ++-
meta/classes/uboot-sign.bbclass | 56 ++---
2 files changed, 178 insertions(+), 175 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 38e05153e3..886ed13029 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
#
# $1 ... .its filename
fitimage_emit_fit_header() {
- cat << EOF >> ${1}
+ cat << EOF >> $1
/dts-v1/;
/ {
@@ -94,24 +94,24 @@ EOF
fitimage_emit_section_maint() {
case $2 in
imagestart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
images {
EOF
;;
confstart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
configurations {
EOF
;;
sectend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
fitend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
@@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print "0x"$1;exit}'`
fi
- cat << EOF >> ${1}
-kernel-${2} {
+ cat << EOF >> $1
+kernel-$2 {
description = "Linux kernel";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "kernel";
arch = "${UBOOT_ARCH}";
os = "linux";
-compression = "${4}";
+compression = "$4";
load = <${UBOOT_LOADADDRESS}>;
-entry = <${ENTRYPOINT}>;
+entry = <$ENTRYPOINT>;
hash-1 {
-algo = "${kernel_csum}";
+algo = "$kernel_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${kernel_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "$kernel_sign_keyname" ] ; then
+ sed -i '$ d' $1
+ cat << EOF >> $1
signature-1 {
-algo = "${kernel_csum},${kernel_sign_algo}";
-key-name-hint = "${kernel_sign_keyname}";
+algo = "$kernel_csum,$kernel_sign_algo";
+key-name-hint = "$kernel_sign_keyname";
};
};
EOF
@@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
fi
- cat << EOF >> ${1}
-fdt-${2} {
+ cat << EOF >> $1
+fdt-$2 {
description = "Flattened Device Tree blob";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "flat_dt";
arch = "${UBOOT_ARCH}";
compression = "none";
-${dtb_loadline}
+$dtb_loadline
hash-1 {
-algo = "${dtb_csum}";
+algo = "$dtb_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${dtb_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}
[OE-core][PATCH v2 2/2] kernel-fitimage: use correct kernel image
Even if initramfs_bundle_path was used, a wrong compression was reflected
in output its template file. Use linux.bin as universal kernel image.
The linux.bin file covers both cases.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 886ed13029..8718ce7e16 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -495,22 +495,7 @@ fitimage_assemble() {
fitimage_emit_section_maint $1 imagestart
uboot_prep_kimage
-
- if [ "${INITRAMFS_IMAGE_BUNDLE}" = "1" ]; then
-
initramfs_bundle_path="arch/"${UBOOT_ARCH}"/boot/"${KERNEL_IMAGETYPE_REPLACEMENT}".initramfs"
- if [ -e "$initramfs_bundle_path" ]; then
-
- #
- # Include the kernel/rootfs bundle.
- #
-
- fitimage_emit_section_kernel $1 $kernelcount
"$initramfs_bundle_path" "$linux_comp"
- else
- bbwarn "$initramfs_bundle_pat not found."
- fi
- else
- fitimage_emit_section_kernel $1 $kernelcount linux.bin
"$linux_comp"
- fi
+ fitimage_emit_section_kernel $1 $kernelcount linux.bin "$linux_comp"
#
# Step 2: Prepare a DTB image section
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156674):
https://lists.openembedded.org/g/openembedded-core/message/156674
Mute This Topic: https://lists.openembedded.org/mt/86113979/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2 1/2] featimage: refactor style
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose
Signed-off-by: Andrej Valek
---
meta/classes/kernel-fitimage.bbclass | 297 ++-
meta/classes/uboot-sign.bbclass | 56 ++---
2 files changed, 178 insertions(+), 175 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 38e05153e3..886ed13029 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
#
# $1 ... .its filename
fitimage_emit_fit_header() {
- cat << EOF >> ${1}
+ cat << EOF >> $1
/dts-v1/;
/ {
@@ -94,24 +94,24 @@ EOF
fitimage_emit_section_maint() {
case $2 in
imagestart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
images {
EOF
;;
confstart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
configurations {
EOF
;;
sectend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
fitend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
@@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print "0x"$1;exit}'`
fi
- cat << EOF >> ${1}
-kernel-${2} {
+ cat << EOF >> $1
+kernel-$2 {
description = "Linux kernel";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "kernel";
arch = "${UBOOT_ARCH}";
os = "linux";
-compression = "${4}";
+compression = "$4";
load = <${UBOOT_LOADADDRESS}>;
-entry = <${ENTRYPOINT}>;
+entry = <$ENTRYPOINT>;
hash-1 {
-algo = "${kernel_csum}";
+algo = "$kernel_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${kernel_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "$kernel_sign_keyname" ] ; then
+ sed -i '$ d' $1
+ cat << EOF >> $1
signature-1 {
-algo = "${kernel_csum},${kernel_sign_algo}";
-key-name-hint = "${kernel_sign_keyname}";
+algo = "$kernel_csum,$kernel_sign_algo";
+key-name-hint = "$kernel_sign_keyname";
};
};
EOF
@@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
fi
- cat << EOF >> ${1}
-fdt-${2} {
+ cat << EOF >> $1
+fdt-$2 {
description = "Flattened Device Tree blob";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "flat_dt";
arch = "${UBOOT_ARCH}";
compression = "none";
-${dtb_loadline}
+$dtb_loadline
hash-1 {
-algo = "${dtb_csum}";
+algo = "$dtb_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${dtb_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}
[OE-core][PATCH 2/2] kernel-fitimage: use correct kernel image
Even if initramfs_bundle_path was used, kernel compression was not
reflected in output its image. Use linux.bin as kernel compressed output
image. File is correctly created from vmlinux which includes a right
initramfs image.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 22b77f1858..7969c89f1a 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -495,22 +495,7 @@ fitimage_assemble() {
fitimage_emit_section_maint $1 imagestart
uboot_prep_kimage
-
- if [ "${INITRAMFS_IMAGE_BUNDLE}" = "1" ]; then
-
initramfs_bundle_path="arch/"${UBOOT_ARCH}"/boot/"${KERNEL_IMAGETYPE_REPLACEMENT}".initramfs"
- if [ -e "$initramfs_bundle_path" ]; then
-
- #
- # Include the kernel/rootfs bundle.
- #
-
- fitimage_emit_section_kernel $1 $kernelcount
"$initramfs_bundle_path" "$linux_comp"
- else
- bbwarn "$initramfs_bundle_pat not found."
- fi
- else
- fitimage_emit_section_kernel $1 $kernelcount linux.bin
"$linux_comp"
- fi
+ fitimage_emit_section_kernel $1 $kernelcount linux.bin "$linux_comp"
#
# Step 2: Prepare a DTB image section
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156659):
https://lists.openembedded.org/g/openembedded-core/message/156659
Mute This Topic: https://lists.openembedded.org/mt/86104017/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 1/2] featimage: refactor style
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
Signed-off-by: Andrej Valek
---
meta/classes/kernel-fitimage.bbclass | 292 +--
meta/classes/uboot-sign.bbclass | 56 ++---
2 files changed, 174 insertions(+), 174 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 38e05153e3..22b77f1858 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
#
# $1 ... .its filename
fitimage_emit_fit_header() {
- cat << EOF >> ${1}
+ cat << EOF >> $1
/dts-v1/;
/ {
@@ -94,24 +94,24 @@ EOF
fitimage_emit_section_maint() {
case $2 in
imagestart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
images {
EOF
;;
confstart)
- cat << EOF >> ${1}
+ cat << EOF >> $1
configurations {
EOF
;;
sectend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
fitend)
- cat << EOF >> ${1}
+ cat << EOF >> $1
};
EOF
;;
@@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print "0x"$1;exit}'`
fi
- cat << EOF >> ${1}
-kernel-${2} {
+ cat << EOF >> $1
+kernel-$2 {
description = "Linux kernel";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "kernel";
arch = "${UBOOT_ARCH}";
os = "linux";
-compression = "${4}";
+compression = "$4";
load = <${UBOOT_LOADADDRESS}>;
-entry = <${ENTRYPOINT}>;
+entry = <$ENTRYPOINT>;
hash-1 {
-algo = "${kernel_csum}";
+algo = "$kernel_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${kernel_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "$kernel_sign_keyname" ] ; then
+ sed -i '$ d' $1
+ cat << EOF >> $1
signature-1 {
-algo = "${kernel_csum},${kernel_sign_algo}";
-key-name-hint = "${kernel_sign_keyname}";
+algo = "$kernel_csum,$kernel_sign_algo";
+key-name-hint = "$kernel_sign_keyname";
};
};
EOF
@@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
fi
- cat << EOF >> ${1}
-fdt-${2} {
+ cat << EOF >> $1
+fdt-$2 {
description = "Flattened Device Tree blob";
-data = /incbin/("${3}");
+data = /incbin/("$3");
type = "flat_dt";
arch = "${UBOOT_ARCH}";
compression = "none";
-${dtb_loadline}
+$dtb_loadline
hash-1 {
-algo = "${dtb_csum}";
+algo = "$dtb_csum";
};
};
EOF
- if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "${dtb_sign_keyname}" ] ; then
- sed -i '$ d' ${1}
- cat << EOF >> ${1}
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a
-n "$dtb_sign_keyname" ] ; then
+ sed
[OE-core][PATCH] busybox: 1.34.0 -> 1.34.1
- update to next stable version 1.34.1
Signed-off-by: Andrej Valek
---
.../{busybox-inittab_1.34.0.bb => busybox-inittab_1.34.1.bb}| 0
.../busybox/{busybox_1.34.0.bb => busybox_1.34.1.bb}| 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-core/busybox/{busybox-inittab_1.34.0.bb =>
busybox-inittab_1.34.1.bb} (100%)
rename meta/recipes-core/busybox/{busybox_1.34.0.bb => busybox_1.34.1.bb} (95%)
diff --git a/meta/recipes-core/busybox/busybox-inittab_1.34.0.bb
b/meta/recipes-core/busybox/busybox-inittab_1.34.1.bb
similarity index 100%
rename from meta/recipes-core/busybox/busybox-inittab_1.34.0.bb
rename to meta/recipes-core/busybox/busybox-inittab_1.34.1.bb
diff --git a/meta/recipes-core/busybox/busybox_1.34.0.bb
b/meta/recipes-core/busybox/busybox_1.34.1.bb
similarity index 95%
rename from meta/recipes-core/busybox/busybox_1.34.0.bb
rename to meta/recipes-core/busybox/busybox_1.34.1.bb
index 51df1df05f..6aed0f0476 100644
--- a/meta/recipes-core/busybox/busybox_1.34.0.bb
+++ b/meta/recipes-core/busybox/busybox_1.34.1.bb
@@ -51,4 +51,4 @@ SRC_URI =
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
"
SRC_URI:append:libc-musl = " file://musl.cfg "
-SRC_URI[tarball.sha256sum] =
"ec8d1615edb045b83b81966604759c4d4ac921434ab4011da604f629c06074ce"
+SRC_URI[tarball.sha256sum] =
"415fbd89e5344c96acf449d94a6f956dbed62e18e835fc83e064db33a34bd549"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156580):
https://lists.openembedded.org/g/openembedded-core/message/156580
Mute This Topic: https://lists.openembedded.org/mt/86062952/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v2] vim: add option to disable NLS support
Hello Steve,
What's the current status in this case?
I see, that changes are in dunfell-nut branch
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=stable/dunfell-nut
. But you bumped the 3.1.11 version already
(http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dunfell ) where
the changes are not there.
Regards,
Andrej
On Wed, 2021-09-01 at 12:35 -1000, Steve Sakoman wrote:
> On Wed, Sep 1, 2021 at 9:04 AM Andrej Valek
> wrote:
> >
> > Hello Steve,
> >
> > Could you please cherry-pick this patch into dunfell branch too?
>
> OK, will add this to my test queue.
>
> Steve
>
> >
> > Thank you,
> > Andrej
> >
> > On Thu, 2021-08-26 at 15:15 +0200, Andrej Valek wrote:
> > > - Some distributions with UTF-8 locale have problem when National
> > > Language
> > > Support is enabled. Add there an option to disable it.
> > >
> > > Signed-off-by: Andrej Valek
> > > ---
> > > meta/recipes-support/vim/vim.inc | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-
> > > support/vim/vim.inc
> > > index 17d1c24a7c..860fd24863 100644
> > > --- a/meta/recipes-support/vim/vim.inc
> > > +++ b/meta/recipes-support/vim/vim.inc
> > > @@ -54,11 +54,12 @@ do_compile() {
> > > autotools_do_compile
> > > }
> > >
> > > -#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny
> > > +#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny
> > > selinux,
> > > elfutils, nls
> > > PACKAGECONFIG ??= ""
> > > PACKAGECONFIG += " \
> > > ${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)} \
> > > ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtkgui',
> > > '',
> > > d)} \
> > > + nls \
> > > "
> > >
> > > PACKAGECONFIG[gtkgui] = "--enable-gui=gtk3,--enable-gui=no,gtk+3"
> > > @@ -67,6 +68,7 @@ PACKAGECONFIG[x11] = "--with-x,--without-x,xt,"
> > > PACKAGECONFIG[tiny] = "--with-features=tiny,--with-features=big,,"
> > > PACKAGECONFIG[selinux] = "--enable-selinux,--disable-
> > > selinux,libselinux,"
> > > PACKAGECONFIG[elfutils] = "--enable-elf-check,,elfutils,"
> > > +PACKAGECONFIG[nls] = "--enable-nls,--disable-nls,,"
> > >
> > > EXTRA_OECONF = " \
> > > --disable-gpm \
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155779):
https://lists.openembedded.org/g/openembedded-core/message/155779
Mute This Topic: https://lists.openembedded.org/mt/85160578/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v2] vim: add option to disable NLS support
Hello Steve,
Could you please cherry-pick this patch into dunfell branch too?
Thank you,
Andrej
On Thu, 2021-08-26 at 15:15 +0200, Andrej Valek wrote:
> - Some distributions with UTF-8 locale have problem when National
> Language
> Support is enabled. Add there an option to disable it.
>
> Signed-off-by: Andrej Valek
> ---
> meta/recipes-support/vim/vim.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-
> support/vim/vim.inc
> index 17d1c24a7c..860fd24863 100644
> --- a/meta/recipes-support/vim/vim.inc
> +++ b/meta/recipes-support/vim/vim.inc
> @@ -54,11 +54,12 @@ do_compile() {
> autotools_do_compile
> }
>
> -#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny
> +#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny selinux,
> elfutils, nls
> PACKAGECONFIG ??= ""
> PACKAGECONFIG += " \
> ${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtkgui', '',
> d)} \
> + nls \
> "
>
> PACKAGECONFIG[gtkgui] = "--enable-gui=gtk3,--enable-gui=no,gtk+3"
> @@ -67,6 +68,7 @@ PACKAGECONFIG[x11] = "--with-x,--without-x,xt,"
> PACKAGECONFIG[tiny] = "--with-features=tiny,--with-features=big,,"
> PACKAGECONFIG[selinux] = "--enable-selinux,--disable-
> selinux,libselinux,"
> PACKAGECONFIG[elfutils] = "--enable-elf-check,,elfutils,"
> +PACKAGECONFIG[nls] = "--enable-nls,--disable-nls,,"
>
> EXTRA_OECONF = " \
> --disable-gpm \
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155602):
https://lists.openembedded.org/g/openembedded-core/message/155602
Mute This Topic: https://lists.openembedded.org/mt/85160578/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2] vim: add option to disable NLS support
- Some distributions with UTF-8 locale have problem when National Language
Support is enabled. Add there an option to disable it.
Signed-off-by: Andrej Valek
---
meta/recipes-support/vim/vim.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 17d1c24a7c..860fd24863 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -54,11 +54,12 @@ do_compile() {
autotools_do_compile
}
-#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny
+#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny selinux, elfutils,
nls
PACKAGECONFIG ??= ""
PACKAGECONFIG += " \
${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtkgui', '', d)} \
+nls \
"
PACKAGECONFIG[gtkgui] = "--enable-gui=gtk3,--enable-gui=no,gtk+3"
@@ -67,6 +68,7 @@ PACKAGECONFIG[x11] = "--with-x,--without-x,xt,"
PACKAGECONFIG[tiny] = "--with-features=tiny,--with-features=big,,"
PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux,"
PACKAGECONFIG[elfutils] = "--enable-elf-check,,elfutils,"
+PACKAGECONFIG[nls] = "--enable-nls,--disable-nls,,"
EXTRA_OECONF = " \
--disable-gpm \
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155360):
https://lists.openembedded.org/g/openembedded-core/message/155360
Mute This Topic: https://lists.openembedded.org/mt/85160578/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
