Re: [OE-core] rust: why is it built in do_install()

2023-09-01 Thread Alexander Kanavin
On Fri, 1 Sept 2023 at 23:22, Richard Purdie
 wrote:
> > > do_compile () {
> > > rust_runx install
> > > rust_runx install clippy
> > > rust_runx install rustfmt
> > > }
> > >
> > > rust_do_install() {
> > > cp -a ${B}/_install ${D}
> >
> > ?
> >
> >
> > [adding 'rustfmt' to 'class-native' would be nice because e.g. 'bindgen'
> >  users might expect it]
>
> One potential downside is that "install" would then run outside pseudo
> context which may cause problems with permissions. I don't really know
> whether that would be an issue or not though in reality.
>
> I'd be happy to see more people working on the rust recipes. The
> challenge is the long testing cycles needed. Fancy working on some
> patches?

The original recipes in meta-rust and oe-core recipes had for a while
separate compile/install steps. At some point this regressed on a
version update - install on top of compile became broken and errored
out, but pristine install (with compile inside of it) continued to
work. This is what upstream tests and documents, so that's how rust
recipe does it as well nowadays. It's not any slower than separate
steps, actually it's somewhat faster, as install was rebuilding
supplementary things unnecessarily after compile has already done
that. The only problem I see is that it's indeed visually confusing.

If somene wants to separate the steps again, they can simply find the
commit in oe-core history and undo that. Any changes would have to
fulfil this:
1. Rust's installation procedure should run under pseudo, e.g. in
do_install. Even if it's not a problem now, it might become a problem
later.
2. The changes can't lengthen build times. Rust is already one of the
slowest items in core.
3. This probably requires fixing things in rust upstream, w.r.t.
supporting separation of build/install, and install using artefacts
from the build step properly.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187020): 
https://lists.openembedded.org/g/openembedded-core/message/187020
Mute This Topic: https://lists.openembedded.org/mt/101098826/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] uki: Add support for building Unified Kernel Images

2023-09-01 Thread Alejandro Hernandez Samaniego

Acked-by: Alejandro Hernandez

On 9/1/23 17:32, Michelle Lin wrote:

Currently, there is not a class to support the building of unified kernel
images. Adding a uki.bbclass to support the creation of UKIs. This class calls
the systemd Ukify tool, which will combine the kernel/initrd/stub components to
build the UKI. To sign the UKI (i.e. SecureBoot, TPM PCR signing), the keys/cert
files are to be specified in a separate configuration file, and the path to the
file is passed to the Ukify tool. UKIs are supported by UEFI and can improve
security through predicted TPM PCR states, and reduce the build burden due to
its single PE binary format.

Signed-off-by: Michelle Lin
---
  meta/classes/uki.bbclass | 140 +++
  meta/recipes-core/systemd/systemd_254.bb |  23 
  2 files changed, 163 insertions(+)
  create mode 100644 meta/classes/uki.bbclass

diff --git a/meta/classes/uki.bbclass b/meta/classes/uki.bbclass
new file mode 100644
index 00..2eff387c75
--- /dev/null
+++ b/meta/classes/uki.bbclass
@@ -0,0 +1,140 @@
+#
+# Unified kernel image (UKI) class
+#
+#
+# This bbclass is designed to repack an Overlake image as a UKI, to be booted 
on a qemuarm64 with SecureBoot
+# signing and embedded with TPM PCR measurements.
+#
+# The UKI is composed by:
+#   - an UEFI stub
+# The linux kernel can generate a UEFI stub, however the one from 
systemd-boot can fetch
+# the command line from a separate section of the EFI application, 
avoiding the need to
+# rebuild the kernel.
+#   - the kernel
+#   - an initramfs
+#   - other metadata (e.g. PCR measurements)
+#
+#
+#
+
+# List build time dependencies
+DEPENDS += "systemd-native \
+sbsigntool-native \
+virtual/${TARGET_PREFIX}binutils \
+"
+
+REQUIRED_DISTRO_FEATURES += "usrmerge systemd"
+
+inherit features_check
+require ../conf/image-uefi.conf
+
+INITRD_IMAGE ?= "core-image-minimal-initramfs"
+
+INITRD_LIVE ?= "${@ ('${DEPLOY_DIR_IMAGE}/' + d.getVar('INITRD_IMAGE') + 
'-${MACHINE}.cpio.gz') if d.getVar('INITRD_IMAGE') else ''}"
+
+UKI_CONFIG_FILE ?= "${WORKDIR}/core-image-minimal-uki.conf"
+UKI_FILENAME ?= "${@ 'UKI.signed.efi' if d.getVar('UKI_CONFIG_FILE') else 
'UKI.unsigned.efi'}"
+
+do_uki[depends] += " \
+systemd-boot:do_deploy \
+virtual/kernel:do_deploy \
+ "
+
+# INITRD_IMAGE is added to INITRD_LIVE, which we use to create our initrd, so 
depend on it if it is set
+# So we want to generate the initrd image if INITRD_IMAGE exists
+do_uki[depends] += "${@ '${INITRD_IMAGE}:do_image_complete' if 
d.getVar('INITRD_IMAGE') else ''}"
+
+# ensure that the build directory is empty everytime we generate a 
newly-created uki
+do_uki[cleandirs] = "${B}"
+# influence the build directory at the start of the builds
+do_uki[dirs] = "${B}"
+
+# we want to allow specifying files in SRC_URI, such as for signing the UKI
+python () {
+d.delVarFlag("do_fetch","noexec")
+d.delVarFlag("do_unpack","noexec")
+}
+
+# main task
+python do_uki() {
+import glob
+import subprocess
+
+# Construct the ukify command
+ukify_cmd = ("ukify build")
+
+# Handle the creation of an initrd image by reading and concatenating 
multiple cpio files.
+# If the INITRD_LIVE variable is defined and not empty, it opens the 
necessary files, reads their contents,
+# and constructs a list.
+if d.getVar('INITRD_LIVE'):
+initrd_list = ""
+for cpio in d.getVar('INITRD_LIVE').split():
+# get a list of initrds
+initrd_list += cpio + ' '
+
+ukify_cmd += " --initrd=%s" % initrd_list
+else:
+bb.fatal("ERROR - Required argument: INITRD")
+
+deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE')
+
+# Kernel
+if d.getVar('KERNEL_IMAGETYPE'):
+kernel = "%s/%s" % (deploy_dir_image, d.getVar('KERNEL_IMAGETYPE'))
+kernel_version = d.getVar('KERNEL_VERSION')
+if not os.path.exists(kernel):
+bb.fatal(f"ERROR: cannot find {kernel}.")
+
+ukify_cmd += " --linux=%s --uname %s" % (kernel, kernel_version)
+else:
+bb.fatal("ERROR - Required argument: KERNEL")
+
+# Architecture
+target_arch = d.getVar('EFI_ARCH')
+ukify_cmd += " --efi-arch %s" % target_arch
+
+# Stub
+stub = "%s/linux%s.efi.stub" % (deploy_dir_image, target_arch)
+if not os.path.exists(stub):
+bb.fatal(f"ERROR: cannot find {stub}.")
+ukify_cmd += " --stub %s" % stub
+
+# Add option for dtb
+if d.getVar('KERNEL_DEVICETREE'):
+first_dtb = d.getVar('KERNEL_DEVICETREE').split()[0]
+dtb_path = "%s/%s" % (deploy_dir_image, first_dtb)
+
+if not os.path.exists(dtb_path):
+bb.fatal(f"ERROR: cannot find {dtb_path}.")
+
+ukify_cmd += " --devicetree %s" % dtb_path
+
+# Add option to pass a config file to sign the UKI.
+if os.path.exists(d.getVar('UKI_CONFIG_FILE')):
+

[OE-core] [RFC] uki: Example usage of uki.bbclass

2023-09-01 Thread Michelle Lin
This patch contains an example recipe, core-image-minimal-uki.bb, on how to use
the uki.bbclass. The recipe specifies the need for a config file to be passed to
SRC_URI if the UKI is to be signed. The config file simplifies the usage of the
class by allowing the user to organize, manage, and customize the settings for
signing the UKI (i.e. SecureBoot, PCR signing). See systemd Ukify documentation
for a detailed rundown of the syntax
(https://www.freedesktop.org/software/systemd/man/ukify.html). If the config
file is not present nor specified in the recipe, the UKI will be unsigned when
built.

Signed-off-by: Michelle Lin 
---
 .../core-image-minimal-uki.bb | 11 +++
 .../core-image-minimal-uki.conf   | 19 +++
 2 files changed, 30 insertions(+)
 create mode 100644 
meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki.bb
 create mode 100644 
meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki/core-image-minimal-uki.conf

diff --git 
a/meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki.bb 
b/meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki.bb
new file mode 100644
index 00..5cdf46a35c
--- /dev/null
+++ b/meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki.bb
@@ -0,0 +1,11 @@
+SUMMARY = "Overlake UKI creation with signing"
+
+require ../../recipes-core/images/core-image-minimal.bb
+inherit uki
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/core-image-minimal-uki:"
+
+# To sign the UKI, you must specify the path to the config file containing the 
key/cert filepaths for signing.
+# If SRC_URI doesn't specify the path to the config file, the UKI will build 
but remained unsigned.
+
+# SRC_URI:append = " file://core-image-minimal-uki.conf"
diff --git 
a/meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki/core-image-minimal-uki.conf
 
b/meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki/core-image-minimal-uki.conf
new file mode 100644
index 00..6e331ff1ae
--- /dev/null
+++ 
b/meta/recipes-extended/core-image-minimal-uki/core-image-minimal-uki/core-image-minimal-uki.conf
@@ -0,0 +1,19 @@
+#
+# This file is your configuration file where settings for signing the UKI can 
be specified. 
+# You must specify the path to the proper paths to the key/cert files in order 
to sign the UKI. Otherwise, the image will be built unsigned.
+#
+# SecureBoot Signing
+#
+[UKI]
+SecureBootPrivateKey=
+SecureBootCertificate=
+#
+# PCR Signature
+#
+[PCRSignature:initrd]
+PCRPrivateKey=
+PCRPublicKey=
+
+[PCRSignature:system]
+PCRPrivateKey=
+PCRPublicKey=
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187018): 
https://lists.openembedded.org/g/openembedded-core/message/187018
Mute This Topic: https://lists.openembedded.org/mt/101106101/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] uki: Add support for building Unified Kernel Images

2023-09-01 Thread Michelle Lin
Currently, there is not a class to support the building of unified kernel
images. Adding a uki.bbclass to support the creation of UKIs. This class calls
the systemd Ukify tool, which will combine the kernel/initrd/stub components to
build the UKI. To sign the UKI (i.e. SecureBoot, TPM PCR signing), the keys/cert
files are to be specified in a separate configuration file, and the path to the
file is passed to the Ukify tool. UKIs are supported by UEFI and can improve
security through predicted TPM PCR states, and reduce the build burden due to
its single PE binary format.

Signed-off-by: Michelle Lin 
---
 meta/classes/uki.bbclass | 140 +++
 meta/recipes-core/systemd/systemd_254.bb |  23 
 2 files changed, 163 insertions(+)
 create mode 100644 meta/classes/uki.bbclass

diff --git a/meta/classes/uki.bbclass b/meta/classes/uki.bbclass
new file mode 100644
index 00..2eff387c75
--- /dev/null
+++ b/meta/classes/uki.bbclass
@@ -0,0 +1,140 @@
+#
+# Unified kernel image (UKI) class
+#
+#
+# This bbclass is designed to repack an Overlake image as a UKI, to be booted 
on a qemuarm64 with SecureBoot
+# signing and embedded with TPM PCR measurements.
+#
+# The UKI is composed by:
+#   - an UEFI stub
+# The linux kernel can generate a UEFI stub, however the one from 
systemd-boot can fetch
+# the command line from a separate section of the EFI application, 
avoiding the need to
+# rebuild the kernel.
+#   - the kernel
+#   - an initramfs
+#   - other metadata (e.g. PCR measurements)
+#
+#
+#
+
+# List build time dependencies
+DEPENDS += "systemd-native \
+sbsigntool-native \
+virtual/${TARGET_PREFIX}binutils \
+"
+
+REQUIRED_DISTRO_FEATURES += "usrmerge systemd"
+
+inherit features_check
+require ../conf/image-uefi.conf
+
+INITRD_IMAGE ?= "core-image-minimal-initramfs"
+
+INITRD_LIVE ?= "${@ ('${DEPLOY_DIR_IMAGE}/' + d.getVar('INITRD_IMAGE') + 
'-${MACHINE}.cpio.gz') if d.getVar('INITRD_IMAGE') else ''}"
+
+UKI_CONFIG_FILE ?= "${WORKDIR}/core-image-minimal-uki.conf"
+UKI_FILENAME ?= "${@ 'UKI.signed.efi' if d.getVar('UKI_CONFIG_FILE') else 
'UKI.unsigned.efi'}"
+
+do_uki[depends] += " \
+systemd-boot:do_deploy \
+virtual/kernel:do_deploy \
+ "
+
+# INITRD_IMAGE is added to INITRD_LIVE, which we use to create our initrd, so 
depend on it if it is set
+# So we want to generate the initrd image if INITRD_IMAGE exists
+do_uki[depends] += "${@ '${INITRD_IMAGE}:do_image_complete' if 
d.getVar('INITRD_IMAGE') else ''}"
+
+# ensure that the build directory is empty everytime we generate a 
newly-created uki
+do_uki[cleandirs] = "${B}"
+# influence the build directory at the start of the builds
+do_uki[dirs] = "${B}"
+
+# we want to allow specifying files in SRC_URI, such as for signing the UKI
+python () {
+d.delVarFlag("do_fetch","noexec")
+d.delVarFlag("do_unpack","noexec")
+}
+
+# main task
+python do_uki() {
+import glob
+import subprocess
+
+# Construct the ukify command
+ukify_cmd = ("ukify build")
+
+# Handle the creation of an initrd image by reading and concatenating 
multiple cpio files. 
+# If the INITRD_LIVE variable is defined and not empty, it opens the 
necessary files, reads their contents, 
+# and constructs a list.
+if d.getVar('INITRD_LIVE'):
+initrd_list = ""
+for cpio in d.getVar('INITRD_LIVE').split():
+# get a list of initrds
+initrd_list += cpio + ' '
+
+ukify_cmd += " --initrd=%s" % initrd_list
+else:
+bb.fatal("ERROR - Required argument: INITRD")
+
+deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE')
+   
+# Kernel
+if d.getVar('KERNEL_IMAGETYPE'):
+kernel = "%s/%s" % (deploy_dir_image, d.getVar('KERNEL_IMAGETYPE'))
+kernel_version = d.getVar('KERNEL_VERSION')
+if not os.path.exists(kernel):
+bb.fatal(f"ERROR: cannot find {kernel}.")
+
+ukify_cmd += " --linux=%s --uname %s" % (kernel, kernel_version)
+else:
+bb.fatal("ERROR - Required argument: KERNEL")
+
+# Architecture
+target_arch = d.getVar('EFI_ARCH')
+ukify_cmd += " --efi-arch %s" % target_arch
+
+# Stub
+stub = "%s/linux%s.efi.stub" % (deploy_dir_image, target_arch)
+if not os.path.exists(stub):
+bb.fatal(f"ERROR: cannot find {stub}.")
+ukify_cmd += " --stub %s" % stub
+
+# Add option for dtb
+if d.getVar('KERNEL_DEVICETREE'):
+first_dtb = d.getVar('KERNEL_DEVICETREE').split()[0]
+dtb_path = "%s/%s" % (deploy_dir_image, first_dtb)
+
+if not os.path.exists(dtb_path):
+bb.fatal(f"ERROR: cannot find {dtb_path}.")
+
+ukify_cmd += " --devicetree %s" % dtb_path
+
+# Add option to pass a config file to sign the UKI.
+if os.path.exists(d.getVar('UKI_CONFIG_FILE')):
+ukify_cmd += " --config=%s" % 

Re: [OE-core] rust: why is it built in do_install()

2023-09-01 Thread Richard Purdie
On Fri, 2023-09-01 at 18:34 +0200, Enrico Scholz via
lists.openembedded.org wrote:
> Hello,
> 
> rust recipe does
> 
> > do_compile () {
> > }
> >  
> > rust_do_install() {
> > rust_runx install
> > }
> > 
> > rust_do_install:class-nativesdk() {
> > export PSEUDO_UNLOAD=1
> > rust_runx install
> > rust_runx install clippy
> > rust_runx install rustfmt
> 
> 
> What is the reason to run the expensive "rust_runx" in do_install() and
> not in do_compile().

The reason was probably that was what was found to work in the original
recipe and nobody has had the time/need to improve it.

> This:
> 
> - is unexpected... do_install is usually expected to run fast
> 
> - might interfere with different ${PARALLEL_MAKE} and ${PARALLEL_MAKEINST}
>   setup
> 
> - might slow down the build process because the 'class-native' variant
>   seems to run with active 'pseudo'
> 
> 
> I guess it is done in this way because of
> 
> >config.set("install", "prefix",  e(d.getVar("D") + d.getVar("prefix")))
> 
> where '${D}' is cleared by do_install.

That would seem likely to be at least one reason.

> Wouldn't it be better to replace this by
> 
> >config.set("install", "prefix",  e(d.getVar("B") + '/_install' + 
> > d.getVar("prefix")))
> 
> 
> > do_compile () {
> > rust_runx install
> > rust_runx install clippy
> > rust_runx install rustfmt
> > }
> > 
> > rust_do_install() {
> > cp -a ${B}/_install ${D}
> 
> ?
> 
> 
> [adding 'rustfmt' to 'class-native' would be nice because e.g. 'bindgen'
>  users might expect it]

One potential downside is that "install" would then run outside pseudo
context which may cause problems with permissions. I don't really know
whether that would be an issue or not though in reality.

I'd be happy to see more people working on the rust recipes. The
challenge is the long testing cycles needed. Fancy working on some
patches?

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187016): 
https://lists.openembedded.org/g/openembedded-core/message/187016
Mute This Topic: https://lists.openembedded.org/mt/101098826/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] yocto-uninative: Update to 4.3

2023-09-01 Thread Michael Halstead
Add in stable updates to glibc 2.38 to fix malloc bugs

Signed-off-by: Michael Halstead 
---
 meta/conf/distro/include/yocto-uninative.inc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 6596c0f4a2..eaa3e9b31c 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -7,9 +7,9 @@
 #
 
 UNINATIVE_MAXGLIBCVERSION = "2.38"
-UNINATIVE_VERSION = "4.2"
+UNINATIVE_VERSION = "4.3"
 
 UNINATIVE_URL ?= 
"http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/;
-UNINATIVE_CHECKSUM[aarch64] ?= 
"cff40e7bdde50aeda06707af8c001796a71b4cf33c5ae1616e5c47943ff6b94e"
-UNINATIVE_CHECKSUM[i686] ?= 
"a70516447e9a9f1465ffaf1c7f89e79d1692d2356d86fd2a5a63acd908db1ff2"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"6a86d71eeafba4fefec600c9bf8cf4a01324d1eb52788b6e398d3f23c10d19fb"
+UNINATIVE_CHECKSUM[aarch64] ?= 
"8df05f4a41455018b4303b2e0ea4eac5c960b5a13713f6dbb33dfdb3e32753ec"
+UNINATIVE_CHECKSUM[i686] ?= 
"bea76b4a97c9ba0077c0dd1295f519cd599dbf71f0ca1c964471c4cdb043addd"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"1c35f09a75c4096749bbe1e009df4e3968cde151424062cf4aa3ed89db22b030"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187015): 
https://lists.openembedded.org/g/openembedded-core/message/187015
Mute This Topic: https://lists.openembedded.org/mt/101101203/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: 
https://lists.openembedded.org/g/openembedded-core/leave/8023207/21656/1426099254/xyzzy
 [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] rust: why is it built in do_install()

2023-09-01 Thread Frederic Martinsons
Hello Enrico,

Le ven. 1 sept. 2023, 18:34, Enrico Scholz via lists.openembedded.org
 a écrit :

> Hello,
>
> rust recipe does
>
> | do_compile () {
> | }
> |
> | rust_do_install() {
> | rust_runx install
> | }
> |
> | rust_do_install:class-nativesdk() {
> | export PSEUDO_UNLOAD=1
> | rust_runx install
> | rust_runx install clippy
> | rust_runx install rustfmt
>
>
> What is the reason to run the expensive "rust_runx" in do_install() and
> not in do_compile().
>
> This:
>
> - is unexpected... do_install is usually expected to run fast
>
> - might interfere with different ${PARALLEL_MAKE} and ${PARALLEL_MAKEINST}
>   setup
>
> - might slow down the build process because the 'class-native' variant
>   seems to run with active 'pseudo'
>
>
> I guess it is done in this way because of
>
> |config.set("install", "prefix",  e(d.getVar("D") +
> d.getVar("prefix")))
>
> where '${D}' is cleared by do_install.
>
>
> Wouldn't it be better to replace this by
>
> |config.set("install", "prefix",  e(d.getVar("B") + '/_install' +
> d.getVar("prefix")))
>
>
> | do_compile () {
> | rust_runx install
> | rust_runx install clippy
> | rust_runx install rustfmt
> | }
> |
> | rust_do_install() {
> | cp -a ${B}/_install ${D}
>
> ?
>
>
> [adding 'rustfmt' to 'class-native' would be nice because e.g. 'bindgen'
>  users might expect it]
>
>
I don't know why this was done that way and I lacked xp for telling you if
your suggestion is correct. But I just wanna tell that the
do_install:rust-native is very long (more than 45mn on my machine) so you
may have a point here.

Enrico
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187014): 
https://lists.openembedded.org/g/openembedded-core/message/187014
Mute This Topic: https://lists.openembedded.org/mt/101098826/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] base.bbclass: Do not fail during parsing if ${SRCREV} does not exist

2023-09-01 Thread Peter Kjellerstedt
> -Original Message-
> From: Richard Purdie 
> Sent: den 30 augusti 2023 11:04
> To: Peter Kjellerstedt ; 
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] base.bbclass: Do not fail during parsing if 
> ${SRCREV} does not exist
> 
> On Fri, 2023-08-25 at 19:16 +0200, Peter Kjellerstedt wrote:
> > After commit a8e7b0f932 (base/package: Move source revision information
> > from PV to PKGV) was integrated, having a recipe with a SRCREV that
> > currently cannot be fetched would lead to an exception during parsing.
> > Catch that exception and instead raise bb.parse.SkipRecipe. That way
> > the parsing continues as it should. Instead you now get a meaningful
> > error if you try build a recipe with a SRCREV that cannot be fetched,
> > e.g.:
> >
> >   ERROR: Nothing PROVIDES 'psplash'
> >   psplash was skipped: Fetcher failure: Unable to resolve 'unknown-ref'
> >   in upstream git repository in git ls-remote output for
> >   git.yoctoproject.org/psplash
> 
> Something doesn't sound quite right in this description. You've said "a
> SRCREV that currently cannot be fetched" but "unknown-ref" will never
> be fetchable and is completely invalid as a revision. I'd guess bitbake
> is assuming it is a tag and trying to resolve it.

You are correct in that the problem only occurs when non-SHA1 references 
are used in SRCREV and that should probably be mentioned in the commit 
message. 

> I really don't like complicating the core code when it doesn't make
> sense to, particularly when it relates to cornercases most people don't
> hit.

It is true that the use of non-SHA1 references in SRCREV is not 
recommended, but the bitbake code does have explicit support for it. 
And while we are working on changing our recipes to not use tags in 
SRCREV for released code, it is unfortunately not trivial to do so 
as we have other tooling that currently relies on being able to find 
the tag names in SRCREV. :(

However, not doing anything to improve the OE code is not an option 
I would like to see, because the following is the output I get with 
the current code (modified to remove the actual names):

WARNING: .../meta-axis/recipes-foo/bar/recipe1_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe1_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe1_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe2_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe2_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe2_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe3_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe3_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe3_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe4_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe4_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe4_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe5_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe5_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe5_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe6_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe6_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe6_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe7_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe7_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe7_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe8_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe8_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe8_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe9_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe9_git.bb: Error during finalise of 
.../meta-axis/recipes-foo/bar/recipe9_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe10_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe10_git.bb: Error during finalise 
of .../meta-axis/recipes-foo/bar/recipe10_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe11_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc
WARNING: .../meta-axis/recipes-foo/bar/recipe11_git.bb: Error during finalise 
of .../meta-axis/recipes-foo/bar/recipe11_git.bb
WARNING: .../meta-axis/recipes-foo/bar/recipe12_git.bb: Exception during 
build_dependencies for fetcher_hashes_dummyfunc

[OE-core] rust: why is it built in do_install()

2023-09-01 Thread Enrico Scholz via lists.openembedded.org
Hello,

rust recipe does

| do_compile () {
| }
|  
| rust_do_install() {
| rust_runx install
| }
| 
| rust_do_install:class-nativesdk() {
| export PSEUDO_UNLOAD=1
| rust_runx install
| rust_runx install clippy
| rust_runx install rustfmt


What is the reason to run the expensive "rust_runx" in do_install() and
not in do_compile().

This:

- is unexpected... do_install is usually expected to run fast

- might interfere with different ${PARALLEL_MAKE} and ${PARALLEL_MAKEINST}
  setup

- might slow down the build process because the 'class-native' variant
  seems to run with active 'pseudo'


I guess it is done in this way because of

|config.set("install", "prefix",  e(d.getVar("D") + d.getVar("prefix")))

where '${D}' is cleared by do_install.


Wouldn't it be better to replace this by

|config.set("install", "prefix",  e(d.getVar("B") + '/_install' + 
d.getVar("prefix")))


| do_compile () {
| rust_runx install
| rust_runx install clippy
| rust_runx install rustfmt
| }
|
| rust_do_install() {
| cp -a ${B}/_install ${D}

?


[adding 'rustfmt' to 'class-native' would be nice because e.g. 'bindgen'
 users might expect it]



Enrico

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187012): 
https://lists.openembedded.org/g/openembedded-core/message/187012
Mute This Topic: https://lists.openembedded.org/mt/101098826/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: Add glibc 2.38 stable updates

2023-09-01 Thread Richard Purdie
Pull in the following stable branch updates:

1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1 sysdeps: tst-bz21269: fix -Wreturn-type
ad9b8399537670a990572c4b0c4da5411e3b68cf sysdeps: tst-bz21269: handle ENOSYS & 
skip appropriately
c8ecda6251dd4a0dfe074e0a6011211cadeef742 sysdeps: tst-bz21269: fix test 
parameter
2af141bda3cd407abd4bedf615f9e45fe79518e2 malloc: Remove bin scanning from 
memalign (bug 30723)
98c293c61f770b6b7a22f89a6ea81b711ecb1952 malloc: Enable merging of remainders 
in memalign (bug 30723)
7ac405a74c6069b0627dc2d8449a82a621f8ff06 i686: Fix build with 
--disable-multiarch
6135d50e44233d8c89ca788f78c669941ad09fb9 x86_64: Fix build with 
--disable-multiarch (BZ 30721)
5ea70cc02626d9b85f1570153873d8648a47bf95 x86: Fix incorrect scope of setting 
`shared_per_thread` [BZ# 30745]
6b99458d197ab779ebb6ff632c168e2cbfa4f543 nscd: Do not rebuild getaddrinfo (bug 
30709)
ced101ed9d3b7cfd12d97ef24940cb00b8658c81 x86: Fix for cache computation on AMD 
legacy cpus.
d97cca1e5df812be0e4de1e38091f02bb1e7ec4e stdlib: Improve tst-realpath 
compatibility with source fortification

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 meta/recipes-core/glibc/glibc-version.inc   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 2e403ce9808..69280fd2107 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 ?= "13.%"
-GLIBCVERSION ?= "2.38"
+GLIBCVERSION ?= "2.38%"
 LINUXLIBCVERSION ?= "6.4%"
 QEMUVERSION ?= "8.1%"
 GOVERSION ?= "1.20%"
diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index f53e59103e2..a907444f504 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
 SRCBRANCH ?= "release/2.38/master"
-PV = "2.38"
-SRCREV_glibc ?= "36f2487f13e3540be9ee0fb51876b1da72176d3f"
+PV = "2.38+git"
+SRCREV_glibc ?= "1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1"
 SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187011): 
https://lists.openembedded.org/g/openembedded-core/message/187011
Mute This Topic: https://lists.openembedded.org/mt/101098185/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] weston: fix comment

2023-09-01 Thread Ulrich Ölmann
Fixes: be7da75827b4 ("weston: update 11.0.1 -> 12.0.1")
Signed-off-by: Ulrich Ölmann 
---
 meta/recipes-graphics/wayland/weston_12.0.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston_12.0.1.bb 
b/meta/recipes-graphics/wayland/weston_12.0.1.bb
index d9eae1ff62f3..8c2438cdaa5b 100644
--- a/meta/recipes-graphics/wayland/weston_12.0.1.bb
+++ b/meta/recipes-graphics/wayland/weston_12.0.1.bb
@@ -70,7 +70,7 @@ PACKAGECONFIG[egl] = 
"-Drenderer-gl=true,-Drenderer-gl=false,virtual/egl"
 PACKAGECONFIG[lcms] = 
"-Dcolor-management-lcms=true,-Dcolor-management-lcms=false,lcms"
 # Weston with webp support
 PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp"
-# Weston with systemd-login support
+# Weston with systemd support
 PACKAGECONFIG[systemd] = "-Dsystemd=true,-Dsystemd=false,systemd dbus"
 # Weston with Xwayland support (requires X11 and Wayland)
 PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb libxcursor 
xcb-util-cursor xwayland"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187010): 
https://lists.openembedded.org/g/openembedded-core/message/187010
Mute This Topic: https://lists.openembedded.org/mt/101097295/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [mickledore][patch 4/4] go: upgrade 1.20.6 -> 1.20.7

2023-09-01 Thread Lee Chee Yang
From: Sakib Sajal 

Upgrade to latest 1.20.x release [1]:

$ git log --oneline go1.20.6..go1.20.7 origin/release-branch.go1.20
adb775e309 (tag: go1.20.7, origin/release-branch.go1.20) 
[release-branch.go1.20] go1.20.7
659f2a2207 [release-branch.go1.20] crypto/tls: restrict RSA keys in 
certificates to <= 8192 bits
10d85fa0f6 [release-branch.go1.20] cmd/asm, cmd/internal/obj: generate proper 
atomic ops for riscv64
bd3a1f24e7 [release-branch.go1.20] net: tolerate permission errors in interface 
tests
6211a024b4 [release-branch.go1.20] cmd/compile: on PPC64, fix sign/zero 
extension when masking

[1] https://github.com/golang/go/compare/go1.20.6...go1.20.7

Upgrade include fix for CVE-2023-29409 CVE-2023-39533

(cherry picked from commit 039324d917ed124228a14ac1effdd66b27d9e82b)

Signed-off-by: Sakib Sajal 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Chee Yang Lee 
---
 meta/recipes-devtools/go/{go-1.20.6.inc => go-1.20.7.inc}   | 2 +-
 ...o-binary-native_1.20.6.bb => go-binary-native_1.20.7.bb} | 6 +++---
 ...cross-canadian_1.20.6.bb => go-cross-canadian_1.20.7.bb} | 0
 .../go/{go-cross_1.20.6.bb => go-cross_1.20.7.bb}   | 0
 .../go/{go-crosssdk_1.20.6.bb => go-crosssdk_1.20.7.bb} | 0
 .../go/{go-native_1.20.6.bb => go-native_1.20.7.bb} | 0
 .../go/{go-runtime_1.20.6.bb => go-runtime_1.20.7.bb}   | 0
 meta/recipes-devtools/go/{go_1.20.6.bb => go_1.20.7.bb} | 0
 8 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/go/{go-1.20.6.inc => go-1.20.7.inc} (90%)
 rename meta/recipes-devtools/go/{go-binary-native_1.20.6.bb => 
go-binary-native_1.20.7.bb} (78%)
 rename meta/recipes-devtools/go/{go-cross-canadian_1.20.6.bb => 
go-cross-canadian_1.20.7.bb} (100%)
 rename meta/recipes-devtools/go/{go-cross_1.20.6.bb => go-cross_1.20.7.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-crosssdk_1.20.6.bb => 
go-crosssdk_1.20.7.bb} (100%)
 rename meta/recipes-devtools/go/{go-native_1.20.6.bb => go-native_1.20.7.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-runtime_1.20.6.bb => go-runtime_1.20.7.bb} 
(100%)
 rename meta/recipes-devtools/go/{go_1.20.6.bb => go_1.20.7.bb} (100%)

diff --git a/meta/recipes-devtools/go/go-1.20.6.inc 
b/meta/recipes-devtools/go/go-1.20.7.inc
similarity index 90%
rename from meta/recipes-devtools/go/go-1.20.6.inc
rename to meta/recipes-devtools/go/go-1.20.7.inc
index 6277020fec..009a67e89e 100644
--- a/meta/recipes-devtools/go/go-1.20.6.inc
+++ b/meta/recipes-devtools/go/go-1.20.7.inc
@@ -17,4 +17,4 @@ SRC_URI += "\
 file://CVE-2023-24531_1.patch \
 file://CVE-2023-24531_2.patch \
 "
-SRC_URI[main.sha256sum] = 
"62ee5bc6fb55b8bae8f705e0cb8df86d6453626b4ecf93279e2867092e0b7f70"
+SRC_URI[main.sha256sum] = 
"2c5ee9c9ec1e733b0dbbc2bdfed3f62306e51d8172bf38f4f4e542b27520f597"
diff --git a/meta/recipes-devtools/go/go-binary-native_1.20.6.bb 
b/meta/recipes-devtools/go/go-binary-native_1.20.7.bb
similarity index 78%
rename from meta/recipes-devtools/go/go-binary-native_1.20.6.bb
rename to meta/recipes-devtools/go/go-binary-native_1.20.7.bb
index 5b2f8f4352..3decde1954 100644
--- a/meta/recipes-devtools/go/go-binary-native_1.20.6.bb
+++ b/meta/recipes-devtools/go/go-binary-native_1.20.7.bb
@@ -9,9 +9,9 @@ PROVIDES = "go-native"
 
 # Checksums available at https://go.dev/dl/
 SRC_URI = 
"https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE};
-SRC_URI[go_linux_amd64.sha256sum] = 
"b945ae2bb5db01a0fb4786afde64e6fbab50b67f6fa0eb6cfa4924f16a7ff1eb"
-SRC_URI[go_linux_arm64.sha256sum] = 
"4e15ab37556e979181a1a1cc60f6d796932223a0f5351d7c83768b356f84429b"
-SRC_URI[go_linux_ppc64le.sha256sum] = 
"a1b91a42a40bba54bfd5c96c23d72250e0c424038d0d2b5c7950b828b4905822"
+SRC_URI[go_linux_amd64.sha256sum] = 
"f0a87f1bcae91c4b69f8dc2bc6d7e6bfcd7524fceec130af525058c0c17b1b44"
+SRC_URI[go_linux_arm64.sha256sum] = 
"44781ae3b153c3b07651d93b6bc554e835a36e2d72a696281c1e4dad9efffe43"
+SRC_URI[go_linux_ppc64le.sha256sum] = 
"6318a1db307c12b8afe68808bd6fae4fba1e558a85b958216096869ed506dcb3"
 
 UPSTREAM_CHECK_URI = "https://golang.org/dl/;
 UPSTREAM_CHECK_REGEX = "go(?P\d+(\.\d+)+)\.linux"
diff --git a/meta/recipes-devtools/go/go-cross-canadian_1.20.6.bb 
b/meta/recipes-devtools/go/go-cross-canadian_1.20.7.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross-canadian_1.20.6.bb
rename to meta/recipes-devtools/go/go-cross-canadian_1.20.7.bb
diff --git a/meta/recipes-devtools/go/go-cross_1.20.6.bb 
b/meta/recipes-devtools/go/go-cross_1.20.7.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross_1.20.6.bb
rename to meta/recipes-devtools/go/go-cross_1.20.7.bb
diff --git a/meta/recipes-devtools/go/go-crosssdk_1.20.6.bb 
b/meta/recipes-devtools/go/go-crosssdk_1.20.7.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-crosssdk_1.20.6.bb
rename to meta/recipes-devtools/go/go-crosssdk_1.20.7.bb
diff --git a/meta/recipes-devtools/go/go-native_1.20.6.bb 

[OE-core] [mickledore][patch 1/4] python3: upgrade 3.11.2 -> 3.11.3

2023-09-01 Thread Lee Chee Yang
From: Alexander Kanavin 

(cherry picked from commit 7d5bb3a4690ef61a1fee21773b4717e829789e32)

Signed-off-by: Alexander Kanavin 
Signed-off-by: Richard Purdie 
Signed-off-by: Chee Yang Lee 
---
 .../0001-Don-t-search-system-for-headers-libraries.patch| 2 +-
 ...1-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch | 2 +-
 .../python3/12-distutils-prefix-is-inside-staging-area.patch| 2 +-
 .../python/{python3_3.11.2.bb => python3_3.11.3.bb} | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/python/{python3_3.11.2.bb => python3_3.11.3.bb} 
(99%)

diff --git 
a/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
 
b/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
index 96e5e81342..c9253832cf 100644
--- 
a/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
+++ 
b/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
@@ -1,4 +1,4 @@
-From 7d296dc635ad3ac2792955ce37e140a4104b098f Mon Sep 17 00:00:00 2001
+From 6cb667f37beacd832cb409e5244b3c90dfad32f7 Mon Sep 17 00:00:00 2001
 From: Jeremy Puhlman 
 Date: Wed, 4 Mar 2020 00:06:42 +
 Subject: [PATCH] Don't search system for headers/libraries
diff --git 
a/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
 
b/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
index 86971f4048..d5b7ce2b95 100644
--- 
a/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
+++ 
b/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
@@ -1,4 +1,4 @@
-From cab8b8b1390165a93dfb27c48c1cc4c3e4280dfd Mon Sep 17 00:00:00 2001
+From 4ed481f4928c361970e78f27c4d9be8700af176b Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Fri, 10 Sep 2021 12:28:31 +0200
 Subject: [PATCH] Lib/sysconfig.py: use prefix value from build configuration
diff --git 
a/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
 
b/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
index e080b5c562..5ee4e4f126 100644
--- 
a/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
+++ 
b/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
@@ -1,4 +1,4 @@
-From 79e7ed59750612e57647847957ab85709307ea38 Mon Sep 17 00:00:00 2001
+From 4c39252c71d8bca81fdc43753c83a59f8668c619 Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Tue, 14 May 2013 15:00:26 -0700
 Subject: [PATCH] python3: Add target and native recipes
diff --git a/meta/recipes-devtools/python/python3_3.11.2.bb 
b/meta/recipes-devtools/python/python3_3.11.3.bb
similarity index 99%
rename from meta/recipes-devtools/python/python3_3.11.2.bb
rename to meta/recipes-devtools/python/python3_3.11.3.bb
index f3be9768bf..0563a0ab9b 100644
--- a/meta/recipes-devtools/python/python3_3.11.2.bb
+++ b/meta/recipes-devtools/python/python3_3.11.3.bb
@@ -39,7 +39,7 @@ SRC_URI:append:class-native = " \
file://12-distutils-prefix-is-inside-staging-area.patch \
file://0001-Don-t-search-system-for-headers-libraries.patch \
"
-SRC_URI[sha256sum] = 
"29e4b8f5f1658542a8c13e2dd277358c9c48f2b2f7318652ef1675e402b9d2af"
+SRC_URI[sha256sum] = 
"8a5db99c961a7ecf27c75956189c9602c968751f11dbeae2b900dbff1c085b5e"
 
 # exclude pre-releases for both python 2.x and 3.x
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar"
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187006): 
https://lists.openembedded.org/g/openembedded-core/message/187006
Mute This Topic: https://lists.openembedded.org/mt/101094624/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [mickledore][patch 3/4] python3: update to 3.11.5

2023-09-01 Thread Lee Chee Yang
From: Chee Yang Lee 

upgrade include fix for CVE-2023-40217

Release notes:
https://docs.python.org/3/whatsnew/changelog.html#python-3-11-5-final

Signed-off-by: Chee Yang Lee 
---
 .../python/{python3_3.11.4.bb => python3_3.11.5.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3_3.11.4.bb => python3_3.11.5.bb} 
(99%)

diff --git a/meta/recipes-devtools/python/python3_3.11.4.bb 
b/meta/recipes-devtools/python/python3_3.11.5.bb
similarity index 99%
rename from meta/recipes-devtools/python/python3_3.11.4.bb
rename to meta/recipes-devtools/python/python3_3.11.5.bb
index 41b27094c7..b1ab307804 100644
--- a/meta/recipes-devtools/python/python3_3.11.4.bb
+++ b/meta/recipes-devtools/python/python3_3.11.5.bb
@@ -39,7 +39,7 @@ SRC_URI:append:class-native = " \
file://12-distutils-prefix-is-inside-staging-area.patch \
file://0001-Don-t-search-system-for-headers-libraries.patch \
"
-SRC_URI[sha256sum] = 
"2f0e409df2ab57aa9fc4cbddfb976af44e4e55bf6f619eee6bc5c2297264a7f6"
+SRC_URI[sha256sum] = 
"85cd12e9cf1d6d5a45f17f7afe1cebe7ee628d3282281c492e86adf636defa3f"
 
 # exclude pre-releases for both python 2.x and 3.x
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar"
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187008): 
https://lists.openembedded.org/g/openembedded-core/message/187008
Mute This Topic: https://lists.openembedded.org/mt/101094626/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [mickledore][patch 2/4] python3: update 3.11.3 -> 3.11.4

2023-09-01 Thread Lee Chee Yang
From: Alexander Kanavin 

upgrade include fix for CVE-2023-24329

(cherry picked from commit f7f163ebe8c53de4314d04595c1fbcc7af2deccc )

Signed-off-by: Alexander Kanavin 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
Signed-off-by: Chee Yang Lee 
---
 ...1-Don-t-search-system-for-headers-libraries.patch |  2 +-
 ...y-handle-stdin-I-O-errors-same-way-as-maste.patch | 12 ++--
 ...nfig.py-use-prefix-value-from-build-configu.patch |  2 +-
 .../12-distutils-prefix-is-inside-staging-area.patch |  2 +-
 meta/recipes-devtools/python/python3/makerace.patch  |  8 
 .../python/{python3_3.11.3.bb => python3_3.11.4.bb}  |  2 +-
 6 files changed, 14 insertions(+), 14 deletions(-)
 rename meta/recipes-devtools/python/{python3_3.11.3.bb => python3_3.11.4.bb} 
(99%)

diff --git 
a/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
 
b/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
index c9253832cf..222a567dd5 100644
--- 
a/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
+++ 
b/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch
@@ -1,4 +1,4 @@
-From 6cb667f37beacd832cb409e5244b3c90dfad32f7 Mon Sep 17 00:00:00 2001
+From aa8f1709c54557d2b51a9a37d15ccc3de62e90cb Mon Sep 17 00:00:00 2001
 From: Jeremy Puhlman 
 Date: Wed, 4 Mar 2020 00:06:42 +
 Subject: [PATCH] Don't search system for headers/libraries
diff --git 
a/meta/recipes-devtools/python/python3/0001-Lib-pty.py-handle-stdin-I-O-errors-same-way-as-maste.patch
 
b/meta/recipes-devtools/python/python3/0001-Lib-pty.py-handle-stdin-I-O-errors-same-way-as-maste.patch
index df5179e877..07c6aef9b9 100644
--- 
a/meta/recipes-devtools/python/python3/0001-Lib-pty.py-handle-stdin-I-O-errors-same-way-as-maste.patch
+++ 
b/meta/recipes-devtools/python/python3/0001-Lib-pty.py-handle-stdin-I-O-errors-same-way-as-maste.patch
@@ -1,4 +1,4 @@
-From 86061629f4a179e740a17e53dd2c98ab47af2fe2 Mon Sep 17 00:00:00 2001
+From 7b0a14e7320078ac891d415cab9b7568e3f52ad8 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Thu, 16 Sep 2021 16:35:37 +0200
 Subject: [PATCH] Lib/pty.py: handle stdin I/O errors same way as master I/O
@@ -30,18 +30,18 @@ Signed-off-by: Alexander Kanavin 
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/Lib/pty.py b/Lib/pty.py
-index 8d8ce40..35439c6 100644
+index fefb63a..4cef056 100644
 --- a/Lib/pty.py
 +++ b/Lib/pty.py
-@@ -154,7 +154,10 @@ def _copy(master_fd, master_read=_read, stdin_read=_read):
- os.write(STDOUT_FILENO, data)
+@@ -184,7 +184,10 @@ def _copy(master_fd, master_read=_read, stdin_read=_read):
+ i_buf = i_buf[n:]
  
- if STDIN_FILENO in rfds:
+ if stdin_avail and STDIN_FILENO in rfds:
 -data = stdin_read(STDIN_FILENO)
 +try:
 +data = stdin_read(STDIN_FILENO)
 +except OSError:
 +data = b""
  if not data:
- fds.remove(STDIN_FILENO)
+ stdin_avail = False
  else:
diff --git 
a/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
 
b/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
index d5b7ce2b95..a0f3d72992 100644
--- 
a/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
+++ 
b/meta/recipes-devtools/python/python3/0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch
@@ -1,4 +1,4 @@
-From 4ed481f4928c361970e78f27c4d9be8700af176b Mon Sep 17 00:00:00 2001
+From 512c617bd00b74b30a80dd56a12391de46e2b6cf Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Fri, 10 Sep 2021 12:28:31 +0200
 Subject: [PATCH] Lib/sysconfig.py: use prefix value from build configuration
diff --git 
a/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
 
b/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
index 5ee4e4f126..bbdd8b586e 100644
--- 
a/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
+++ 
b/meta/recipes-devtools/python/python3/12-distutils-prefix-is-inside-staging-area.patch
@@ -1,4 +1,4 @@
-From 4c39252c71d8bca81fdc43753c83a59f8668c619 Mon Sep 17 00:00:00 2001
+From 843574d5a5b0818e83e20f8c0389d567bd4733fb Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Tue, 14 May 2013 15:00:26 -0700
 Subject: [PATCH] python3: Add target and native recipes
diff --git a/meta/recipes-devtools/python/python3/makerace.patch 
b/meta/recipes-devtools/python/python3/makerace.patch
index 979fc9dc36..c71c1e15de 100644
--- a/meta/recipes-devtools/python/python3/makerace.patch
+++ b/meta/recipes-devtools/python/python3/makerace.patch
@@ -1,4 +1,4 @@
-From 4f52aaf2a548b3356c6f1369c62b11335dc27464 Mon Sep 17 00:00:00 2001
+From 

Re: [OE-core] [master] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

2023-09-01 Thread Dhairya Nagodra via lists.openembedded.org
Hi Peter,

It seems that cve-report.bbclass is already filtering out the CVEs based on the 
vendor.
It would make explicit Whitelisting/Ignoring these CVEs redundant and thus my 4 
commits can be skipped.
Thanks for pointing it out!

Regards,
Dhairya Nagodra

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Peter Marko via
> lists.openembedded.org
> Sent: Friday, September 1, 2023 3:48 PM
> To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco)
> ; openembedded-core@lists.openembedded.org;
> Steve Sakoman ; richard.pur...@linuxfoundation.org
> Cc: qi.c...@windriver.com; xe-linux-external(mailer list)  exter...@cisco.com>
> Subject: Re: [OE-core] [master] [PATCH] flex: Exclude CVE-2015-1773 from
> cve-check.
> 
> What's the reason for ignoring this CVE in all branches when CVE_PRODUCT =
> "flex_project:flex" means it's not reported by cve-check?
> Peter
> 
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Dhairya Nagodra via
> lists.openembedded.org
> Sent: Friday, September 1, 2023 6:15
> To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco)
> ; openembedded-core@lists.openembedded.org;
> Steve Sakoman ; richard.pur...@linuxfoundation.org
> Cc: qi.c...@windriver.com; xe-linux-external(mailer list)  exter...@cisco.com>; st...@sakoman.com
> Subject: Re: [OE-core] [master] [PATCH] flex: Exclude CVE-2015-1773 from
> cve-check.
> 
> > Hi @Steve Sakoman @richard.pur...@linuxfoundation.org,
> >
> > Kindly consider this patch for "master" branch.
> > Apologies for the error.
> >
> > > -Original Message-
> > > From: openembedded-core@lists.openembedded.org  > > c...@lists.openembedded.org> On Behalf Of Dhairya Nagodra via
> > > lists.openembedded.org
> > > Sent: Friday, September 1, 2023 9:38 AM
> > > To: openembedded-core@lists.openembedded.org
> > > Cc: qi.c...@windriver.com; xe-linux-external(mailer list)  > > exter...@cisco.com>; Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC
> > > at
> > > Cisco) 
> > > Subject: [OE-core] [dunfell] [PATCH] flex: Exclude CVE-2015-1773
> > > from
> > > cve- check.
> > >
> > > Issue only affects Apache.
> > >
> > > Signed-off-by: Dhairya Nagodra 
> > > ---
> > >  meta/recipes-devtools/flex/flex_2.6.4.bb | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb
> > > b/meta/recipes- devtools/flex/flex_2.6.4.bb index
> > > 1ac88d65ef..5be7351f4c 100644
> > > --- a/meta/recipes-devtools/flex/flex_2.6.4.bb
> > > +++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
> > > @@ -31,6 +31,8 @@ CVE_STATUS[CVE-2019-6293] = "upstream-wontfix: \
> > > there is stack exhaustion but no bug and it is building the \
> > > parser, not running it, effectively similar to a compiler ICE.
> > > Upstream no plans to address this."
> > >
> > > +CVE_STATUS[CVE-2015-1773] = "not-applicable-platform: Issue only
> > > +affects
> > > Apache."
> > > +
> > >  inherit autotools gettext texinfo ptest github-releases
> > >
> > >  M4 = "${bindir}/m4"
> > > --
> > > 2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187005): 
https://lists.openembedded.org/g/openembedded-core/message/187005
Mute This Topic: https://lists.openembedded.org/mt/101088488/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][PATCH 1/1] gawk: fix CVE-2023-4156

2023-09-01 Thread Meenali Gupta via lists.openembedded.org
heap out of bound read in builtin.c

Signed-off-by: Meenali Gupta 
---
 .../gawk/gawk/CVE-2023-4156.patch | 46 +++
 meta/recipes-extended/gawk/gawk_5.1.1.bb  |  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch

diff --git a/meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch 
b/meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch
new file mode 100644
index 00..7becfa1dd7
--- /dev/null
+++ b/meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch
@@ -0,0 +1,46 @@
+From 75a02992e0049868d077fda26b32699465de54fc Mon Sep 17 00:00:00 2001
+From: Arnold D. Robbins 
+Date: Wed, 3 Aug 2022 15:30:54 +0530
+Subject: [PATCH] gawk: Small bug fix in builtin.c
+
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/gitweb/?p=gawk.git;a=commitdiff;h=e709eb829448ce040087a3fc5481db6bfcaae212]
+CVE: CVE-2023-4156
+
+Signed-off-by: Meenali Gupta 
+---
+ ChangeLog | 6 ++
+ builtin.c | 5 -
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 6b51464..39a5a7f 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,9 @@
++2022-08-03 Arnold D. Robbins 
++
++   * builtin.c (format_tree): When collecting positional field widths or
++   precisions, check for wrap around to negative values. Thanks to
++   YU Jiongchi  for the report.
++
+ 2021-10-27 Arnold D. Robbins 
+
+   * 5.1.1: Release tar ball made.
+diff --git a/builtin.c b/builtin.c
+index d7ba82c..4ee3f3f 100644
+--- a/builtin.c
 b/builtin.c
+@@ -963,7 +963,10 @@ check_pos:
+   s1++;
+   n0--;
+   }
+-  if (val >= num_args) {
++  // val could be less than zero if someone 
provides a field width
++   // so large that it causes integer overflow. 
Mainly fuzzers do this,
++   // but let's try to be good anyway.
++   if (val < 0 || val >= num_args) {
+   toofew = true;
+   break;
+   }
+--
+2.40.0
diff --git a/meta/recipes-extended/gawk/gawk_5.1.1.bb 
b/meta/recipes-extended/gawk/gawk_5.1.1.bb
index fe339805d0..ecc8ca3bd2 100644
--- a/meta/recipes-extended/gawk/gawk_5.1.1.bb
+++ b/meta/recipes-extended/gawk/gawk_5.1.1.bb
@@ -18,6 +18,7 @@ PACKAGECONFIG[mpfr] = "--with-mpfr,--without-mpfr, mpfr"
 SRC_URI = "${GNU_MIRROR}/gawk/gawk-${PV}.tar.gz \
file://remove-sensitive-tests.patch \
file://run-ptest \
+  file://CVE-2023-4156.patch \
"
 
 SRC_URI[sha256sum] = 
"6168d8d1dc8f74bd17d9dc22fa9634c49070f232343b744901da15fb4f06bffd"
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187004): 
https://lists.openembedded.org/g/openembedded-core/message/187004
Mute This Topic: https://lists.openembedded.org/mt/101092729/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][PATCH 1/1] busybox: fix CVE-2022-48174

2023-09-01 Thread Meenali Gupta via lists.openembedded.org
There is a stack overflow vulnerability in ash.c:6030 in busybox
vbefore 1.35. In the environment of Internet of Vehicles, this
vulnerability can be executed from command to arbitrary code execution.

Signed-off-by: Meenali Gupta 
---
 .../busybox/busybox/CVE-2022-48174.patch  | 80 +++
 meta/recipes-core/busybox/busybox_1.35.0.bb   |  1 +
 2 files changed, 81 insertions(+)
 create mode 100644 meta/recipes-core/busybox/busybox/CVE-2022-48174.patch

diff --git a/meta/recipes-core/busybox/busybox/CVE-2022-48174.patch 
b/meta/recipes-core/busybox/busybox/CVE-2022-48174.patch
new file mode 100644
index 00..dd0ea19f02
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/CVE-2022-48174.patch
@@ -0,0 +1,80 @@
+From cf5d0889262e1b04ec2aa4caff2f5da2d602c665 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Mon, 12 Jun 2023 17:48:47 +0200
+Subject: [PATCH] busybox: shell: avoid segfault on ${0::0/0~09J}. Closes 15216
+function old new delta evaluate_string 1011 1053 +42
+
+Upstream-Status: Backport 
[https://git.busybox.net/busybox/commit/?id=d417193cf37ca1005830d7e16f5fa7e1d8a44209]
+CVE: CVE-2022-48174
+
+Signed-off-by: Meenali Gupta 
+---
+ shell/math.c | 39 +++
+ 1 file changed, 35 insertions(+), 4 deletions(-)
+
+diff --git a/shell/math.c b/shell/math.c
+index 76d22c9..727c294 100644
+--- a/shell/math.c
 b/shell/math.c
+@@ -577,6 +577,28 @@ static arith_t strto_arith_t(const char *nptr, char 
**endptr)
+ # endif
+ #endif
+
++//TODO: much better estimation than expr_len/2? Such as:
++//static unsigned estimate_nums_and_names(const char *expr)
++//{
++//unsigned count = 0;
++//while (*(expr = skip_whitespace(expr)) != '\0') {
++//const char *p;
++//if (isdigit(*expr)) {
++//while (isdigit(*++expr))
++//continue;
++//count++;
++//continue;
++//}
++//p = endofname(expr);
++//if (p != expr) {
++//expr = p;
++//count++;
++//continue;
++//}
++//}
++//return count;
++//}
++
+ static arith_t
+ evaluate_string(arith_state_t *math_state, const char *expr)
+ {
+@@ -584,10 +606,12 @@ evaluate_string(arith_state_t *math_state, const char 
*expr)
+   const char *errmsg;
+   const char *start_expr = expr = skip_whitespace(expr);
+   unsigned expr_len = strlen(expr) + 2;
+-  /* Stack of integers */
+-  /* The proof that there can be no more than strlen(startbuf)/2+1
+-   * integers in any given correct or incorrect expression
+-   * is left as an exercise to the reader. */
++  /* Stack of integers/names */
++  /* There can be no more than strlen(startbuf)/2+1
++   * integers/names in any given correct or incorrect expression.
++   * (modulo "09v09v09v09v09v" case,
++   * but we have code to detect that early)
++   */
+   var_or_num_t *const numstack = alloca((expr_len / 2) * 
sizeof(numstack[0]));
+   var_or_num_t *numstackptr = numstack;
+   /* Stack of operator tokens */
+@@ -652,6 +676,13 @@ evaluate_string(arith_state_t *math_state, const char 
*expr)
+   numstackptr->var = NULL;
+   errno = 0;
+   numstackptr->val = strto_arith_t(expr, (char**) );
++  /* A number can't be followed by another number, or a 
variable name.
++   * We'd catch this later anyway, but this would require 
numstack[]
++   * to be twice as deep to handle strings where _every_ 
char is
++   * a new number or name. Example: 
09v09v09v09v09v09v09v09v09v
++   */
++  if (isalnum(*expr) || *expr == '_')
++  goto err;
+ //bb_error_msg("val:%lld", numstackptr->val);
+   if (errno)
+   numstackptr->val = 0; /* bash compat */
+--
+2.40.0
diff --git a/meta/recipes-core/busybox/busybox_1.35.0.bb 
b/meta/recipes-core/busybox/busybox_1.35.0.bb
index e9ca6fdb1a..07a5137d2a 100644
--- a/meta/recipes-core/busybox/busybox_1.35.0.bb
+++ b/meta/recipes-core/busybox/busybox_1.35.0.bb
@@ -51,6 +51,7 @@ SRC_URI = 
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \

file://0002-nslookup-sanitize-all-printed-strings-with-printable.patch \
file://CVE-2022-30065.patch \
file://0001-devmem-add-128-bit-width.patch \
+  file://CVE-2022-48174.patch \
"
 SRC_URI:append:libc-musl = " file://musl.cfg "
 
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187003): 
https://lists.openembedded.org/g/openembedded-core/message/187003
Mute This Topic: https://lists.openembedded.org/mt/101092688/21656
Group Owner: 

Re: [OE-core] [PATCH] insane.bbclass: introduce SIGILL finder

2023-09-01 Thread Ross Burton
On 31 Aug 2023, at 10:16, Benjamin Bara via lists.openembedded.org 
 wrote:
> 
> From: Benjamin Bara 
> 
> This commit should look for unsupported instructions depending on the
> active tune features. For now, it checks for vfpv3d16 and other non-neon
> machines, but it can be easily extended for other architectures/checks.
> 
> Reason for this check is that a couple of packages assume neon support
> for armv7, but it is actually optional.

Presumably this will trigger on recipes which generate the code for all the 
extended instructions (neon, sve, etc) and pick and runtime what functions to 
run?

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187002): 
https://lists.openembedded.org/g/openembedded-core/message/187002
Mute This Topic: https://lists.openembedded.org/mt/101070322/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] [master] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

2023-09-01 Thread Peter Marko via lists.openembedded.org
What's the reason for ignoring this CVE in all branches when CVE_PRODUCT = 
"flex_project:flex" means it's not reported by cve-check?
Peter

-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Dhairya Nagodra via 
lists.openembedded.org
Sent: Friday, September 1, 2023 6:15
To: Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at Cisco) 
; openembedded-core@lists.openembedded.org; Steve Sakoman 
; richard.pur...@linuxfoundation.org
Cc: qi.c...@windriver.com; xe-linux-external(mailer list) 
; st...@sakoman.com
Subject: Re: [OE-core] [master] [PATCH] flex: Exclude CVE-2015-1773 from 
cve-check.

> Hi @Steve Sakoman @richard.pur...@linuxfoundation.org,
>
> Kindly consider this patch for "master" branch.
> Apologies for the error.
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Dhairya Nagodra via 
> > lists.openembedded.org
> > Sent: Friday, September 1, 2023 9:38 AM
> > To: openembedded-core@lists.openembedded.org
> > Cc: qi.c...@windriver.com; xe-linux-external(mailer list)  > exter...@cisco.com>; Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC 
> > at
> > Cisco) 
> > Subject: [OE-core] [dunfell] [PATCH] flex: Exclude CVE-2015-1773 from 
> > cve- check.
> > 
> > Issue only affects Apache.
> > 
> > Signed-off-by: Dhairya Nagodra 
> > ---
> >  meta/recipes-devtools/flex/flex_2.6.4.bb | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb b/meta/recipes- 
> > devtools/flex/flex_2.6.4.bb index 1ac88d65ef..5be7351f4c 100644
> > --- a/meta/recipes-devtools/flex/flex_2.6.4.bb
> > +++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
> > @@ -31,6 +31,8 @@ CVE_STATUS[CVE-2019-6293] = "upstream-wontfix: \ 
> > there is stack exhaustion but no bug and it is building the \  parser, 
> > not running it, effectively similar to a compiler ICE. Upstream no 
> > plans to address this."
> > 
> > +CVE_STATUS[CVE-2015-1773] = "not-applicable-platform: Issue only 
> > +affects
> > Apache."
> > +
> >  inherit autotools gettext texinfo ptest github-releases
> > 
> >  M4 = "${bindir}/m4"
> > --
> > 2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187001): 
https://lists.openembedded.org/g/openembedded-core/message/187001
Mute This Topic: https://lists.openembedded.org/mt/101088488/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 1/2] distcc: Fix groupname gid change warning

2023-09-01 Thread Alexandre Belloni via lists.openembedded.org
Hello,

This fails on the autobuilders:

https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3449/steps/12/logs/stdio

ERROR: Nothing RPROVIDES 'distcc' (but 
/home/pokybuild/yocto-worker/reproducible/build/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb,
 
/home/pokybuild/yocto-worker/reproducible/build/meta/recipes-devtools/devel-config/distcc-config.bb
 RDEPENDS on or otherwise requires it)
distcc was skipped: Recipe distcc, package distcc-server: system groupname 
"nogroup" does not have a static ID defined. Add nogroup to one of these files: 
/home/pokybuild/yocto-worker/reproducible/build/build-st/meta-selftest/files/static-group


On 31/08/2023 09:23:04-0500, JD Schroeder wrote:
> This patch fixes warnings when useradd-staticids.bbclass is used and
> USERADD_PARAM is used to add the user to a group that has not been
> explicitly created yet. By adding the GROUPADD_PARAM for the new group
> being used the warnings for changing the gid from GID-OLD to GID-NEW
> is eliminated.
> 
> Warning fixed:
> distcc: Changing groupname nogroup's gid from (WXYZ) to (JKLM), verify 
> configuration files!
> 
> Signed-off-by: JD Schroeder 
> ---
>  meta/recipes-devtools/distcc/distcc_3.4.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-devtools/distcc/distcc_3.4.bb 
> b/meta/recipes-devtools/distcc/distcc_3.4.bb
> index 45fc7cde53..0c20f74d68 100644
> --- a/meta/recipes-devtools/distcc/distcc_3.4.bb
> +++ b/meta/recipes-devtools/distcc/distcc_3.4.bb
> @@ -33,6 +33,7 @@ EXTRA_OECONF += "--disable-Werror PYTHON='' 
> --disable-pump-mode"
>  PACKAGE_BEFORE_PN = "${PN}-distmon-gnome ${PN}-server"
>  
>  USERADD_PACKAGES = "${PN}-server"
> +GROUPADD_PARAM:${PN}-server = "--system nogroup"
>  USERADD_PARAM:${PN}-server = "--system \
> --home /dev/null \
> --no-create-home \
> -- 
> 2.37.0
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187000): 
https://lists.openembedded.org/g/openembedded-core/message/187000
Mute This Topic: https://lists.openembedded.org/mt/101074670/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] json-c: upgrade 0.16 -> 0.17

2023-09-01 Thread Alexandre Belloni via lists.openembedded.org
New ptest failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/5537/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/5354/steps/13/logs/stdio

'json-c': ['test_json_patch.test']


On 31/08/2023 10:31:56+0800, wangmy wrote:
> From: Wang Mingyu 
> 
> 0001-Fix-build-with-clang-15.patch
> removed since it's included in 0.17.
> 
> Changelog:
> ===
> New features
> 
> * json_patch: add first implementation only with patch application
> * Add --disable-static and --disable-dynamic options to the cmake-configure 
> script.
> * Add -DBUILD_APPS=NO option to disable app build
> * Minimum cmake version is now 3.9
> 
> Significant changes and bug fixes
> -
> * When serializing with JSON_C_TO_STRING_PRETTY set, keep the opening and
>   closing curly or square braces on same line for empty objects or arrays.
> * Disable locale handling when targeting a uClibc system due to problems
>   with its duplocale() function.
> * When parsing with JSON_TOKENER_STRICT set, integer overflow/underflow
>   now result in a json_tokener_error_parse_number.  Without that flag
>   values are capped at INT64_MIN/UINT64_MAX.
> * Fix memory leak with emtpy strings in json_object_set_string
> * json_object_from_fd_ex: fail if file is too large (>=INT_MAX bytes)
> * Add back json_number_chars, but only because it's part of the public API.
> * Entirely drop mode bits from open(O_RDONLY) to avoid warnings on certain
>   platforms.
> * Specify dependent libraries, including -lbsd, in a more consistent way so
>   linking against a static json-c works better
> * Fix a variety of build problems and add & improve tests
> * Update RFC reference to https://www.rfc-editor.org/rfc/rfc8259
> 
> Signed-off-by: Wang Mingyu 
> ---
>  .../json-c/0001-Fix-build-with-clang-15.patch | 34 ---
>  .../json-c/{json-c_0.16.bb => json-c_0.17.bb} | 10 +++---
>  2 files changed, 4 insertions(+), 40 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/json-c/json-c/0001-Fix-build-with-clang-15.patch
>  rename meta/recipes-devtools/json-c/{json-c_0.16.bb => json-c_0.17.bb} (78%)
> 
> diff --git 
> a/meta/recipes-devtools/json-c/json-c/0001-Fix-build-with-clang-15.patch 
> b/meta/recipes-devtools/json-c/json-c/0001-Fix-build-with-clang-15.patch
> deleted file mode 100644
> index 215f4d829a..00
> --- a/meta/recipes-devtools/json-c/json-c/0001-Fix-build-with-clang-15.patch
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -From 0145b575ac1fe6a77e00d639864f26fc91ceb12f Mon Sep 17 00:00:00 2001
> -From: Khem Raj 
> -Date: Sat, 13 Aug 2022 20:37:03 -0700
> -Subject: [PATCH] Fix build with clang-15+
> -
> -Fixes
> -json_util.c:63:35: error: a function declaration without a prototype is 
> deprecated in all versions of C [-We
> -rror,-Wstrict-prototypes]
> -const char *json_util_get_last_err()
> -  ^
> -   void
> -
> -Upstream-Status: Backport [https://github.com/json-c/json-c/pull/783]
> -Signed-off-by: Khem Raj 
> 
> - json_util.c | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/json_util.c b/json_util.c
> -index 952770a..83d9c68 100644
>  a/json_util.c
> -+++ b/json_util.c
> -@@ -60,7 +60,7 @@ static int _json_object_to_fd(int fd, struct json_object 
> *obj, int flags, const
> - 
> - static char _last_err[256] = "";
> - 
> --const char *json_util_get_last_err()
> -+const char *json_util_get_last_err(void)
> - {
> - if (_last_err[0] == '\0')
> - return NULL;
> --- 
> -2.37.2
> -
> diff --git a/meta/recipes-devtools/json-c/json-c_0.16.bb 
> b/meta/recipes-devtools/json-c/json-c_0.17.bb
> similarity index 78%
> rename from meta/recipes-devtools/json-c/json-c_0.16.bb
> rename to meta/recipes-devtools/json-c/json-c_0.17.bb
> index 3aba41dfcf..aff5ad5076 100644
> --- a/meta/recipes-devtools/json-c/json-c_0.16.bb
> +++ b/meta/recipes-devtools/json-c/json-c_0.17.bb
> @@ -4,12 +4,10 @@ HOMEPAGE = "https://github.com/json-c/json-c/wiki;
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
>  
> -SRC_URI = " \
> -https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz \
> -file://0001-Fix-build-with-clang-15.patch \
> -file://run-ptest \
> -"
> -SRC_URI[sha256sum] = 
> "8e45ac8f96ec7791eaf3bb7ee50e9c2100bbbc87b8d0f1d030c5ba8a0288d96b"
> +SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz \
> +   file://run-ptest \
> +   "
> +SRC_URI[sha256sum] = 
> "7550914d58fb63b2c3546f3ccfbe11f1c094147bd31a69dcd23714d7956159e6"
>  
>  UPSTREAM_CHECK_URI = "https://github.com/${BPN}/${BPN}/tags;
>  UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+)-\d+"
> -- 
> 2.34.1
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

Re: [OE-core] [dunfell] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

2023-09-01 Thread Peter Marko via lists.openembedded.org
-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Dhairya Nagodra via 
lists.openembedded.org
Sent: Friday, September 1, 2023 6:08
To: openembedded-core@lists.openembedded.org
Cc: qi.c...@windriver.com; xe-linux-exter...@cisco.com; Dhairya Nagodra 

Subject: [OE-core] [dunfell] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

> Issue only affects Apache.
>
> Signed-off-by: Dhairya Nagodra 
> ---
>  meta/recipes-devtools/flex/flex_2.6.4.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb 
> b/meta/recipes-devtools/flex/flex_2.6.4.bb
> index 1ac88d65ef..5be7351f4c 100644
> --- a/meta/recipes-devtools/flex/flex_2.6.4.bb
> +++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
> @@ -31,6 +31,8 @@ CVE_STATUS[CVE-2019-6293] = "upstream-wontfix: \  there is 
> stack exhaustion but no bug and it is building the \  parser, not running it, 
> effectively similar to a compiler ICE. Upstream no plans to address this."
>  
> +CVE_STATUS[CVE-2015-1773] = "not-applicable-platform: Issue only affects 
> Apache."

dunfell does not support CVE_STATUS flags, you need to use CVE_CHECK_WHITELIST

Additionally, this CVE is not reported for current dunfell version as 
CVE_PRODUCT is set correctly.

> +
>  inherit autotools gettext texinfo ptest github-releases
>  
>  M4 = "${bindir}/m4"
> --
> 2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186998): 
https://lists.openembedded.org/g/openembedded-core/message/186998
Mute This Topic: https://lists.openembedded.org/mt/101088411/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][PATCH 1/1] ncurses: fix CVE-2023-29491

2023-09-01 Thread Soumya via lists.openembedded.org
From: Soumya Sambu 

Backport patch to fix CVE-2023-29491.

Signed-off-by: Soumya Sambu 
---
 .../ncurses/files/CVE-2023-29491.patch| 464 ++
 .../ncurses/ncurses_6.3+20220423.bb   |   1 +
 2 files changed, 465 insertions(+)
 create mode 100644 meta/recipes-core/ncurses/files/CVE-2023-29491.patch

diff --git a/meta/recipes-core/ncurses/files/CVE-2023-29491.patch 
b/meta/recipes-core/ncurses/files/CVE-2023-29491.patch
new file mode 100644
index 00..957ff9b8b2
--- /dev/null
+++ b/meta/recipes-core/ncurses/files/CVE-2023-29491.patch
@@ -0,0 +1,464 @@
+From eb51b1ea1f75a0ec17c9c5937cb28df1e8eeec56 Mon Sep 17 00:00:00 2001
+From: Thomas E. Dickey 
+Date: Sun, 9 Apr 2023 05:38:25 +0530
+Subject: [PATCH] Fix CVE-2023-29491
+
+CVE: CVE-2023-29491
+
+Upstream-Status: Backport 
[http://ncurses.scripts.mit.edu/?p=ncurses.git;a=commitdiff;h=eb51b1ea1f75a0ec17c9c5937cb28df1e8eeec56]
+
+Signed-off-by: Chen Qi 
+
+Signed-off-by: Soumya Sambu 
+---
+ ncurses/tinfo/lib_tgoto.c  |  10 +++-
+ ncurses/tinfo/lib_tparm.c  | 116 -
+ ncurses/tinfo/read_entry.c |   3 +
+ progs/tic.c|   6 ++
+ progs/tparm_type.c |   9 +++
+ progs/tparm_type.h |   2 +
+ progs/tput.c   |  61 ---
+ 7 files changed, 185 insertions(+), 22 deletions(-)
+
+diff --git a/ncurses/tinfo/lib_tgoto.c b/ncurses/tinfo/lib_tgoto.c
+index 9cf5e100..c50ed4df 100644
+--- a/ncurses/tinfo/lib_tgoto.c
 b/ncurses/tinfo/lib_tgoto.c
+@@ -207,6 +207,14 @@ tgoto(const char *string, int x, int y)
+   result = tgoto_internal(string, x, y);
+ else
+ #endif
+-  result = TIPARM_2(string, y, x);
++if ((result = TIPARM_2(string, y, x)) == NULL) {
++  /*
++   * Because termcap did not provide a more general solution such as
++   * tparm(), it was necessary to handle single-parameter capabilities
++   * using tgoto().  The internal _nc_tiparm() function returns a NULL
++   * for that case; retry for the single-parameter case.
++   */
++  result = TIPARM_1(string, y);
++}
+ returnPtr(result);
+ }
+diff --git a/ncurses/tinfo/lib_tparm.c b/ncurses/tinfo/lib_tparm.c
+index d9bdfd8f..a10a3877 100644
+--- a/ncurses/tinfo/lib_tparm.c
 b/ncurses/tinfo/lib_tparm.c
+@@ -1086,6 +1086,64 @@ tparam_internal(TPARM_STATE *tps, const char *string, 
TPARM_DATA *data)
+ return (TPS(out_buff));
+ }
+ 
++#ifdef CUR
++/*
++ * Only a few standard capabilities accept string parameters.  The others that
++ * are parameterized accept only numeric parameters.
++ */
++static bool
++check_string_caps(TPARM_DATA *data, const char *string)
++{
++bool result = FALSE;
++
++#define CHECK_CAP(name) (VALID_STRING(name) && !strcmp(name, string))
++
++/*
++ * Disallow string parameters unless we can check them against a terminal
++ * description.
++ */
++if (cur_term != NULL) {
++  int want_type = 0;
++
++  if (CHECK_CAP(pkey_key))
++  want_type = 2;  /* function key #1, type string #2 */
++  else if (CHECK_CAP(pkey_local))
++  want_type = 2;  /* function key #1, execute string #2 */
++  else if (CHECK_CAP(pkey_xmit))
++  want_type = 2;  /* function key #1, transmit string #2 */
++  else if (CHECK_CAP(plab_norm))
++  want_type = 2;  /* label #1, show string #2 */
++  else if (CHECK_CAP(pkey_plab))
++  want_type = 6;  /* function key #1, type string #2, show string 
#3 */
++#if NCURSES_XNAMES
++  else {
++  char *check;
++
++  check = tigetstr("Cs");
++  if (CHECK_CAP(check))
++  want_type = 1;  /* style #1 */
++
++  check = tigetstr("Ms");
++  if (CHECK_CAP(check))
++  want_type = 3;  /* storage unit #1, content #2 */
++  }
++#endif
++
++  if (want_type == data->tparm_type) {
++  result = TRUE;
++  } else {
++  T(("unexpected string-parameter"));
++  }
++}
++return result;
++}
++
++#define ValidCap() (myData.tparm_type == 0 || \
++  check_string_caps(, string))
++#else
++#define ValidCap() 1
++#endif
++
+ #if NCURSES_TPARM_VARARGS
+ 
+ NCURSES_EXPORT(char *)
+@@ -1100,7 +1158,7 @@ tparm(const char *string, ...)
+ tps->tname = "tparm";
+ #endif /* TRACE */
+ 
+-if (tparm_setup(cur_term, string, ) == OK) {
++if (tparm_setup(cur_term, string, ) == OK && ValidCap()) {
+   va_list ap;
+ 
+   va_start(ap, string);
+@@ -1135,7 +1193,7 @@ tparm(const char *string,
+ tps->tname = "tparm";
+ #endif /* TRACE */
+ 
+-if (tparm_setup(cur_term, string, ) == OK) {
++if (tparm_setup(cur_term, string, ) == OK && ValidCap()) {
+ 
+   myData.param[0] = a1;
+   myData.param[1] = a2;
+@@ -1166,7 +1224,7 @@ tiparm(const char *string, ...)
+ tps->tname = "tiparm";
+ #endif /* TRACE */
+ 
+-if (tparm_setup(cur_term, string, ) == OK) {
++if (tparm_setup(cur_term, 

Re: [OE-core] [PATCH] sqlite3: set CVE_STATUS for CVE-2023-36191

2023-09-01 Thread Peter Marko via lists.openembedded.org
-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Changqing Li via 
lists.openembedded.org
Sent: Friday, September 1, 2023 11:02
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] sqlite3: set CVE_STATUS for CVE-2023-36191

> From: Changqing Li 
>
> The error is a bug. It has been fixed upstream. But it is not a 
> vulnerability. You may safely ignore the CVE.
>
> Refer:
> [1] https://www.sqlite.org/forum/forumpost/19f55ef73b
>
> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-support/sqlite/sqlite3_3.42.0.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-support/sqlite/sqlite3_3.42.0.bb 
> b/meta/recipes-support/sqlite/sqlite3_3.42.0.bb
> index 8783f620f4..b37644580c 100644
> --- a/meta/recipes-support/sqlite/sqlite3_3.42.0.bb
> +++ b/meta/recipes-support/sqlite/sqlite3_3.42.0.bb
> @@ -6,3 +6,5 @@ LIC_FILES_CHKSUM = 
> "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
>  SRC_URI = "http://www.sqlite.org/2023/sqlite-autoconf-${SQLITE_PV}.tar.gz;
>  SRC_URI[sha256sum] = 
> "7abcfd161c6e2742ca5c6c0895d1f853c940f203304a0b49da4e1eca5d088ca6"
>  
> +CVE_STATUS[CVE-2023-36191] = "The error is a bug. It has been fixed 
> upstream. But it is not a vulnerability"

This is wrong format since it's missing CVE status map prefix.
It needs to be something like:
CVE_STATUS[CVE-2023-36191] = "disputed: The error is a bug. It has been fixed 
upstream. But it is not a vulnerability"

Also since this CVE is reported in NVD DB for 3.40.1 only, this CVE exclusion 
is not needed for 3.42.0 recipe.

> +
> --
> 2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186996): 
https://lists.openembedded.org/g/openembedded-core/message/186996
Mute This Topic: https://lists.openembedded.org/mt/101090960/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] sqlite3: set CVE_STATUS for CVE-2023-36191

2023-09-01 Thread Changqing Li
From: Changqing Li 

The error is a bug. It has been fixed upstream. But it is not a
vulnerability. You may safely ignore the CVE.

Refer:
[1] https://www.sqlite.org/forum/forumpost/19f55ef73b

Signed-off-by: Changqing Li 
---
 meta/recipes-support/sqlite/sqlite3_3.42.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/sqlite/sqlite3_3.42.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.42.0.bb
index 8783f620f4..b37644580c 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.42.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.42.0.bb
@@ -6,3 +6,5 @@ LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
 SRC_URI = "http://www.sqlite.org/2023/sqlite-autoconf-${SQLITE_PV}.tar.gz;
 SRC_URI[sha256sum] = 
"7abcfd161c6e2742ca5c6c0895d1f853c940f203304a0b49da4e1eca5d088ca6"
 
+CVE_STATUS[CVE-2023-36191] = "The error is a bug. It has been fixed upstream. 
But it is not a vulnerability"
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186995): 
https://lists.openembedded.org/g/openembedded-core/message/186995
Mute This Topic: https://lists.openembedded.org/mt/101090960/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] generate-cve-exclusions.py: boundary-value error?

2023-09-01 Thread Yuta Hayama
Hi,

I have been trying Linux Kernel CVEs for a while now and found a weird part in
generate-cve-exclusions.py.

https://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/generate-cve-exclusions.py#n64

>affected = data["affected_versions"]
>first_affected, last_affected = re.search(r"(.+) to (.+)", 
> affected).groups()
>first_affected = parse_version(first_affected)
>last_affected = parse_version(last_affected)
>
>if not last_affected:
>print(f"# {cve} has no known resolution")
>elif first_affected and version < first_affected:
>print(f'CVE_STATUS[{cve}] = "fixed-version: only affects 
> {first_affected} onwards"')
>elif last_affected < version:
>print(
>f'CVE_STATUS[{cve}] = "fixed-version: Fixed after version 
> {last_affected}"'

generate-cve-exclusions.py interprets "affected_versions" in kernel_cves.json
literally as "first affected version" to "last affected version". However,
"affected_versions" may actually mean "first affected version" to "fixed 
version".

I honestly don't know what's going on here, as I can't find any documentation
for Linux Kernel CVEs. But, picking up a random CVE and checking it in detail,
I think the second element in "affected_versions" is actually a "fixed version".

Some examples.

[CVE-2023-28327]
* In kernel_cves.json, "affected_versions" is described as "v5.3-rc1 to v6.1"
* the patch is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3abe42e94900bdd045c472f9c9be620ba5ce553
* v6.1-rc8 source is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/unix/diag.c?h=v6.1-rc8#n117
* v6.1 source is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/unix/diag.c?h=v6.1#n117
* It seems to be fixed in 6.1 (not after 6.1).

[CVE-2021-3772]
* In kernel_cves.json, "affected_versions" is described as "v2.6.12-rc2 to 
v5.15"
* the patch is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f7019c7eb33967eb87766e0e4602b5576873680
* v5.15-rc7 source is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/sctp/sm_statefuns.c?h=v5.15-rc7#n6350
* v5.15 source is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/sctp/sm_statefuns.c?h=v5.15#n6380
* It seems to be fixed in 5.15 (not after 5.15).

[CVE-2022-39190]
* In kernel_cves.json, "affected_versions" is described as "v5.9-rc1 to 
v6.0-rc3"
* the patch is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e02f0d3970404bfea385b6edb86f2d936db0ea2b
* v6.0-rc2 source is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_tables_api.c?h=v6.0-rc2#n9708
* v6.0-rc3 source is 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_tables_api.c?h=v6.0-rc3#n9712
* It seems to be fixed in v6.0-rc3 (not after v6.0-rc3).

If the assumption is correct, I will try to write a patch.

Note that in reality, I think there are very few cases of error.

>elif last_affected < version:
>print(
>f'CVE_STATUS[{cve}] = "fixed-version: Fixed after version 
> {last_affected}"'

The last_affected here is the major version (in short, the last_affected is x.y,
not x.y.z), so there is a possibility of error only if version is the major
version. But actually, in most cases, version is x.y.z.

Regards,

Yuta Hayama

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186994): 
https://lists.openembedded.org/g/openembedded-core/message/186994
Mute This Topic: https://lists.openembedded.org/mt/101089426/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-