Re: [OE-core] [PATCH 2/2] selftest/sstatetests: add a test for CDN sstate cache

[Alexandre Belloni via lists.openembedded.org]

Hello Alex,

This doesn't apply cleanly, it seems the context is from another series.

On 20/10/2023 19:12:32+0200, Alexander Kanavin wrote:
> Specifically, the test checks that everything needed for building
> standard oe-core images for x86_64 and arm64 is available from
> the cache (with minor exceptions). Going forward, a complete
> world check could be enabled and additional configurations,
> but that requires improvements to performance of hash equivalence
> server in particular.
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/lib/oeqa/selftest/cases/sstatetests.py | 47 +
>  1 file changed, 47 insertions(+)
> 
> diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
> b/meta/lib/oeqa/selftest/cases/sstatetests.py
> index 6ef339897bf..e392d6a1a63 100644
> --- a/meta/lib/oeqa/selftest/cases/sstatetests.py
> +++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
> @@ -14,6 +14,7 @@ import re
>  
>  from oeqa.utils.commands import runCmd, bitbake, get_bb_var, 
> create_temp_layer, get_bb_vars
>  from oeqa.selftest.case import OESelftestTestCase
> +from oeqa.core.decorator import OETestTag
>  
>  import oe
>  import bb.siggen
> @@ -879,3 +880,49 @@ expected_sametmp_output, expected_difftmp_output)
>  INHERIT += "base-do-configure-modified"
>  """,
>  expected_sametmp_output, expected_difftmp_output)
> +
> +@OETestTag("yocto-mirrors")
> +class SStateMirrors(SStateBase):
> +def check_bb_output(self, output, exceptions):
> +in_tasks = False
> +missing_objects = []
> +for l in output.splitlines():
> +if "The differences between the current build and any cached 
> tasks start at the following tasks" in l:
> +in_tasks = True
> +continue
> +if "Writing task signature files" in l:
> +in_tasks = False
> +continue
> +if in_tasks:
> +recipe_task = l.split("/")[-1]
> +recipe, task = recipe_task.split(":")
> +for e in exceptions:
> +if e[0] in recipe and task == e[1]:
> +break
> +else:
> +missing_objects.append(recipe_task)
> +self.assertTrue(len(missing_objects) == 0, "Missing objects in the 
> cache:\n{}".format("\n".join(missing_objects)))
> +
> +
> +def run_test_cdn_mirror(self, machine, targets, exceptions):
> +exceptions = exceptions + [[t, "do_deploy_source_date_epoch"] for t 
> in targets.split()]
> +exceptions = exceptions + [[t, "do_image_qa"] for t in 
> targets.split()]
> +self.config_sstate(True)
> +self.append_config("""
> +MACHINE = "{}"
> +BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
> +SSTATE_MIRRORS ?= "file://.* 
> http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH;
> +""".format(machine))
> +result = bitbake("-S printdiff {}".format(targets))
> +self.check_bb_output(result.output, exceptions)
> +
> +def test_cdn_mirror_qemux86_64(self):
> +# Example:
> +# exceptions = [ ["packagegroup-core-sdk","do_package"] ]
> +exceptions = []
> +self.run_test_cdn_mirror("qemux86-64", "core-image-minimal 
> core-image-full-cmdline core-image-weston core-image-sato-sdk", exceptions)
> +
> +def test_cdn_mirror_qemuarm64(self):
> +exceptions = []
> +# core-image-weston isn't produced for arm64 currently
> +self.run_test_cdn_mirror("qemuarm64", "core-image-minimal 
> core-image-full-cmdline core-image-sato-sdk", exceptions)
> -- 
> 2.39.2
> 

> 
> 
> 


-- 
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 (#189581): 
https://lists.openembedded.org/g/openembedded-core/message/189581
Mute This Topic: https://lists.openembedded.org/mt/102085736/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][mickledore][PATCH] grub2: fix CVE-2023-4692

[Alexandre Belloni via lists.openembedded.org]

Hello,

This doesn't apply on master, can you rebase?

On 20/10/2023 16:09:14+0800, Xiangyu Chen wrote:
> From: Xiangyu Chen 
> 
> Crafted file system images can cause heap-based buffer overflow and may
> allow arbitrary code execution and secure boot bypass
> 
> Reference:
> https://security-tracker.debian.org/tracker/CVE-2023-4692
> 
> Signed-off-by: Xiangyu Chen 
> ---
>  .../grub/files/CVE-2023-4692.patch| 98 +++
>  meta/recipes-bsp/grub/grub2.inc   |  1 +
>  2 files changed, 99 insertions(+)
>  create mode 100644 meta/recipes-bsp/grub/files/CVE-2023-4692.patch
> 
> diff --git a/meta/recipes-bsp/grub/files/CVE-2023-4692.patch 
> b/meta/recipes-bsp/grub/files/CVE-2023-4692.patch
> new file mode 100644
> index 00..305fcc93d8
> --- /dev/null
> +++ b/meta/recipes-bsp/grub/files/CVE-2023-4692.patch
> @@ -0,0 +1,98 @@
> +From 43651027d24e62a7a463254165e1e46e42aecdea Mon Sep 17 00:00:00 2001
> +From: Maxim Suhanov 
> +Date: Mon, 28 Aug 2023 16:31:57 +0300
> +Subject: [PATCH] fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST 
> attribute
> + for the $MFT file
> +
> +When parsing an extremely fragmented $MFT file, i.e., the file described
> +using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer
> +containing bytes read from the underlying drive to store sector numbers,
> +which are consumed later to read data from these sectors into another buffer.
> +
> +These sectors numbers, two 32-bit integers, are always stored at predefined
> +offsets, 0x10 and 0x14, relative to first byte of the selected entry within
> +the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem.
> +
> +However, when parsing a specially-crafted file system image, this may cause
> +the NTFS code to write these integers beyond the buffer boundary, likely
> +causing the GRUB memory allocator to misbehave or fail. These integers 
> contain
> +values which are controlled by on-disk structures of the NTFS file system.
> +
> +Such modification and resulting misbehavior may touch a memory range not
> +assigned to the GRUB and owned by firmware or another EFI application/driver.
> +
> +This fix introduces checks to ensure that these sector numbers are never
> +written beyond the boundary.
> +
> +Fixes: CVE-2023-4692
> +
> +Upstream-Status: Backport from 
> +[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=43651027d24e62a7a463254165e1e46e42aecdea]
> +CVE: CVE-2023-4692
> +
> +Reported-by: Maxim Suhanov 
> +Signed-off-by: Maxim Suhanov 
> +Reviewed-by: Daniel Kiper 
> +Signed-off-by: Xiangyu Chen 
> +---
> + grub-core/fs/ntfs.c | 18 +-
> + 1 file changed, 17 insertions(+), 1 deletion(-)
> +
> +diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
> +index bbdbe24..c3c4db1 100644
> +--- a/grub-core/fs/ntfs.c
>  b/grub-core/fs/ntfs.c
> +@@ -184,7 +184,7 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
> + }
> +   if (at->attr_end)
> + {
> +-  grub_uint8_t *pa;
> ++  grub_uint8_t *pa, *pa_end;
> + 
> +   at->emft_buf = grub_malloc (at->mft->data->mft_size << 
> GRUB_NTFS_BLK_SHR);
> +   if (at->emft_buf == NULL)
> +@@ -209,11 +209,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t 
> attr)
> + }
> +   at->attr_nxt = at->edat_buf;
> +   at->attr_end = at->edat_buf + u32at (pa, 0x30);
> ++  pa_end = at->edat_buf + n;
> + }
> +   else
> + {
> +   at->attr_nxt = at->attr_end + u16at (pa, 0x14);
> +   at->attr_end = at->attr_end + u32at (pa, 4);
> ++  pa_end = at->mft->buf + (at->mft->data->mft_size << 
> GRUB_NTFS_BLK_SHR);
> + }
> +   at->flags |= GRUB_NTFS_AF_ALST;
> +   while (at->attr_nxt < at->attr_end)
> +@@ -230,6 +232,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
> +   at->flags |= GRUB_NTFS_AF_GPOS;
> +   at->attr_cur = at->attr_nxt;
> +   pa = at->attr_cur;
> ++
> ++  if ((pa >= pa_end) || (pa_end - pa < 0x18))
> ++{
> ++  grub_error (GRUB_ERR_BAD_FS, "can\'t parse attribute list");
> ++  return NULL;
> ++}
> ++
> +   grub_set_unaligned32 ((char *) pa + 0x10,
> + grub_cpu_to_le32 (at->mft->data->mft_start));
> +   grub_set_unaligned32 ((char *) pa + 0x14,
> +@@ -240,6 +249,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
> + {
> +   if (*pa != attr)
> + break;
> ++
> ++  if ((pa >= pa_end) || (pa_end - pa < 0x18))
> ++{
> ++  grub_error (GRUB_ERR_BAD_FS, "can\'t parse attribute list");
> ++  return NULL;
> ++}
> ++
> +   if (read_attr
> +   (at, pa + 0x10,
> +u32at (pa, 0x10) * (at->mft->data->mft_size << 
> GRUB_NTFS_BLK_SHR),
> +-- 
> +cgit v1.1
> +
> diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
> index 41839698dc..5ce8699363 100644
> --- 

[OE-core] [PATCH] openssl: Match target name for riscv64/riscv32

[Khem Raj]

This is updated in openssl [1] [2] since opensssl 3.2 onwards

[1] 
https://github.com/openssl/openssl/commit/42ee6e7be43c57136d71e5612fed22a06f7f5d0e
[2] 
https://github.com/openssl/openssl/commit/c29554245ae107c87d71c8463eef0134391da318

Signed-off-by: Khem Raj 
---
 meta/recipes-connectivity/openssl/openssl_3.1.3.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_3.1.3.bb 
b/meta/recipes-connectivity/openssl/openssl_3.1.3.bb
index 5bbafcfd3f6..5432d9dd8c2 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.1.3.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.1.3.bb
@@ -119,10 +119,10 @@ do_configure () {
target=linux-ppc64le
;;
linux-riscv32)
-   target=linux-latomic
+   target=linux32-riscv32
;;
linux-riscv64)
-   target=linux-generic64
+   target=linux64-riscv64
;;
linux-sparc | linux-supersparc)
target=linux-sparcv9
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189579): 
https://lists.openembedded.org/g/openembedded-core/message/189579
Mute This Topic: https://lists.openembedded.org/mt/102087698/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][mickledore][PATCH] weston: default to launcher-seatd

[Steve Sakoman]

On Fri, Oct 20, 2023 at 7:26 AM  wrote:
>
> Quoting Steve Sakoman :
>
> > On Thu, Oct 19, 2023 at 3:28 AM Sean Nyekjaer  wrote:
> >>
> >> Lets use the launcher-seatd as default, launcher-logind is "sometimes"
> >> failing to provide input events. Further more is the launcher-logind
> >> depricated in newer versions of weston.
> >
> > Changing behaviour is typically not allowed in stable branches.
> >
> > In any event, this change would need to go into the master branch
> > before it could be backported to stable branches. So please submit
> > this for the master branch!
> >
> > Steve
>
> Hi Steve,
>
> It is part of the master branch be7da75 “weston: update 11.0.1 - 12.0.1”

OK, then no need to submit for master :-)

I'm still not able to take this for mickledore though, since it would
cause a behaviour change for people already shipping product with
mickledore.

Steve

> >> Signed-off-by: Sean Nyekjaer 
> >> ---
> >>  meta/recipes-graphics/wayland/weston_11.0.1.bb | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/recipes-graphics/wayland/weston_11.0.1.bb
> >> b/meta/recipes-graphics/wayland/weston_11.0.1.bb
> >> index 0838791a6b..09753e7c51 100644
> >> --- a/meta/recipes-graphics/wayland/weston_11.0.1.bb
> >> +++ b/meta/recipes-graphics/wayland/weston_11.0.1.bb
> >> @@ -37,7 +37,7 @@ PACKAGECONFIG ??=
> >> "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'kms wayla
> >> ${@bb.utils.contains('DISTRO_FEATURES', 'x11
> >> wayland', 'xwayland', '', d)} \
> >> ${@bb.utils.filter('DISTRO_FEATURES', 'systemd
> >> x11', d)} \
> >> ${@bb.utils.contains_any('DISTRO_FEATURES',
> >> 'wayland x11', '', 'headless', d)} \
> >> -
> >> ${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager', 'sysvinit',
> >> 'launcher-libseat', '', d)} \
> >> +   launcher-libseat \
> >> image-jpeg \
> >> screenshare \
> >> shell-desktop \
> >> @@ -71,7 +71,7 @@ PACKAGECONFIG[lcms] =
> >> "-Dcolor-management-lcms=true,-Dcolor-management-lcms=fals
> >>  # Weston with webp support
> >>  PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp"
> >>  # Weston with systemd-login support
> >> -PACKAGECONFIG[systemd] = "-Dsystemd=true
> >> -Dlauncher-logind=true,-Dsystemd=false
> >> -Dlauncher-logind=false,systemd dbus"
> >> +PACKAGECONFIG[systemd] = "-Dsystemd=true,-Dsystemd=false,systemd dbus"
> >>  # Weston with Xwayland support (requires X11 and Wayland)
> >>  PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb
> >> libxcursor xwayland"
> >>  # colord CMS support
> >> --
> >> 2.42.0
> >>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189578): 
https://lists.openembedded.org/g/openembedded-core/message/189578
Mute This Topic: https://lists.openembedded.org/mt/102059907/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][mickledore][PATCH] weston: default to launcher-seatd

[Sean Nyekjaer]

Quoting Steve Sakoman :


On Thu, Oct 19, 2023 at 3:28 AM Sean Nyekjaer  wrote:


Lets use the launcher-seatd as default, launcher-logind is "sometimes"
failing to provide input events. Further more is the launcher-logind
depricated in newer versions of weston.


Changing behaviour is typically not allowed in stable branches.

In any event, this change would need to go into the master branch
before it could be backported to stable branches. So please submit
this for the master branch!

Steve


Hi Steve,

It is part of the master branch be7da75 “weston: update 11.0.1 - 12.0.1”

/Sean





Signed-off-by: Sean Nyekjaer 
---
 meta/recipes-graphics/wayland/weston_11.0.1.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston_11.0.1.bb  
b/meta/recipes-graphics/wayland/weston_11.0.1.bb

index 0838791a6b..09753e7c51 100644
--- a/meta/recipes-graphics/wayland/weston_11.0.1.bb
+++ b/meta/recipes-graphics/wayland/weston_11.0.1.bb
@@ -37,7 +37,7 @@ PACKAGECONFIG ??=  
"${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'kms wayla
${@bb.utils.contains('DISTRO_FEATURES', 'x11  
wayland', 'xwayland', '', d)} \
${@bb.utils.filter('DISTRO_FEATURES', 'systemd  
x11', d)} \
${@bb.utils.contains_any('DISTRO_FEATURES',  
'wayland x11', '', 'headless', d)} \
-
${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager', 'sysvinit',  
'launcher-libseat', '', d)} \

+   launcher-libseat \
image-jpeg \
screenshare \
shell-desktop \
@@ -71,7 +71,7 @@ PACKAGECONFIG[lcms] =  
"-Dcolor-management-lcms=true,-Dcolor-management-lcms=fals

 # Weston with webp support
 PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp"
 # Weston with systemd-login support
-PACKAGECONFIG[systemd] = "-Dsystemd=true  
-Dlauncher-logind=true,-Dsystemd=false  
-Dlauncher-logind=false,systemd dbus"

+PACKAGECONFIG[systemd] = "-Dsystemd=true,-Dsystemd=false,systemd dbus"
 # Weston with Xwayland support (requires X11 and Wayland)
 PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb  
libxcursor xwayland"

 # colord CMS support
--
2.42.0






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

[Alex Stewart]

Signed-off-by: Alex Stewart 
---
 .../libsndfile1/cve-2022-33065.patch  | 739 ++
 .../libsndfile/libsndfile1_1.2.2.bb   |   1 +
 2 files changed, 740 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch
new file mode 100644
index 00..fa4b2fc08b
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch
@@ -0,0 +1,739 @@
+From c7ce5b0ebeeb58934825077d1324960aa0747718 Mon Sep 17 00:00:00 2001
+From: Alex Stewart 
+Date: Tue, 10 Oct 2023 16:10:34 -0400
+Subject: [PATCH] mat4/mat5: fix int overflow in dataend calculation
+
+The clang sanitizer warns of a possible signed integer overflow when
+calculating the `dataend` value in `mat4_read_header()`.
+
+```
+src/mat4.c:323:41: runtime error: signed integer overflow: 205 * -100663296 
cannot be represented in type 'int'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/mat4.c:323:41 in
+src/mat4.c:323:48: runtime error: signed integer overflow: 838860800 * 4 
cannot be represented in type 'int'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/mat4.c:323:48 in
+```
+
+Cast the offending `rows` and `cols` ints to `sf_count_t` (the type of
+`dataend` before performing the calculation, to avoid the issue.
+
+CVE: CVE-2022-33065
+Fixes: https://github.com/libsndfile/libsndfile/issues/789
+Fixes: https://github.com/libsndfile/libsndfile/issues/833
+
+Upstream-Status: Backport [9a829113c88a51e57c1e46473e90609e4b7df151]
+
+Signed-off-by: Alex Stewart 
+---
+ src/mat4.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/mat4.c b/src/mat4.c
+index 0b1b414b..575683ba 100644
+--- a/src/mat4.c
 b/src/mat4.c
+@@ -320,7 +320,7 @@ mat4_read_header (SF_PRIVATE *psf)
+   psf->filelength - psf->dataoffset, 
psf->sf.channels * psf->sf.frames * psf->bytewidth) ;
+   }
+   else if ((psf->filelength - psf->dataoffset) > psf->sf.channels * 
psf->sf.frames * psf->bytewidth)
+-  psf->dataend = psf->dataoffset + rows * cols * psf->bytewidth ;
++  psf->dataend = psf->dataoffset + (sf_count_t) rows * 
(sf_count_t) cols * psf->bytewidth ;
+ 
+   psf->datalength = psf->filelength - psf->dataoffset - psf->dataend ;
+ 
+From 842303f984b2081481e74cb84a9a24ecbe3dec1a Mon Sep 17 00:00:00 2001
+From: Alex Stewart 
+Date: Wed, 11 Oct 2023 16:36:02 -0400
+Subject: [PATCH] au: avoid int overflow while calculating data_end
+
+At several points in au_read_header(), we calculate the functional end
+of the data segment by adding the (int)au_fmt.dataoffset and the
+(int)au_fmt.datasize. This can overflow the implicit int_32 return value
+and cause undefined behavior.
+
+Instead, precalculate the value and assign it to a 64-bit
+(sf_count_t)data_end variable.
+
+CVE: CVE-2022-33065
+Fixes: https://github.com/libsndfile/libsndfile/issues/833
+
+Signed-off-by: Alex Stewart 
+---
+ src/au.c | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/src/au.c b/src/au.c
+index 62bd691d..f68f2587 100644
+--- a/src/au.c
 b/src/au.c
+@@ -291,6 +291,7 @@ static int
+ au_read_header (SF_PRIVATE *psf)
+ { AU_FMT  au_fmt ;
+   int marker, dword ;
++  sf_count_t data_end ;
+ 
+   memset (_fmt, 0, sizeof (au_fmt)) ;
+   psf_binheader_readf (psf, "pm", 0, ) ;
+@@ -317,14 +318,15 @@ au_read_header (SF_PRIVATE *psf)
+   return SFE_AU_EMBED_BAD_LEN ;
+   } ;
+ 
++  data_end = (sf_count_t) au_fmt.dataoffset + (sf_count_t) 
au_fmt.datasize ;
+   if (psf->fileoffset > 0)
+-  {   psf->filelength = au_fmt.dataoffset + au_fmt.datasize ;
++  {   psf->filelength = data_end ;
+   psf_log_printf (psf, "  Data Size   : %d\n", au_fmt.datasize) ;
+   }
+-  else if (au_fmt.datasize == -1 || au_fmt.dataoffset + au_fmt.datasize 
== psf->filelength)
++  else if (au_fmt.datasize == -1 || data_end == psf->filelength)
+   psf_log_printf (psf, "  Data Size   : %d\n", au_fmt.datasize) ;
+-  else if (au_fmt.dataoffset + au_fmt.datasize < psf->filelength)
+-  {   psf->filelength = au_fmt.dataoffset + au_fmt.datasize ;
++  else if (data_end < psf->filelength)
++  {   psf->filelength = data_end ;
+   psf_log_printf (psf, "  Data Size   : %d\n", au_fmt.datasize) ;
+   }
+   else
+From 0754d3380a54e3fbdde0f684b88955c80c79f58f Mon Sep 17 00:00:00 2001
+From: Alex Stewart 
+Date: Wed, 11 Oct 2023 16:46:29 -0400
+Subject: [PATCH] avr: fix int overflow in avr_read_header()
+
+Pre-cast hdr.frames to sf_count_t, to provide the calculation with
+enough numeric space to avoid an int-overflow.
+
+CVE: CVE-2022-33065
+Fixes: 

[OE-core] [PATCH 1/2] lib/oe/sstatesig.py: dump locked.sigs.inc only when explicitly asked via -S lockedsigs

[Alexander Kanavin]

This was writing out locked-sigs.inc into cwd with every
'bitbake -S' invocation. When the intent is only to to get task
stamps (-S none), or print the difference between them (-S printdiff),
the file is unnecessary clutter.

A couple of selftests/scripts were however relying on this, so they're
adjusted to explicitly request the file.

eSDK code calls dump_lockedsigs() separately via
oe.copy_buildsystem.generate_locked_sigs() and so isn't affected.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/sstatesig.py | 7 ---
 meta/lib/oeqa/selftest/cases/archiver.py | 2 +-
 meta/lib/oeqa/selftest/cases/signing.py  | 2 +-
 scripts/lib/checklayer/__init__.py   | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 42e13a8c800..e250f51c124 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -142,9 +142,10 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 super().set_taskdata(data[3:])
 
 def dump_sigs(self, dataCache, options):
-sigfile = os.getcwd() + "/locked-sigs.inc"
-bb.plain("Writing locked sigs to %s" % sigfile)
-self.dump_lockedsigs(sigfile)
+if 'lockedsigs' in options:
+sigfile = os.getcwd() + "/locked-sigs.inc"
+bb.plain("Writing locked sigs to %s" % sigfile)
+self.dump_lockedsigs(sigfile)
 return super(bb.siggen.SignatureGeneratorBasicHash, 
self).dump_sigs(dataCache, options)
 
 
diff --git a/meta/lib/oeqa/selftest/cases/archiver.py 
b/meta/lib/oeqa/selftest/cases/archiver.py
index 3fa59fff510..3cb888c5067 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -141,7 +141,7 @@ class Archiver(OESelftestTestCase):
 pn = 'gcc-source-%s' % get_bb_vars(['PV'], 'gcc')['PV']
 
 # Generate the tasks signatures
-bitbake('mc:mc1:%s mc:mc2:%s -c %s -S none' % (pn, pn, task))
+bitbake('mc:mc1:%s mc:mc2:%s -c %s -S lockedsigs' % (pn, pn, task))
 
 # Check the tasks signatures
 # To be machine agnostic the tasks needs to generate the same 
signature for each machine
diff --git a/meta/lib/oeqa/selftest/cases/signing.py 
b/meta/lib/oeqa/selftest/cases/signing.py
index 322e753ed3b..18cce0ba258 100644
--- a/meta/lib/oeqa/selftest/cases/signing.py
+++ b/meta/lib/oeqa/selftest/cases/signing.py
@@ -191,7 +191,7 @@ class LockedSignatures(OESelftestTestCase):
 
 bitbake(test_recipe)
 # Generate locked sigs include file
-bitbake('-S none %s' % test_recipe)
+bitbake('-S lockedsigs %s' % test_recipe)
 
 feature = 'require %s\n' % locked_sigs_file
 feature += 'SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn"\n'
diff --git a/scripts/lib/checklayer/__init__.py 
b/scripts/lib/checklayer/__init__.py
index 0a0db2f02ac..8271ed7fe3b 100644
--- a/scripts/lib/checklayer/__init__.py
+++ b/scripts/lib/checklayer/__init__.py
@@ -307,7 +307,7 @@ def get_signatures(builddir, failsafe=False, machine=None, 
extravars=None):
 cmd += 'bitbake '
 if failsafe:
 cmd += '-k '
-cmd += '-S none world'
+cmd += '-S lockedsigs world'
 sigs_file = os.path.join(builddir, 'locked-sigs.inc')
 if os.path.exists(sigs_file):
 os.unlink(sigs_file)
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189574): 
https://lists.openembedded.org/g/openembedded-core/message/189574
Mute This Topic: https://lists.openembedded.org/mt/102085735/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 2/2] selftest/sstatetests: add a test for CDN sstate cache

[Alexander Kanavin]

Specifically, the test checks that everything needed for building
standard oe-core images for x86_64 and arm64 is available from
the cache (with minor exceptions). Going forward, a complete
world check could be enabled and additional configurations,
but that requires improvements to performance of hash equivalence
server in particular.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/sstatetests.py | 47 +
 1 file changed, 47 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 6ef339897bf..e392d6a1a63 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -14,6 +14,7 @@ import re
 
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, 
create_temp_layer, get_bb_vars
 from oeqa.selftest.case import OESelftestTestCase
+from oeqa.core.decorator import OETestTag
 
 import oe
 import bb.siggen
@@ -879,3 +880,49 @@ expected_sametmp_output, expected_difftmp_output)
 INHERIT += "base-do-configure-modified"
 """,
 expected_sametmp_output, expected_difftmp_output)
+
+@OETestTag("yocto-mirrors")
+class SStateMirrors(SStateBase):
+def check_bb_output(self, output, exceptions):
+in_tasks = False
+missing_objects = []
+for l in output.splitlines():
+if "The differences between the current build and any cached tasks 
start at the following tasks" in l:
+in_tasks = True
+continue
+if "Writing task signature files" in l:
+in_tasks = False
+continue
+if in_tasks:
+recipe_task = l.split("/")[-1]
+recipe, task = recipe_task.split(":")
+for e in exceptions:
+if e[0] in recipe and task == e[1]:
+break
+else:
+missing_objects.append(recipe_task)
+self.assertTrue(len(missing_objects) == 0, "Missing objects in the 
cache:\n{}".format("\n".join(missing_objects)))
+
+
+def run_test_cdn_mirror(self, machine, targets, exceptions):
+exceptions = exceptions + [[t, "do_deploy_source_date_epoch"] for t in 
targets.split()]
+exceptions = exceptions + [[t, "do_image_qa"] for t in targets.split()]
+self.config_sstate(True)
+self.append_config("""
+MACHINE = "{}"
+BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
+SSTATE_MIRRORS ?= "file://.* 
http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH;
+""".format(machine))
+result = bitbake("-S printdiff {}".format(targets))
+self.check_bb_output(result.output, exceptions)
+
+def test_cdn_mirror_qemux86_64(self):
+# Example:
+# exceptions = [ ["packagegroup-core-sdk","do_package"] ]
+exceptions = []
+self.run_test_cdn_mirror("qemux86-64", "core-image-minimal 
core-image-full-cmdline core-image-weston core-image-sato-sdk", exceptions)
+
+def test_cdn_mirror_qemuarm64(self):
+exceptions = []
+# core-image-weston isn't produced for arm64 currently
+self.run_test_cdn_mirror("qemuarm64", "core-image-minimal 
core-image-full-cmdline core-image-sato-sdk", exceptions)
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189575): 
https://lists.openembedded.org/g/openembedded-core/message/189575
Mute This Topic: https://lists.openembedded.org/mt/102085736/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 4/4] package_rpm.bbclass: Support compression override

[Khem Raj]

On 10/20/23 6:42 AM, Niko Mauno via lists.openembedded.org wrote:



On 20.10.2023 16.00, Richard Purdie wrote:

Is it common for people to need to manipulate rpms on target without
rpm being present using busybox? Do you know if busybox plans to add
zstd support?

As far as I could tell when we looked at this, the rpm world was moving
over to zstd so adding in conditional xz support for a limited use case
probably just creates a maintenance headache going forward as it isn't
something we test or plan to test?

Are you using this on an LTS release or master?


Hi Richard,

After moving to Yocto Kirkstone (LTS) which we currently use, we started
getting developer reports of 'no gzip/bzip2/xz magic' error from BusyBox
applet. For example developer uploads an rpm file to target device and
then unpacks it in runtime using 'rpm2cpio  | cpio -idmv'
command.

We don't include rpm package on target filesystems as that would
increase rootfs footprint approximately 5 MB. Including only rpm2cpio
from rpm package needs still accompanying libraries, increasing the size
by 2.5 MB approximately which also feels too big.



it seems you are quite sensitive to size, I wonder if opkg backend is 
better suited for your usecase than rpm.



I checked the discussions from BusyBox mailing list and found that in
2021 the maintainer seemed reluctant to accept the proposed zstd support
because it was not optimized for embedded systems.
http://lists.busybox.net/pipermail/busybox/2021-September/089179.html

BR, Niko






OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189573): 
https://lists.openembedded.org/g/openembedded-core/message/189573
Mute This Topic: https://lists.openembedded.org/mt/102080114/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][mickledore][PATCH] weston: default to launcher-seatd

[Steve Sakoman]

On Thu, Oct 19, 2023 at 3:28 AM Sean Nyekjaer  wrote:
>
> Lets use the launcher-seatd as default, launcher-logind is "sometimes"
> failing to provide input events. Further more is the launcher-logind
> depricated in newer versions of weston.

Changing behaviour is typically not allowed in stable branches.

In any event, this change would need to go into the master branch
before it could be backported to stable branches. So please submit
this for the master branch!

Steve

>
> Signed-off-by: Sean Nyekjaer 
> ---
>  meta/recipes-graphics/wayland/weston_11.0.1.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/wayland/weston_11.0.1.bb 
> b/meta/recipes-graphics/wayland/weston_11.0.1.bb
> index 0838791a6b..09753e7c51 100644
> --- a/meta/recipes-graphics/wayland/weston_11.0.1.bb
> +++ b/meta/recipes-graphics/wayland/weston_11.0.1.bb
> @@ -37,7 +37,7 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 
> 'wayland', 'kms wayla
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland', 
> 'xwayland', '', d)} \
> ${@bb.utils.filter('DISTRO_FEATURES', 'systemd x11', d)} \
> ${@bb.utils.contains_any('DISTRO_FEATURES', 'wayland 
> x11', '', 'headless', d)} \
> -   ${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager', 
> 'sysvinit', 'launcher-libseat', '', d)} \
> +   launcher-libseat \
> image-jpeg \
> screenshare \
> shell-desktop \
> @@ -71,7 +71,7 @@ PACKAGECONFIG[lcms] = 
> "-Dcolor-management-lcms=true,-Dcolor-management-lcms=fals
>  # Weston with webp support
>  PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp"
>  # Weston with systemd-login support
> -PACKAGECONFIG[systemd] = "-Dsystemd=true 
> -Dlauncher-logind=true,-Dsystemd=false -Dlauncher-logind=false,systemd dbus"
> +PACKAGECONFIG[systemd] = "-Dsystemd=true,-Dsystemd=false,systemd dbus"
>  # Weston with Xwayland support (requires X11 and Wayland)
>  PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb 
> libxcursor xwayland"
>  # colord CMS support
> --
> 2.42.0
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189572): 
https://lists.openembedded.org/g/openembedded-core/message/189572
Mute This Topic: https://lists.openembedded.org/mt/102059907/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.bbclass: support embedded SW components with different version number

[Khem Raj]

On 10/20/23 12:49 AM, Mikko Rapeli wrote:

Many recipes embed other SW components. The name and version of the
embedded SW component differs from the main recipe. To detect CVEs in the
embedded SW component, it needs to be added to CVE_PRODUCT list using
name of the SW product in CVE database or with "vendor:product" syntax.
Then the version of the embedded SW component can be set using
CVE_VERSION_product variable.

For example in meta-arm, trusted-firmware-a embeds mbed_tls SW component.
Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database
uses product name "mbed_tls":

CVE_PRODUCT += "mbed_tls"

and set the version of mbed_tls:

CVE_VERSION_mbed_tls = "2.28.4"

(Real patches for both are a bit more complex due to conditional build
enabling mbed_tls support and due to mbed_tls version being set in an
.inc file.)

Now trusted-firmware-a CVE check output shows:

NOTE: recipe 
trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0: task 
do_cve_check: Started
WARNING: 
trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0 
do_cve_check: Found unpatched CVE (CVE-2021-36647 CVE-2021-43666 CVE-2021-45451 
CVE-2023-43615), for more information check 
/home/builder/src/base/build/tmp/work/arm64-poky-linux/trusted-firmware-a/2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122/temp/cve.log
NOTE: recipe 
trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0: task 
do_cve_check: Succeeded

Here CVE-2023-43615 is a newly added and fixed CVE in version 2.28.5 and the 
CVEs
from 2021 need to be checked but are likely fixed in 2.28.3 and newer 2.28.y 
releases.

Note that CVE-2023-43615 does not impact trusted-firmware-a since it doesn't use
TLS or null or RC4 ciphers, but I think it's a good idea to extend
CVE checker for this use case. I hope the "CVE_VERSION_vendor:product"
does not cause odd breakages.



This is a good improvement. There is one more kink to it, where the 
vendored subpackage might be there in source but we might have 
configured the recipe to use the system version of the package instead, 
so how do we cater to such situation ?



Signed-off-by: Mikko Rapeli 
---
  meta/classes/create-spdx-2.2.bbclass |  2 +-
  meta/classes/cve-check.bbclass   | 28 +++-
  meta/lib/oe/cve_check.py |  5 ++---
  3 files changed, 22 insertions(+), 13 deletions(-)

v1: https://lists.openembedded.org/g/openembedded-core/message/189260

v2: adapt SPDX too

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass
index b0aef80db1..5b842e67ee 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -590,7 +590,7 @@ python do_create_spdx() {
  if patched_cves:
  recipe.sourceInfo = "CVEs fixed: " + patched_cves
  
-cpe_ids = oe.cve_check.get_cpe_ids(d.getVar("CVE_PRODUCT"), d.getVar("CVE_VERSION"))

+cpe_ids = oe.cve_check.get_cpe_ids(d, d.getVar("CVE_PRODUCT"), 
d.getVar("CVE_VERSION"))
  if cpe_ids:
  for cpe_id in cpe_ids:
  cpe = oe.spdx.SPDXExternalReference()
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index b55f4299da..9c41d54188 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -309,7 +309,16 @@ def check_cves(d, patched_cves):
  # If this has been unset then we're not scanning for CVEs here (for 
example, image recipes)
  if not products:
  return ([], [], [], [])
-pv = d.getVar("CVE_VERSION").split("+git")[0]
+
+# Version is PV, CVE_VERSION or CVE_VERSION_%s where %s is one of the 
entries in CVE_PRODUCT.
+# Enables checking embedded SW component CVEs provided that CVE_PRODUCT 
contains the embedded SW
+# component and that version of that component is set via 
CVE_VERSION_embedded_component variable.
+pv = {}
+for product in products:
+version = (d.getVar("CVE_VERSION_%s" % product) or "").split("+git")[0]
+if version == "":
+version = d.getVar("CVE_VERSION").split("+git")[0]
+pv[product] = version
  
  # If the recipe has been skipped/ignored we return empty lists

  if pn in d.getVar("CVE_CHECK_SKIP_RECIPE").split():
@@ -329,6 +338,7 @@ def check_cves(d, patched_cves):
  
  # For each of the known product names (e.g. curl has CPEs using curl and libcurl)...

  for product in products:
+full_product = product
  cves_in_product = False
  if ":" in product:
  vendor, product = product.split(":", 1)
@@ -341,7 +351,7 @@ def check_cves(d, patched_cves):
  cve = cverow[0]
  
  if cve in cve_ignore:

-bb.note("%s-%s ignores %s" % (product, pv, cve))
+bb.note("%s-%s ignores %s" % (product, pv[full_product], cve))
  cves_ignored.append(cve)
  continue
  elif cve in patched_cves:
@@ -366,27 +376,27 @@ def 

Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0

[Sundeep KOKKONDA via lists.openembedded.org]

Hi Alex,

You can find the rust 1.73.0 upgrade here - 
https://lists.openembedded.org/g/openembedded-core/message/189512

Thanks,
Sundeep K.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189570): 
https://lists.openembedded.org/g/openembedded-core/message/189570
Mute This Topic: https://lists.openembedded.org/mt/100936266/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 24/24] busybox: Set PATH in syslog initscript

[Steve Sakoman]

From: Martijn de Gouw 

This script is not always called with /sbin and /usr/sbin in the PATH
already, for example when called via ssh. Explicitly set PATH to make
sure it includes /sbin and /usr/sbin since that's where start-stop-daemon
is located.

Signed-off-by: Martijn de Gouw 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit fa53f898eaba15dff030f9eadf86e5bca7d954fa)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/busybox/files/syslog | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/busybox/files/syslog 
b/meta/recipes-core/busybox/files/syslog
index 2208613e8c..a4fea30ab7 100644
--- a/meta/recipes-core/busybox/files/syslog
+++ b/meta/recipes-core/busybox/files/syslog
@@ -10,6 +10,8 @@
 
 set -e
 
+PATH="/bin:/usr/bin:/sbin:/usr/sbin"
+
 if [ -f /etc/syslog-startup.conf ]; then
. /etc/syslog-startup.conf
LOG_LOCAL=0
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189569): 
https://lists.openembedded.org/g/openembedded-core/message/189569
Mute This Topic: https://lists.openembedded.org/mt/102083960/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 23/24] packages.bbclass: Correct the check for conflicts with renamed packages

[Steve Sakoman]

From: Peter Kjellerstedt 

The original solution replaced all overrides with the package name that
was being checked. This can have unforseen consequences where some
variable involved in defining the value for the PKG: variable
may rely on some override which is not set as expected. It also meant
that any PKG variable set using an override would not be caught, e.g.,
PKG:${PN}:${MACHINE} = "${PN}-dev" (made up example that would always
fail with the old code).

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit de62d538dbfe6caf123ff366643f893077175583)
Signed-off-by: Steve Sakoman 
---
 meta/classes-global/package.bbclass | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/meta/classes-global/package.bbclass 
b/meta/classes-global/package.bbclass
index e8055a9cdc..08eb56dc3d 100644
--- a/meta/classes-global/package.bbclass
+++ b/meta/classes-global/package.bbclass
@@ -499,11 +499,9 @@ python do_package () {
 # Check for conflict between renamed packages and existing ones
 # for each package in PACKAGES, check if it will be renamed to an existing 
one
 for p in packages:
-localdata = bb.data.createCopy(d)
-localdata.setVar('OVERRIDES', p)
-rename = localdata.getVar('PKG')
-if (rename != None) and rename in packages:
-bb.fatal('package "%s" is renamed to "%s" using PKG:%s, but 
package name already exists'%(p,rename,p))
+rename = d.getVar('PKG:%s' % p)
+if rename and rename in packages:
+bb.fatal('package "%s" is renamed to "%s" using PKG:%s, but 
package name already exists' % (p, rename, p))
 
 ###
 # Optimisations
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189568): 
https://lists.openembedded.org/g/openembedded-core/message/189568
Mute This Topic: https://lists.openembedded.org/mt/102083959/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 21/24] wic: bootimg-partition: Fix file name in debug message

[Steve Sakoman]

From: Daniel Semkowicz 

Debug message about using custom configuration file includes file name
with incorrect extension. Correct file name to "extlinux.conf".

Signed-off-by: Daniel Semkowicz 
Signed-off-by: Richard Purdie 
(cherry picked from commit dd63e1520454b2d53a48b72eaae126059af9809b)
Signed-off-by: Steve Sakoman 
---
 scripts/lib/wic/plugins/source/bootimg-partition.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py 
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 8956162205..58f6da72c3 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -112,7 +112,7 @@ class BootimgPartitionPlugin(SourcePlugin):
 # Use a custom configuration for extlinux.conf
 extlinux_conf = custom_cfg
 logger.debug("Using custom configuration file "
- "%s for extlinux.cfg", configfile)
+ "%s for extlinux.conf", configfile)
 else:
 raise WicError("configfile is specified but failed to "
"get it from %s." % configfile)
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189566): 
https://lists.openembedded.org/g/openembedded-core/message/189566
Mute This Topic: https://lists.openembedded.org/mt/102083957/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 22/24] oeqa/concurrencytest: Remove invalid buffering option

[Steve Sakoman]

From: Richard Purdie 

Fix warnings from oe-selftest -j:

/usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) 
isn't supported in binary mode, the default buffer size will be used
  return io.open(fd, mode, buffering, encoding, *args, **kwargs)

Remove the option since it clearly doesn't do much.

Signed-off-by: Richard Purdie 
(cherry picked from commit 6b872ee72942951fd464c4c6cb9eadcb9b4749c1)
Signed-off-by: Steve Sakoman 
---
 meta/lib/oeqa/core/utils/concurrencytest.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/core/utils/concurrencytest.py 
b/meta/lib/oeqa/core/utils/concurrencytest.py
index 4f77589b00..3ac5a6dd7c 100644
--- a/meta/lib/oeqa/core/utils/concurrencytest.py
+++ b/meta/lib/oeqa/core/utils/concurrencytest.py
@@ -263,7 +263,7 @@ def fork_for_tests(concurrency_num, suite):
 ourpid = os.getpid()
 try:
 newbuilddir = None
-stream = os.fdopen(c2pwrite, 'wb', 1)
+stream = os.fdopen(c2pwrite, 'wb')
 os.close(c2pread)
 
 (builddir, newbuilddir) = suite.setupfunc("-st-" + 
str(ourpid), selftestdir, process_suite)
@@ -308,7 +308,7 @@ def fork_for_tests(concurrency_num, suite):
 os._exit(0)
 else:
 os.close(c2pwrite)
-stream = os.fdopen(c2pread, 'rb', 1)
+stream = os.fdopen(c2pread, 'rb')
 # Collect stdout/stderr into an io buffer
 output = io.BytesIO()
 testserver = ProtocolTestCase(stream, passthrough=output)
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189567): 
https://lists.openembedded.org/g/openembedded-core/message/189567
Mute This Topic: https://lists.openembedded.org/mt/102083958/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 20/24] oeqa/utils/gitarchive: Handle broken commit counts in results repo

[Steve Sakoman]

From: Richard Purdie 

The test results repository contains tags like:

master/64501-g65c94ca3196e5ef3344a469fea8e30444f2e967a/0
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/3
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/2
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/1
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/0

where the commit count is correct in one case and not in the others. This causes
assertion errors in the current code.

Add in some code to work around these historical issues where the commit counts 
are low.

Signed-off-by: Richard Purdie 
Signed-off-by: Alexandre Belloni 
(cherry picked from commit d51fc5c8c469730885af7bbde7122032de411d89)
Signed-off-by: Steve Sakoman 
---
 meta/lib/oeqa/utils/gitarchive.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/gitarchive.py 
b/meta/lib/oeqa/utils/gitarchive.py
index 73beafecb5..6046f183d5 100644
--- a/meta/lib/oeqa/utils/gitarchive.py
+++ b/meta/lib/oeqa/utils/gitarchive.py
@@ -221,7 +221,15 @@ def get_test_revs(log, repo, tag_name, **kwargs):
 if not commit in revs:
 revs[commit] = TestedRev(commit, commit_num, [tag])
 else:
-assert commit_num == revs[commit].commit_number, "Commit numbers 
do not match"
+if commit_num != revs[commit].commit_number:
+# Historically we have incorrect commit counts of '1' in the 
repo so fix these up
+if int(revs[commit].commit_number) < 5:
+tags = revs[commit].tags
+revs[commit] = TestedRev(commit, commit_num, [tags])
+elif int(commit_num) < 5:
+pass
+else:
+sys.exit("Commit numbers for commit %s don't match (%s vs 
%s)" % (commit, commit_num, revs[commit].commit_number))
 revs[commit].tags.append(tag)
 
 # Return in sorted table
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189565): 
https://lists.openembedded.org/g/openembedded-core/message/189565
Mute This Topic: https://lists.openembedded.org/mt/102083956/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 19/24] oeqa/selftest: Fix broken symlink removal handling

[Steve Sakoman]

From: Richard Purdie 

The test above this removal correctly looks at symlinks however to
remove a symlink we should call unlink(), not remove(). This avoids
some build failures/tracebacks.

Signed-off-by: Richard Purdie 
(cherry picked from commit dbdb6e73b0f52bc5f9429aca47802d51edbbc834)
Signed-off-by: Steve Sakoman 
---
 meta/lib/oeqa/selftest/context.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index 39325f4b72..3fb357f8eb 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -427,7 +427,7 @@ class OESelftestTestContextExecutor(OETestContextExecutor):
 output_link = os.path.join(os.path.dirname(args.output_log),
 "%s-results.log" % self.name)
 if os.path.lexists(output_link):
-os.remove(output_link)
+os.unlink(output_link)
 os.symlink(args.output_log, output_link)
 
 return rc
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189564): 
https://lists.openembedded.org/g/openembedded-core/message/189564
Mute This Topic: https://lists.openembedded.org/mt/102083954/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 18/24] insane.bbclass: Count raw bytes in shebang-size

[Steve Sakoman]

From: Jan Garcia 

Operating systems limit the shebang to a maximum number of bytes.
This patch makes the shebang-size check count raw bytes instead of UTF-8 
characters.

Signed-off-by: Jan Garcia 
Signed-off-by: Richard Purdie 
(cherry picked from commit d4ac66c5cdaf971fb717cc5c5bf9aa51a787d412)
Signed-off-by: Steve Sakoman 
---
 meta/classes-global/insane.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes-global/insane.bbclass 
b/meta/classes-global/insane.bbclass
index ee34d5208d..e3a7d05ec3 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -94,9 +94,8 @@ def package_qa_check_shebang_size(path, name, d, elf, 
messages):
 return
 
 if stanza.startswith(b'#!'):
-#Shebang not found
 try:
-stanza = stanza.decode("utf-8")
+stanza.decode("utf-8")
 except UnicodeDecodeError:
 #If it is not a text file, it is not a script
 return
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189563): 
https://lists.openembedded.org/g/openembedded-core/message/189563
Mute This Topic: https://lists.openembedded.org/mt/102083952/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 17/24] fontcache.bbclass: avoid native recipes depending on target fontconfig

[Steve Sakoman]

From: Martin Jansa 

* this caused liberation-font-native to depend on TUNE_PKGARCH target fontconfig
  because ${MLPREFIX}fontconfig-utils is added to RDEPENDS in anonymous python

* the dependency tree for liberation-font-native got much shorter
  (just quilt-native and liberation-font-native itself):
   2 after/pn-buildlist
  78 before/pn-buildlist

* fixes graphviz-native signature issue as well as detected with 
sstate-diff-machines.sh

  $ bitbake-diffsigs \

sstate-after/mako/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.184d4fd355f1e7a2d7d929ef4b5f62b94e2071df9dd674b2067ec21bfc7bcc1b
 \

sstate-after/qemux86-64/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.35da674d2dbc275bac02869dfce4165466315023910bdef65a6026e2cb942a46
  Hash for task dependency liberation-fonts-native:do_populate_sysroot changed 
from 310d3da04ad9abf8ee7e53d1ffa71c2b7d9d60fb0e8de85171a9ab6a77d3 to 
048420ad1410c2b8d95498fc3c11681207335a2c722836f1f3e683cc449814da

Signed-off-by: Martin Jansa 
Signed-off-by: Richard Purdie 
(cherry picked from commit 998d4da9d89aea77dc0f2cbac60ea64258331756)
Signed-off-by: Steve Sakoman 
---
 meta/classes-recipe/fontcache.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes-recipe/fontcache.bbclass 
b/meta/classes-recipe/fontcache.bbclass
index 0d496b72dd..6f4978369d 100644
--- a/meta/classes-recipe/fontcache.bbclass
+++ b/meta/classes-recipe/fontcache.bbclass
@@ -13,6 +13,7 @@ PACKAGE_WRITE_DEPS += "qemu-native"
 inherit qemu
 
 FONT_PACKAGES ??= "${PN}"
+FONT_PACKAGES:class-native = ""
 FONT_EXTRA_RDEPENDS ?= "${MLPREFIX}fontconfig-utils"
 FONTCONFIG_CACHE_DIR ?= "${localstatedir}/cache/fontconfig"
 FONTCONFIG_CACHE_PARAMS ?= "-v"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189562): 
https://lists.openembedded.org/g/openembedded-core/message/189562
Mute This Topic: https://lists.openembedded.org/mt/102083951/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 16/24] libevent: fix patch Upstream-Status

[Steve Sakoman]

From: Michael Opdenacker 

Signed-off-by: Michael Opdenacker 
Signed-off-by: Richard Purdie 
(cherry picked from commit 8c987afb2054f24d9bf86305774c186a6e015a8f)
Signed-off-by: Steve Sakoman 
---
 ...test-retriable-tests-are-marked-failed-only-when-all-a.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-support/libevent/libevent/0004-test-retriable-tests-are-marked-failed-only-when-all-a.patch
 
b/meta/recipes-support/libevent/libevent/0004-test-retriable-tests-are-marked-failed-only-when-all-a.patch
index ea17e876ea..26b707ad31 100644
--- 
a/meta/recipes-support/libevent/libevent/0004-test-retriable-tests-are-marked-failed-only-when-all-a.patch
+++ 
b/meta/recipes-support/libevent/libevent/0004-test-retriable-tests-are-marked-failed-only-when-all-a.patch
@@ -6,7 +6,7 @@ Subject: [PATCH] test: retriable tests are marked failed only 
when all
 
 Fixes: #1193
 
-Upstream-Status: Accepted
+Upstream-Status: Backport 
[https://github.com/libevent/libevent/commit/3daebf308a01b4b2d3fb867be3d6631f7b5a2dbb]
 
 Signed-off-by: Thomas Perrot 
 ---
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189561): 
https://lists.openembedded.org/g/openembedded-core/message/189561
Mute This Topic: https://lists.openembedded.org/mt/102083946/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 15/24] shadow: fix patch Upstream-Status

[Steve Sakoman]

From: Michael Opdenacker 

Replace "Accepted" by "Backport" as specified on
https://docs.yoctoproject.org/migration-guides/migration-3.2.html#miscellaneous-changes

Signed-off-by: Michael Opdenacker 
Signed-off-by: Richard Purdie 
(cherry picked from commit 945f1106de1fc1b08921e05aa0f871092c2c116d)
Signed-off-by: Steve Sakoman 
---
 .../shadow/files/0001-Fix-can-not-print-full-login.patch| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch 
b/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
index 37ba5f3dc2..89f9c05c8d 100644
--- a/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
+++ b/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
@@ -7,7 +7,7 @@ Date:   Tue Dec 27 17:40:17 2022 +0530
 Login timed out message prints only first few bytes when write is 
immediately followed by exit.
 Calling exit from new handler provides enough time to display full message.
 
-Upstream-Status: Accepted 
[https://github.com/shadow-maint/shadow/commit/670cae834827a8f794e6f7464fa57790d911b63c]
+Upstream-Status: Backport 
[https://github.com/shadow-maint/shadow/commit/670cae834827a8f794e6f7464fa57790d911b63c]
 
 diff --git a/src/login.c b/src/login.c
 index 116e2cb3..c55f4de0 100644
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189560): 
https://lists.openembedded.org/g/openembedded-core/message/189560
Mute This Topic: https://lists.openembedded.org/mt/102083945/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 14/24] uboot-extlinux-config.bbclass: fix missed override syntax migration

[Steve Sakoman]

From: Quentin Schulz 

uboot-extlinux-config allows to specify multiple "labels" (entries in a
menu, à-la grub) and each of them have their own values for some fields.
Each "base" variable, e.g. UBOOT_EXTLINUX_FDT can be overridden for each
label. This is done via the OVERRIDES mechanism based on the label name,
e.g. UBOOT_EXTLINUX_FDT:linux if linux is a label.

However, OVERRIDES doesn't contain the label globally because it's only
necessary in one task. Therefore, the OVERRIDES itself is modified
within the task. This means that the sigdata will not be told the
dependency on UBOOT_EXTLINUX_FDT:linux, because it cannot know about it.

For this reason, we need to explicitly specify which variables this task
depends on via vardeps varflag for the task.

This was done in the past, but we missed updating it during the override
syntax migration so the cache wouldn't get invalidated if someone
modifies UBOOT_EXTLINUX_FDT:linux from a configuration file or a
bbappend for example.

Let's fix this by migrating it to the new syntax.

Signed-off-by: Quentin Schulz 
Signed-off-by: Richard Purdie 
(cherry picked from commit b4dd9d873508128adbbf5ff6cf0a3df3d2ffbcf6)
Signed-off-by: Steve Sakoman 
---
 meta/classes-recipe/uboot-extlinux-config.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/uboot-extlinux-config.bbclass 
b/meta/classes-recipe/uboot-extlinux-config.bbclass
index 653e583663..2f5c665f97 100644
--- a/meta/classes-recipe/uboot-extlinux-config.bbclass
+++ b/meta/classes-recipe/uboot-extlinux-config.bbclass
@@ -152,7 +152,7 @@ python do_create_extlinux_config() {
 bb.fatal('Unable to open %s' % (cfile))
 }
 UBOOT_EXTLINUX_VARS = "CONSOLE MENU_DESCRIPTION ROOT KERNEL_IMAGE FDTDIR FDT 
KERNEL_ARGS INITRD"
-do_create_extlinux_config[vardeps] += "${@' '.join(['UBOOT_EXTLINUX_%s_%s' % 
(v, l) for v in d.getVar('UBOOT_EXTLINUX_VARS').split() for l in 
d.getVar('UBOOT_EXTLINUX_LABELS').split()])}"
+do_create_extlinux_config[vardeps] += "${@' '.join(['UBOOT_EXTLINUX_%s:%s' % 
(v, l) for v in d.getVar('UBOOT_EXTLINUX_VARS').split() for l in 
d.getVar('UBOOT_EXTLINUX_LABELS').split()])}"
 do_create_extlinux_config[vardepsexclude] += "OVERRIDES"
 
 addtask create_extlinux_config before do_install do_deploy after do_compile
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189559): 
https://lists.openembedded.org/g/openembedded-core/message/189559
Mute This Topic: https://lists.openembedded.org/mt/102083944/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 13/24] vim: Upgrade 9.0.2009 -> 9.0.2048

[Steve Sakoman]

From: Siddharth Doshi 

This includes CVE fix for CVE-2023-5535.

Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-support/vim/vim.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 5e06866692..58025828f2 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -19,8 +19,8 @@ SRC_URI = 
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://no-path-adjust.patch \
"
 
-PV .= ".2009"
-SRCREV = "54844857fd6933fa4f6678e47610c4b9c9f7a091"
+PV .= ".2048"
+SRCREV = "982ef16059bd163a77271107020defde0740bbd6"
 
 # Do not consider .z in x.y.z, as that is updated with every commit
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+)\.0"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189558): 
https://lists.openembedded.org/g/openembedded-core/message/189558
Mute This Topic: https://lists.openembedded.org/mt/102083943/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 11/24] linux-yocto/6.1: update to v6.1.57

[Steve Sakoman]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

082280fe94a0 Linux 6.1.57
a4cc925e2e12 xen/events: replace evtchn_rwlock with RCU
a4fcf8a242c6 ipv6: remove one read_lock()/read_unlock() pair in 
rt6_check_neigh()
6e4c40aa270b btrfs: file_remove_privs needs an exclusive lock in direct io 
write
ff81d1c77d08 netlink: remove the flex array from struct nlmsghdr
6cd57f5c7795 btrfs: fix fscrypt name leak after failure to join log 
transaction
6d05a1a7a484 btrfs: fix an error handling path in btrfs_rename()
5aaa45025f9f vrf: Fix lockdep splat in output path
fd32f1eee6c0 ipv6: remove nexthop_fib6_nh_bh()
edeccce85cbe parisc: Restore __ldcw_align for PA-RISC 2.0 processors
8226ffc759ea ksmbd: fix uaf in smb20_oplock_break_ack
a2ca5fd3dbcc ksmbd: fix race condition between session lookup and expire
64301a935462 x86/sev: Use the GHCB protocol when available for SNP CPUID 
requests
76b6a980e85f RDMA/mlx5: Fix NULL string error
26eb1307c704 RDMA/mlx5: Fix mutex unlocking on error flow for steering 
anchor creation
5cf38e638e5d RDMA/siw: Fix connection failure handling
2b298f918158 RDMA/srp: Do not call scsi_done() from srp_abort()
c54204d7960f RDMA/uverbs: Fix typo of sizeof argument
233229fa577a RDMA/cma: Fix truncation compilation warning in make_cma_ports
39f701870114 RDMA/cma: Initialize ib_sa_multicast structure to 0 when join
52b0bb7139c9 gpio: pxa: disable pinctrl calls for MMP_GPIO
d09e467491b2 gpio: aspeed: fix the GPIO number passed to 
pinctrl_gpio_set_config()
7e47a8419da6 IB/mlx4: Fix the size of a buffer in add_port_entries()
315ae630502c of: dynamic: Fix potential memory leak in of_changeset_action()
9c480fb41aa4 RDMA/core: Require admin capabilities to set system parameters
f60287b2d240 dm zoned: free dmz->ddev array in dmz_put_zoned_devices
485f0bac83a6 parisc: Fix crash with nr_cpus=1 option
c9c110ce3754 smb: use kernel_connect() and kernel_bind()
ec02b892237d intel_idle: add Emerald Rapids Xeon support
cdcc04e844a2 HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit
07c6338acb15 HID: sony: remove duplicate NULL check before calling 
usb_free_urb()
40d609b6ad90 netlink: annotate data-races around sk->sk_err
0915de8c6083 netlink: Fix potential skb memleak in netlink_ack
1a6e2da05f37 netlink: split up copies in the ack construction
220f0f866d69 sctp: update hb timer immediately after users change 
hb_interval
63cb52e75fd1 sctp: update transport state when processing a dupcook packet
419b2c5766fa tcp: fix delayed ACKs for MSS boundary condition
4acf07bafb58 tcp: fix quick-ack counting to count actual ACKs of new data
143e72757a90 tipc: fix a potential deadlock on >lock
f2697457ab73 net: stmmac: dwmac-stm32: fix resume on STM32 MCU
da7fa17bd9ac ipv4: Set offload_failed flag in fibmatch results
56a6ea76dd9b netfilter: nf_tables: nft_set_rbtree: fix spurious insertion 
failure
7ff9a9857b8b netfilter: nf_tables: Deduplicate nft_register_obj audit logs
e1bbe4afe1a3 selftests: netfilter: Extend nft_audit.sh
82273f15e3db selftests: netfilter: Test nf_tables audit logging
00d35e6b1672 netfilter: handle the connecting collision properly in 
nf_conntrack_proto_sctp
6e1dbbf29031 ibmveth: Remove condition to recompute TCP header checksum.
2428c557cd62 net: ethernet: ti: am65-cpsw: Fix error code in 
am65_cpsw_nuss_init_tx_chns()
7562780e32b8 net: nfc: llcp: Add lock when modifying device list
9ffc5018020f net: usb: smsc75xx: Fix uninit-value access in 
__smsc75xx_read_reg
7f042041360e ipv6: tcp: add a missing nf_reset_ct() in 3WHS handling
a003d4994088 net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent
6a91ec7cfd0e ptp: ocp: Fix error handling in ptp_ocp_device_init
f6a7182179c0 ipv4, ipv6: Fix handling of transhdrlen in 
__ip{,6}_append_data()
a8ed1b2e1674 neighbour: fix data-races around n->output
2b76aad68b30 neighbour: switch to standard rcu, instead of rcu_bh
0526933c1005 neighbour: annotate lockless accesses to n->nud_state
8904d8848b31 bpf: Add BPF_FIB_LOOKUP_SKIP_NEIGH for bpf_fib_lookup
f82aac816287 net: fix possible store tearing in neigh_periodic_work()
8ef7f9acbe8e modpost: add missing else to the "of" check
b8f97e47b6fb bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
c024db960301 bpf, sockmap: Do not inc copied_seq when PEEK flag set
46052a98854a bpf: tcp_read_skb needs to pop skb regardless of seq
99fe9a120729 NFSv4: Fix a nfs4_state_manager() race
23acd1784eb5 ima: rework CONFIG_IMA dependency block
6c5d7f541693 scsi: target: core: Fix deadlock due to recursive locking
f23c35f0686c ima: Finish deprecation of IMA_TRUSTED_KEYRING Kconfig
937ec4434e0a regulator/core: regulator_register: set device->class earlier
fbac416e25ef 

[OE-core][mickledore 12/24] cve-exclusion_6.1.inc: update for 6.1.57

[Steve Sakoman]

Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/linux/cve-exclusion_6.1.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc 
b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
index b6b9ca00d4..d172261886 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
@@ -1,9 +1,9 @@
 
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2023-09-30 07:26:16.988526+00:00 for version 6.1.55
+# Generated at 2023-10-18 21:33:08.698393+00:00 for version 6.1.57
 
 python check_kernel_cve_status_version() {
-this_version = "6.1.55"
+this_version = "6.1.57"
 kernel_version = d.getVar("LINUX_VERSION")
 if kernel_version != this_version:
 bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189557): 
https://lists.openembedded.org/g/openembedded-core/message/189557
Mute This Topic: https://lists.openembedded.org/mt/102083940/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 10/24] linux-yocto/6.1: tiny: fix arm 32 boot

[Steve Sakoman]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/.:

0816d0a6984 qemuarma15: add ARM_PATCH_PHYS_VIRT

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 
(cherry picked from commit 732d1ee4bc824cb52fab4327601efdb1558b6d9c)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_6.1.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
index ab6dbdb52d..bd782d1b09 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
@@ -15,7 +15,7 @@ python () {
 }
 
 SRCREV_machine ?= "4b3040c1dc13aaac356ad4ef45a8926118c732d0"
-SRCREV_meta ?= "3b4113ce39d722191d1eb0e159976d653de4d2b2"
+SRCREV_meta ?= "0816d0a6984e2abbbc5aef9db16391a97b7c9850"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
 \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.1;destsuffix=${KMETA};protocol=https"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
index 29459fabed..11d87d23a7 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
@@ -18,7 +18,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "644e73fa089ade30c0db7bd54be960be92546ba2"
-SRCREV_meta ?= "3b4113ce39d722191d1eb0e159976d653de4d2b2"
+SRCREV_meta ?= "0816d0a6984e2abbbc5aef9db16391a97b7c9850"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.1.bb
index 21e22c887e..03cecb2da1 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.1.bb
@@ -28,7 +28,7 @@ SRCREV_machine:qemux86 ?= 
"f21f9d92e463bcfa7e64887f14676225144ed8d1"
 SRCREV_machine:qemux86-64 ?= "f21f9d92e463bcfa7e64887f14676225144ed8d1"
 SRCREV_machine:qemumips64 ?= "aa0e978c979b84d620ad21132cfdbbf857be3878"
 SRCREV_machine ?= "f21f9d92e463bcfa7e64887f14676225144ed8d1"
-SRCREV_meta ?= "3b4113ce39d722191d1eb0e159976d653de4d2b2"
+SRCREV_meta ?= "0816d0a6984e2abbbc5aef9db16391a97b7c9850"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189555): 
https://lists.openembedded.org/g/openembedded-core/message/189555
Mute This Topic: https://lists.openembedded.org/mt/102083938/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 09/24] linux-yocto/6.1: update to v6.1.56

[Steve Sakoman]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

ecda77b46871 Linux 6.1.56
8c515d4f2d66 ASoC: amd: yc: Fix a non-functional mic on Lenovo 82TL
a3c1da448353 mm, memcg: reconsider kmem.limit_in_bytes deprecation
b8901b6c2e9b memcg: drop kmem.limit_in_bytes
ee335e0094ad drm/meson: fix memory leak on ->hpd_notify callback
b60028c81e46 drm/amdkfd: Use gpu_offset for user queue's wptr
48a22f13fb1b fs: binfmt_elf_efpic: fix personality for ELF-FDPIC
69e61ee8ea8a power: supply: ab8500: Set typing and props
c038ebffbb48 power: supply: rk817: Add missing module alias
69dd84470b4d drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
60d2e06ad6e3 ata: libata-sata: increase PMP SRST timeout to 10s
886f387db1e6 ata: libata-core: Do not register PM operations for SAS ports
5cfbe6da8354 ata: libata-core: Fix port and device removal
0b7aaf2058ba ata: libata-core: Fix ata_port_request_pm() locking
f555a508087a fs/smb/client: Reset password pointer to NULL
1983fd78701a net: thunderbolt: Fix TCPv6 GSO checksum calculation
4fb56e82d939 bpf: Fix BTF_ID symbol generation collision in tools/
4f1e3e02777b bpf: Fix BTF_ID symbol generation collision
b1041cab4726 bpf: Add override check to kprobe multi link attach
09635bf4cdd4 media: uvcvideo: Fix OOB read
d6a749e4cab2 btrfs: properly report 0 avail for very full file systems
f3ad8874541d ring-buffer: Update "shortest_full" in polling
6bacdb914a99 mm: memcontrol: fix GFP_NOFS recursion in memory.high 
enforcement
a5569bb18752 mm/slab_common: fix slab_caches list corruption after 
kmem_cache_destroy()
9a4fe81a8644 mm/damon/vaddr-test: fix memory leak in 
damon_do_test_apply_three_regions()
68a63a077e02 arm64: defconfig: remove CONFIG_COMMON_CLK_NPCM8XX=y
b29756aefe03 drm/tests: Fix incorrect argument in drm_test_mm_insert_range
a90eafbf165f timers: Tag (hr)timer softirq as hotplug safe
f32340c70eb9 Revert "SUNRPC dont update timeout value on connection reset"
1e4c03d530d8 netfilter: nf_tables: fix kdoc warnings after gc rework
49903f70d728 sched/rt: Fix live lock between select_fallback_rq() and RT 
push
787256ec9b44 kernel/sched: Modify initial boot task idle setup
afa2bbd682c7 ASoC: amd: yc: Fix non-functional mic on Lenovo 82QF and 82UG
829ff08be566 i2c: i801: unregister tco_pdev in i801_probe() error path
75c307d9f2fb io_uring/fs: remove sqe->rw_flags checking from LINKAT
06fba8a8dea2 ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED 
OPERATION CODES
476fd029e700 ata: libata-scsi: link ata port and scsi device
490f3b805ee3 LoongArch: numa: Fix high_memory calculation
7bc8585aa071 LoongArch: Define relocation types for ABI v2.10
f04ded9ae268 ALSA: hda: Disable power save for solving pop issue on Lenovo 
ThinkCentre M70q
9af8bb2afea3 netfilter: nf_tables: disallow rule removal from chain binding
980663f1d189 nilfs2: fix potential use after free in 
nilfs_gccache_submit_read_data()
e14f68a48fd4 serial: 8250_port: Check IRQ data before use
c61d0b87a702 Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
37435ddfadc6 misc: rtsx: Fix some platforms can not boot and move the l1ss 
judgment to probe
5d6613ed2b7d mptcp: fix bogus receive window shrinkage with multiple 
subflows
00c27bffdba6 KVM: x86/mmu: Do not filter address spaces in 
for_each_tdp_mmu_root_yield_safe()
cd41db6cb285 KVM: x86/mmu: Open code leaf invalidation from mmu_notifier
733d7a5451fc KVM: SVM: Fix TSC_AUX virtualization setup
e86a3a622633 KVM: SVM: INTERCEPT_RDTSCP is never intercepted anyway
6ce2f297a716 x86/srso: Add SRSO mitigation for Hygon processors
811ba2ef0cb6 x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
f90f4c562003 iommu/arm-smmu-v3: Fix soft lockup triggered by 
arm_smmu_mm_invalidate_range
a09446ac0414 smack: Retrieve transmuting information in 
smack_inode_getsecurity()
cbb16d0f4996 smack: Record transmuting in smk_transmuted
4b8ef68e39d2 nvme-pci: always return an ERR_PTR from nvme_pci_alloc_dev
1d7bc76b5849 scsi: qla2xxx: Fix NULL pointer dereference in target mode
1a51d35ba729 wifi: ath11k: Don't drop tx_status when peer cannot be found
a60768c05b58 nvme-pci: do not set the NUMA node of device if it has none
6b2165cae403 nvme-pci: factor out a nvme_pci_alloc_dev helper
69bc295d0e0b nvme-pci: factor the iod mempool creation into a helper
9ebee88a8911 perf build: Define YYNOMEM as YYNOABORT for bison < 3.81
8e85af2c682e fbdev/sh7760fb: Depend on FB=y
f105e893a8ed LoongArch: Set all reserved memblocks on Node#0 at 
initialization
146ba159f5a6 tsnep: Fix NAPI polling with budget 0
78ac1e7dec24 tsnep: Fix NAPI scheduling
b09c1359e4f0 net: hsr: Add __packed to struct hsr_sup_tlv.
97788f0757bd ncsi: Propagate carrier gain/loss events to the NCSI 

[OE-core][mickledore 08/24] linux-yocto/6.1: update to v6.1.55

[Steve Sakoman]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

d23900f974e0 Linux 6.1.55
0db211ec0f1d interconnect: Teach lockdep about icc_bw_lock order
b93aeb6352b0 net/sched: Retire rsvp classifier
4c6bb9158179 drm/amdgpu: fix amdgpu_cs_p1_user_fence
45ea58f9dbf8 Revert "memcg: drop kmem.limit_in_bytes"
4422080e777e drm/amd/display: fix the white screen issue when >= 64GB DRAM
97d4186c3503 ext4: fix rec_len verify error
89365b624af5 scsi: pm8001: Setup IRQs on resume
c2cb422dca0b scsi: megaraid_sas: Fix deadlock on firmware crashdump
890e1e5dd8ba ata: libahci: clear pending interrupt status
a3517ee1d4e6 ata: libata: disallow dev-initiated LPM transitions to 
unsupported states
30057f4add41 i2c: aspeed: Reset the i2c controller when timeout occurs
8b0f7d55b22e tracefs: Add missing lockdown check to tracefs_create_dir()
dcf3caeee432 nfsd: fix change_info in NFSv4 RENAME replies
978b86fbdb2a selinux: fix handling of empty opts in 
selinux_fs_context_submount()
2617afde0c3d tracing: Have option files inc the trace array ref count
6dc57c3a1d13 tracing: Have current_trace inc the trace array ref count
a46bf337a20f tracing: Increase trace array ref count on enable and filter 
files
0c2982b01501 tracing: Have event inject files inc the trace array ref count
d65553fe5281 tracing: Have tracing_max_latency inc the trace array ref count
1f89e6daf2b0 btrfs: check for BTRFS_FS_ERROR in pending ordered assert
50e385d98b2a btrfs: release path before inode lookup during the ino lookup 
ioctl
52932bbc6d4b btrfs: fix a compilation error if DEBUG is defined in 
btree_dirty_folio
32247b9526bf btrfs: fix lockdep splat and potential deadlock after failure 
running delayed items
d7b2abd87d1f dm: don't attempt to queue IO under RCU protection
216eae7d7dea Revert "drm/amd: Disable S/G for APUs when 64GB or more host 
memory"
98ea94f1627b md: Put the right device in md_seq_next
f07c0bc27b0e nvme: avoid bogus CRTO values
6a1d1365fafe io_uring/net: fix iter retargeting for selected buf
e7dcf8339a0f ovl: fix incorrect fdput() on aio completion
17854d92fa4a ovl: fix failed copyup of fileattr on a symlink
6a84939cc7dd attr: block mode changes of symlinks
3494a0066d8a Revert "SUNRPC: Fail faster on bad verifier"
ba4f28a1d362 md/raid1: fix error: ISO C90 forbids mixed declarations
2076b4b677c3 samples/hw_breakpoint: fix building without module unloading
0dea06849924 x86/purgatory: Remove LTO flags
2074cb608cb5 x86/boot/compressed: Reserve more memory for page tables
038249ee7264 panic: Reenable preemption in WARN slowpath
6069b9d8056d scsi: lpfc: Fix the NULL vs IS_ERR() bug for 
debugfs_create_file()
1cd41d1669bc scsi: target: core: Fix target_cmd_counter leak
dd8fce4e2da5 riscv: kexec: Align the kexeced kernel entry
e9b8e266105a x86/ibt: Suppress spurious ENDBR
03425393f41c selftests: tracing: Fix to unmount tracefs for recovering 
environment
bc912eed8a1a scsi: qla2xxx: Fix NULL vs IS_ERR() bug for 
debugfs_create_dir()
cbf226355ee3 drm: gm12u320: Fix the timeout usage for usb_bulk_msg()
64561352c0f2 nvmet-tcp: pass iov_len instead of sg->length to 
bvec_set_page()
5ee5c928dbb6 nvmet: use bvec_set_page to initialize bvecs
00cf1dc13c1f block: factor out a bvec_set_page helper
2174731a17b0 btrfs: compare the correct fsid/metadata_uuid in 
btrfs_validate_super
31242daa108b btrfs: add a helper to read the superblock metadata_uuid
44751b057c24 MIPS: Use "grep -E" instead of "egrep"
8332311cd02a misc: fastrpc: Fix incorrect DMA mapping unmap request
5a5641755ca8 misc: fastrpc: Prepare to dynamic dma-buf locking specification
b4539ff7a48d dma-buf: Add unlocked variant of attachment-mapping functions
6ca28642dd9a printk: Consolidate console deferred printing
13ebf3ff08b0 printk: Keep non-panic-CPUs out of console lock
ee42bfc791aa interconnect: Fix locking for runpm vs reclaim
48aebbe801e7 kobject: Add sanity check for kset->kobj.ktype in 
kset_register()
240571c49f76 media: pci: ipu3-cio2: Initialise timing struct to avoid a 
compiler warning
91f400233edc usb: chipidea: add workaround for chipidea PEC bug
8e3556f2f497 usb: ehci: add workaround for chipidea PORTSC.PEC bug
48c135c30ad2 misc: open-dice: make OPEN_DICE depend on HAS_IOMEM
a3c9315a8c78 serial: cpm_uart: Avoid suspicious locking
4738bf8b2d36 scsi: target: iscsi: Fix buffer overflow in 
lio_target_nacl_info_show()
6c440fec96af tools: iio: iio_generic_buffer: Fix some integer type and 
calculation
826e9c91a203 usb: gadget: fsl_qe_udc: validate endpoint index for ch9 udc
bbc9c3652708 usb: cdns3: Put the cdns set active part outside the spin lock
96a0bf5827e7 media: pci: cx23885: replace BUG with error return
257092cb544c media: tuners: qt1010: replace BUG_ON with a 

[OE-core][mickledore 07/24] libxpm: upgrade to 3.5.17

[Steve Sakoman]

From: Ross Burton 

This release fixes the following CVEs:

- CVE-2023-43788
- CVE-2023-43789

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit 46dd8ce41756dbc2aa0f9001416f208cced1c8d5)
Signed-off-by: Steve Sakoman 
---
 .../xorg-lib/{libxpm_3.5.16.bb => libxpm_3.5.17.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/xorg-lib/{libxpm_3.5.16.bb => libxpm_3.5.17.bb} 
(88%)

diff --git a/meta/recipes-graphics/xorg-lib/libxpm_3.5.16.bb 
b/meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
similarity index 88%
rename from meta/recipes-graphics/xorg-lib/libxpm_3.5.16.bb
rename to meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
index c3d01f1bb3..8e15ecc0d4 100644
--- a/meta/recipes-graphics/xorg-lib/libxpm_3.5.16.bb
+++ b/meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
@@ -22,6 +22,6 @@ PACKAGES =+ "sxpm cxpm"
 FILES:cxpm = "${bindir}/cxpm"
 FILES:sxpm = "${bindir}/sxpm"
 
-SRC_URI[sha256sum] = 
"e6bc5da7a69dbd9bcc67e87c93d4904fe2f5177a0711c56e71fa2f6eff649f51"
+SRC_URI[sha256sum] = 
"64b31f81019e7d388c822b0b28af8d51c4622b83f1f0cb6fa3fc95e271226e43"
 
 BBCLASSEXTEND = "native"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189552): 
https://lists.openembedded.org/g/openembedded-core/message/189552
Mute This Topic: https://lists.openembedded.org/mt/102083934/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 06/24] libx11: upgrade to 1.8.7

[Steve Sakoman]

From: Ross Burton 

This incorporates fixes for the following CVEs:

- CVE-2023-43785
- CVE-2023-43786
- CVE-2023-43787

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit a1534bb34b680bfc5cb2f35b5fd5a0c2afed6368)
Signed-off-by: Steve Sakoman 
---
 .../xorg-lib/{libx11_1.8.6.bb => libx11_1.8.7.bb}   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/xorg-lib/{libx11_1.8.6.bb => libx11_1.8.7.bb} 
(92%)

diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.8.6.bb 
b/meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb
similarity index 92%
rename from meta/recipes-graphics/xorg-lib/libx11_1.8.6.bb
rename to meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb
index 1cfa56b21e..5f14e62446 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.8.6.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb
@@ -24,7 +24,7 @@ XORG_PN = "libX11"
 
 SRC_URI += "file://disable_tests.patch"
 
-SRC_URI[sha256sum] = 
"59535b7cc6989ba806a022f7e8533b28c4397b9d86e9d07b6df0c0703fa25cc9"
+SRC_URI[sha256sum] = 
"05f267468e3c851ae2b5c830bcf74251a90f63f04dd7c709ca94dc155b7e99ee"
 
 inherit gettext
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189551): 
https://lists.openembedded.org/g/openembedded-core/message/189551
Mute This Topic: https://lists.openembedded.org/mt/102083933/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 05/24] python3-urllib3: 1.26.15 -> 1.26.17

[Steve Sakoman]

From: Lee Chee Yang 

1.26.17 (2023-10-02)
Added the Cookie header to the list of headers to strip from requests
when redirecting to a different host. As before, different headers can
be set via Retry.remove_headers_on_redirect. (CVE-2023-43804)

1.26.16 (2023-05-23)
Fixed thread-safety issue where accessing a PoolManager with many
distinct origins would cause connection pools to be closed while
requests are in progress (#2954)

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 .../{python3-urllib3_1.26.15.bb => python3-urllib3_1.26.17.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3-urllib3_1.26.15.bb => 
python3-urllib3_1.26.17.bb} (86%)

diff --git a/meta/recipes-devtools/python/python3-urllib3_1.26.15.bb 
b/meta/recipes-devtools/python/python3-urllib3_1.26.17.bb
similarity index 86%
rename from meta/recipes-devtools/python/python3-urllib3_1.26.15.bb
rename to meta/recipes-devtools/python/python3-urllib3_1.26.17.bb
index d2de7c4c02..57b166870a 100644
--- a/meta/recipes-devtools/python/python3-urllib3_1.26.15.bb
+++ b/meta/recipes-devtools/python/python3-urllib3_1.26.17.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://github.com/shazow/urllib3;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=c2823cb995439c984fd62a973d79815c"
 
-SRC_URI[sha256sum] = 
"8a388717b9476f934a21484e8c8e61875ab60644d29b9b39e11e4b9dc1c6b305"
+SRC_URI[sha256sum] = 
"24d6a242c28d29af46c3fae832c36db3bbebcc533dd1bb549172cd739c82df21"
 
 inherit pypi setuptools3
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189550): 
https://lists.openembedded.org/g/openembedded-core/message/189550
Mute This Topic: https://lists.openembedded.org/mt/102083932/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 04/24] cve-check: add CVSS vector string to CVE database and reports

[Steve Sakoman]

From: Antoine Lubineau 

This allows building detailed vulnerability analysis tools without
relying on external resources.

Signed-off-by: Antoine Lubineau 
Signed-off-by: Alexandre Belloni 
(cherry picked from commit 048ff0ad927f4d37cc5547ebeba9e0c221687ea6)
Signed-off-by: Steve Sakoman 
---
 meta/classes/cve-check.bbclass   |  5 -
 meta/recipes-core/meta/cve-update-nvd2-native.bb | 11 ---
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..3846aee5ea 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -32,7 +32,7 @@ CVE_PRODUCT ??= "${BPN}"
 CVE_VERSION ??= "${PV}"
 
 CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2-1.db"
 CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
 
 CVE_CHECK_LOG ?= "${T}/cve.log"
@@ -403,6 +403,7 @@ def get_cve_info(d, cves):
 cve_data[row[0]]["scorev3"] = row[3]
 cve_data[row[0]]["modified"] = row[4]
 cve_data[row[0]]["vector"] = row[5]
+cve_data[row[0]]["vectorString"] = row[6]
 cursor.close()
 conn.close()
 return cve_data
@@ -459,6 +460,7 @@ def cve_write_data_text(d, patched, unpatched, ignored, 
cve_data):
 write_string += "CVSS v2 BASE SCORE: %s\n" % cve_data[cve]["scorev2"]
 write_string += "CVSS v3 BASE SCORE: %s\n" % cve_data[cve]["scorev3"]
 write_string += "VECTOR: %s\n" % cve_data[cve]["vector"]
+write_string += "VECTORSTRING: %s\n" % cve_data[cve]["vectorString"]
 write_string += "MORE INFORMATION: %s%s\n\n" % (nvd_link, cve)
 
 if unpatched_cves and d.getVar("CVE_CHECK_SHOW_WARNINGS") == "1":
@@ -573,6 +575,7 @@ def cve_write_data_json(d, patched, unpatched, ignored, 
cve_data, cve_status):
 "scorev2" : cve_data[cve]["scorev2"],
 "scorev3" : cve_data[cve]["scorev3"],
 "vector" : cve_data[cve]["vector"],
+"vectorString" : cve_data[cve]["vectorString"],
 "status" : status,
 "link": issue_link
 }
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb 
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 2f7dad7e82..d0321f1bb5 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -225,7 +225,7 @@ def initialize_db(conn):
 c.execute("CREATE TABLE IF NOT EXISTS META (YEAR INTEGER UNIQUE, DATE 
TEXT)")
 
 c.execute("CREATE TABLE IF NOT EXISTS NVD (ID TEXT UNIQUE, SUMMARY 
TEXT, \
-SCOREV2 TEXT, SCOREV3 TEXT, MODIFIED INTEGER, VECTOR TEXT)")
+SCOREV2 TEXT, SCOREV3 TEXT, MODIFIED INTEGER, VECTOR TEXT, 
VECTORSTRING TEXT)")
 
 c.execute("CREATE TABLE IF NOT EXISTS PRODUCTS (ID TEXT, \
 VENDOR TEXT, PRODUCT TEXT, VERSION_START TEXT, OPERATOR_START 
TEXT, \
@@ -299,6 +299,7 @@ def update_db(conn, elt):
 """
 
 accessVector = None
+vectorString = None
 cveId = elt['cve']['id']
 if elt['cve']['vulnStatus'] ==  "Rejected":
 return
@@ -309,25 +310,29 @@ def update_db(conn, elt):
 date = elt['cve']['lastModified']
 try:
 accessVector = 
elt['cve']['metrics']['cvssMetricV2'][0]['cvssData']['accessVector']
+vectorString = 
elt['cve']['metrics']['cvssMetricV2'][0]['cvssData']['vectorString']
 cvssv2 = 
elt['cve']['metrics']['cvssMetricV2'][0]['cvssData']['baseScore']
 except KeyError:
 cvssv2 = 0.0
 cvssv3 = None
 try:
 accessVector = accessVector or 
elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['attackVector']
+vectorString = vectorString or 
elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['vectorString']
 cvssv3 = 
elt['cve']['metrics']['cvssMetricV30'][0]['cvssData']['baseScore']
 except KeyError:
 pass
 try:
 accessVector = accessVector or 
elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['attackVector']
+vectorString = vectorString or 
elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['vectorString']
 cvssv3 = cvssv3 or 
elt['cve']['metrics']['cvssMetricV31'][0]['cvssData']['baseScore']
 except KeyError:
 pass
 accessVector = accessVector or "UNKNOWN"
+vectorString = vectorString or "UNKNOWN"
 cvssv3 = cvssv3 or 0.0
 
-conn.execute("insert or replace into NVD values (?, ?, ?, ?, ?, ?)",
-[cveId, cveDesc, cvssv2, cvssv3, date, accessVector]).close()
+conn.execute("insert or replace into NVD values (?, ?, ?, ?, ?, ?, ?)",
+[cveId, cveDesc, cvssv2, cvssv3, date, accessVector, 
vectorString]).close()
 
 try:
 for config in elt['cve']['configurations']:
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189549): 

[OE-core][mickledore 03/24] qemu: ignore RHEL specific CVE-2023-2680

[Steve Sakoman]

From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/qemu/qemu.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 00decc57e5..a7f1099dd5 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -67,6 +67,10 @@ CVE_CHECK_IGNORE += "CVE-2018-18438"
 # this bug related to windows specific.
 CVE_CHECK_IGNORE += "CVE-2023-0664"
 
+# As per https://bugzilla.redhat.com/show_bug.cgi?id=2203387
+# RHEL specific issue
+CVE_CHECK_IGNORE += "CVE-2023-2680"
+
 COMPATIBLE_HOST:mipsarchn32 = "null"
 COMPATIBLE_HOST:mipsarchn64 = "null"
 COMPATIBLE_HOST:riscv32 = "null"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189548): 
https://lists.openembedded.org/g/openembedded-core/message/189548
Mute This Topic: https://lists.openembedded.org/mt/102083929/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 02/24] dmidecode: fixup for CVE-2023-30630

[Steve Sakoman]

From: Sean Nyekjaer 

The previous CVE-2023-30630_1.patch picked only the patch
"dmidecode: Write the whole dump file at once" d8cfbc808f.
But there was a refactoring which does not allow to cherry-pick it fast
forward. Resolving this conflict was not correctly done. The patch was:

+u32 len;
+u8 *table;
...
-if (!(opt.flags & FLAG_QUIET))
-pr_comment("Writing %d bytes to %s.", crafted[0x05],
-   opt.dumpfile);
-write_dump(0, crafted[0x05], crafted, opt.dumpfile, 1);
+dmi_table_dump(crafted, crafted[0x05], table, len);

It looks like the variables len and table have been added without
initialization.
Now this problem is solved by applying the previous refactoring as
well. Patch 1 gets replaced by Patch 1a and Patch 1b. Patch 2..4 are
rebased without changes.

This is basically the same patch as in kirkstone:
ea069a94a2 dmidecode: fixup for CVE-2023-30630

Signed-off-by: Sean Nyekjaer 
Signed-off-by: Steve Sakoman 
---
 .../dmidecode/CVE-2023-30630_1a.patch | 236 ++
 .../dmidecode/CVE-2023-30630_1b.patch | 197 +++
 .../dmidecode/CVE-2023-30630_2.patch  |   8 +-
 .../dmidecode/CVE-2023-30630_3.patch  |  55 ++--
 .../dmidecode/CVE-2023-30630_4.patch  | 143 +--
 .../dmidecode/dmidecode_3.4.bb|   3 +-
 6 files changed, 539 insertions(+), 103 deletions(-)
 create mode 100644 
meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1a.patch
 create mode 100644 
meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1b.patch

diff --git a/meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1a.patch 
b/meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1a.patch
new file mode 100644
index 00..bf93fbc13c
--- /dev/null
+++ b/meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1a.patch
@@ -0,0 +1,236 @@
+From ee6db10dd70b8fdc7a93cffd7cf5bc7a28f9d3d7 Mon Sep 17 00:00:00 2001
+From: Jean Delvare 
+Date: Mon, 20 Feb 2023 14:53:21 +0100
+Subject: [PATCH 1/5] dmidecode: Split table fetching from decoding
+
+Clean up function dmi_table so that it does only one thing:
+* dmi_table() is renamed to dmi_table_get(). It now retrieves the
+  DMI table, but does not process it any longer.
+* Decoding or dumping the table is now done in smbios3_decode(),
+  smbios_decode() and legacy_decode().
+No functional change.
+
+A side effect of this change is that writing the header and body of
+dump files is now done in a single location. This is required to
+further consolidate the writing of dump files.
+
+Signed-off-by: Jean Delvare 
+Reviewed-by: Jerry Hoemann 
+
+CVE: CVE-2023-30630
+
+Upstream-Status: Backport 
[https://git.savannah.nongnu.org/cgit/dmidecode.git/commit/?id=39b2dd7b6ab719b920e96ed832cfb4bdd664e808]
+
+Signed-off-by: Adrian Freihofer 
+---
+ dmidecode.c | 86 ++---
+ 1 file changed, 62 insertions(+), 24 deletions(-)
+
+diff --git a/dmidecode.c b/dmidecode.c
+index cd2b5c9..b082c03 100644
+--- a/dmidecode.c
 b/dmidecode.c
+@@ -5247,8 +5247,9 @@ static void dmi_table_decode(u8 *buf, u32 len, u16 num, 
u16 ver, u32 flags)
+   }
+ }
+ 
+-static void dmi_table(off_t base, u32 len, u16 num, u32 ver, const char 
*devmem,
+-u32 flags)
++/* Allocates a buffer for the table, must be freed by the caller */
++static u8 *dmi_table_get(off_t base, u32 *len, u16 num, u32 ver,
++   const char *devmem, u32 flags)
+ {
+   u8 *buf;
+ 
+@@ -5267,7 +5268,7 @@ static void dmi_table(off_t base, u32 len, u16 num, u32 
ver, const char *devmem,
+   {
+   if (num)
+   pr_info("%u structures occupying %u bytes.",
+-  num, len);
++  num, *len);
+   if (!(opt.flags & FLAG_FROM_DUMP))
+   pr_info("Table at 0x%08llX.",
+   (unsigned long long)base);
+@@ -5285,19 +5286,19 @@ static void dmi_table(off_t base, u32 len, u16 num, 
u32 ver, const char *devmem,
+* would be the result of the kernel truncating the table on
+* parse error.
+*/
+-  size_t size = len;
++  size_t size = *len;
+   buf = read_file(flags & FLAG_NO_FILE_OFFSET ? 0 : base,
+   , devmem);
+-  if (!(opt.flags & FLAG_QUIET) && num && size != (size_t)len)
++  if (!(opt.flags & FLAG_QUIET) && num && size != (size_t)*len)
+   {
+   fprintf(stderr, "Wrong DMI structures length: %u bytes "
+   "announced, only %lu bytes available.\n",
+-  len, (unsigned long)size);
++  *len, (unsigned long)size);
+   }
+-  len = size;
++  *len = size;
+   }
+

[OE-core][mickledore 00/24] Patch review

[Steve Sakoman]

Please review this set of changes for mickledore and have comments back by
end of day Tuesday, October 24

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6075

with the exception of the meta-arm test which fails due to the linux-yocto 6.1
version bumps in this series. A patch to meta-arm is pending the merge of these
version bumps.

The following changes since commit 266944eb216912b7b2a935360aa51cd79847a071:

  gdb: fix RDEPENDS for PACKAGECONFIG[tui] (2023-10-12 16:23:08 -1000)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/mickledore-nut
  
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/mickledore-nut

Antoine Lubineau (1):
  cve-check: add CVSS vector string to CVE database and reports

Bruce Ashfield (4):
  linux-yocto/6.1: update to v6.1.55
  linux-yocto/6.1: update to v6.1.56
  linux-yocto/6.1: tiny: fix arm 32 boot
  linux-yocto/6.1: update to v6.1.57

Daniel Semkowicz (1):
  wic: bootimg-partition: Fix file name in debug message

Jan Garcia (1):
  insane.bbclass: Count raw bytes in shebang-size

Lee Chee Yang (3):
  cups: fix CVE-2023-4504
  qemu: ignore RHEL specific CVE-2023-2680
  python3-urllib3: 1.26.15 -> 1.26.17

Martijn de Gouw (1):
  busybox: Set PATH in syslog initscript

Martin Jansa (1):
  fontcache.bbclass: avoid native recipes depending on target fontconfig

Michael Opdenacker (2):
  shadow: fix patch Upstream-Status
  libevent: fix patch Upstream-Status

Peter Kjellerstedt (1):
  packages.bbclass: Correct the check for conflicts with renamed
packages

Quentin Schulz (1):
  uboot-extlinux-config.bbclass: fix missed override syntax migration

Richard Purdie (3):
  oeqa/selftest: Fix broken symlink removal handling
  oeqa/utils/gitarchive: Handle broken commit counts in results repo
  oeqa/concurrencytest: Remove invalid buffering option

Ross Burton (2):
  libx11: upgrade to 1.8.7
  libxpm: upgrade to 3.5.17

Sean Nyekjaer (1):
  dmidecode: fixup for CVE-2023-30630

Siddharth Doshi (1):
  vim: Upgrade 9.0.2009 -> 9.0.2048

Steve Sakoman (1):
  cve-exclusion_6.1.inc: update for 6.1.57

 meta/classes-global/insane.bbclass|   3 +-
 meta/classes-global/package.bbclass   |   8 +-
 meta/classes-recipe/fontcache.bbclass |   1 +
 .../uboot-extlinux-config.bbclass |   2 +-
 meta/classes/cve-check.bbclass|   5 +-
 meta/lib/oeqa/core/utils/concurrencytest.py   |   4 +-
 meta/lib/oeqa/selftest/context.py |   2 +-
 meta/lib/oeqa/utils/gitarchive.py |  10 +-
 meta/recipes-core/busybox/files/syslog|   2 +
 .../meta/cve-update-nvd2-native.bb|  11 +-
 .../dmidecode/CVE-2023-30630_1a.patch | 236 ++
 .../dmidecode/CVE-2023-30630_1b.patch | 197 +++
 .../dmidecode/CVE-2023-30630_2.patch  |   8 +-
 .../dmidecode/CVE-2023-30630_3.patch  |  55 ++--
 .../dmidecode/CVE-2023-30630_4.patch  | 143 +--
 .../dmidecode/dmidecode_3.4.bb|   3 +-
 ..._1.26.15.bb => python3-urllib3_1.26.17.bb} |   2 +-
 meta/recipes-devtools/qemu/qemu.inc   |   4 +
 meta/recipes-extended/cups/cups.inc   |   1 +
 .../cups/cups/CVE-2023-4504.patch |  42 
 .../0001-Fix-can-not-print-full-login.patch   |   2 +-
 .../{libx11_1.8.6.bb => libx11_1.8.7.bb}  |   2 +-
 .../{libxpm_3.5.16.bb => libxpm_3.5.17.bb}|   2 +-
 .../linux/cve-exclusion_6.1.inc   |  13 +-
 .../linux/linux-yocto-rt_6.1.bb   |   6 +-
 .../linux/linux-yocto-tiny_6.1.bb |   6 +-
 meta/recipes-kernel/linux/linux-yocto_6.1.bb  |  28 +--
 ...ts-are-marked-failed-only-when-all-a.patch |   2 +-
 meta/recipes-support/vim/vim.inc  |   4 +-
 .../wic/plugins/source/bootimg-partition.py   |   2 +-
 30 files changed, 654 insertions(+), 152 deletions(-)
 create mode 100644 
meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1a.patch
 create mode 100644 
meta/recipes-devtools/dmidecode/dmidecode/CVE-2023-30630_1b.patch
 rename meta/recipes-devtools/python/{python3-urllib3_1.26.15.bb => 
python3-urllib3_1.26.17.bb} (86%)
 create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-4504.patch
 rename meta/recipes-graphics/xorg-lib/{libx11_1.8.6.bb => libx11_1.8.7.bb} 
(92%)
 rename meta/recipes-graphics/xorg-lib/{libxpm_3.5.16.bb => libxpm_3.5.17.bb} 
(88%)

-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189545): 
https://lists.openembedded.org/g/openembedded-core/message/189545
Mute This Topic: https://lists.openembedded.org/mt/102083924/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 01/24] cups: fix CVE-2023-4504

[Steve Sakoman]

From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-extended/cups/cups.inc   |  1 +
 .../cups/cups/CVE-2023-4504.patch | 42 +++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-4504.patch

diff --git a/meta/recipes-extended/cups/cups.inc 
b/meta/recipes-extended/cups/cups.inc
index c6a676b747..d09ceb203f 100644
--- a/meta/recipes-extended/cups/cups.inc
+++ b/meta/recipes-extended/cups/cups.inc
@@ -17,6 +17,7 @@ SRC_URI = 
"${GITHUB_BASE_URI}/download/v${PV}/cups-${PV}-source.tar.gz \
file://cups-volatiles.conf \
file://CVE-2023-32324.patch \
file://CVE-2023-34241.patch \
+   file://CVE-2023-4504.patch \
"
 
 GITHUB_BASE_URI = "https://github.com/OpenPrinting/cups/releases;
diff --git a/meta/recipes-extended/cups/cups/CVE-2023-4504.patch 
b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
new file mode 100644
index 00..e52e43a209
--- /dev/null
+++ b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
@@ -0,0 +1,42 @@
+CVE: CVE-2023-4504
+Upstream-Status: Backport 
[https://github.com/OpenPrinting/cups/commit/2431caddb7e6a87f04ac90b5c6366ad268b6ff31
 ]
+Signed-off-by: Lee Chee Yang 
+
+From 2431caddb7e6a87f04ac90b5c6366ad268b6ff31 Mon Sep 17 00:00:00 2001
+From: Zdenek Dohnal 
+Date: Wed, 20 Sep 2023 14:45:17 +0200
+Subject: [PATCH] raster-interpret.c: Fix CVE-2023-4504
+
+We didn't check for end of buffer if it looks there is an escaped
+character - check for NULL terminator there and if found, return NULL
+as return value and in `ptr`, because a lone backslash is not
+a valid PostScript character.
+---
+ cups/raster-interpret.c | 14 +-
+ 1 files changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/cups/raster-interpret.c b/cups/raster-interpret.c
+index 6fcf731b5..b8655c8c6 100644
+--- a/cups/raster-interpret.c
 b/cups/raster-interpret.c
+@@ -1116,7 +1116,19 @@ scan_ps(_cups_ps_stack_t *st,   /* I  - Stack */
+ 
+   cur ++;
+ 
+-if (*cur == 'b')
++ /*
++  * Return NULL if we reached NULL terminator, a lone backslash
++  * is not a valid character in PostScript.
++  */
++
++  if (!*cur)
++  {
++*ptr = NULL;
++
++return (NULL);
++  }
++
++  if (*cur == 'b')
+ *valptr++ = '\b';
+   else if (*cur == 'f')
+ *valptr++ = '\f';
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189546): 
https://lists.openembedded.org/g/openembedded-core/message/189546
Mute This Topic: https://lists.openembedded.org/mt/102083925/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] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Bruce Ashfield]

On Fri, Oct 20, 2023 at 10:24 AM Richard Purdie
 wrote:
>
> On Fri, 2023-10-20 at 08:52 -0400, Bruce Ashfield wrote:
> > On Fri, Oct 20, 2023 at 7:19 AM Rasmus Villemoes
> >  wrote:
> > >
> > > On 20/10/2023 12.13, Richard Purdie wrote:
> > > > On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote:
> > > > > On 20/10/2023 11.38, Richard Purdie wrote:
> > > > > > On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
> > > > > > > On 19/10/2023 14.48, Richard Purdie wrote:
> > > > >
> > > > > > > > The fact this works suggests perf is ignoring TARGET_CFLAGS. Is 
> > > > > > > > there
> > > > > > > > anything in the perf build system where we should be passing in 
> > > > > > > > cflags
> > > > > > > > we really want used?
> > > > > > >
> > > > > > > Well, IIUC, the normal way TARGET_CFLAGS would take effect is via 
> > > > > > > the
> > > > > > > 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
> > > > > > > do_compile and do_install start with
> > > > > > >
> > > > > > > # Linux kernel build system is expected to do the right 
> > > > > > > thing
> > > > > > > unset CFLAGS
> > > > > > >
> > > > > > > And perf's build system does indeed add lots of flags of its own, 
> > > > > > > at
> > > > > > > least for most TUs, but nowhere is any 
> > > > > > > -f(macro/debug/file)-prefix being
> > > > > > > set.
> > > > > > >
> > > > > > > So I do think that TARGET_CC_ARCH is the best place for flags 
> > > > > > > that we
> > > > > > > really want used. At least as an initial step, because this is 
> > > > > > > known to
> > > > > > > work when using the security_flags.inc file. Maybe there's some 
> > > > > > > cleaner
> > > > > > > way where we don't unset CFLAGS, but that could be a giant can of 
> > > > > > > worms.
> > > > > > >
> > > > > > > And yes, a comment should be added. Is something like
> > > > > > >
> > > > > > > # Perf's build system adds its own optimization flags for most 
> > > > > > > TUs,
> > > > > > > # overriding the flags included here. But for some, perf does not 
> > > > > > > add
> > > > > > > # any -O option, so ensure the distro's chosen optimization gets 
> > > > > > > used
> > > > > > > # for those. Since ${SELECTED_OPTIMIZATION} always includes
> > > > > > > # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this 
> > > > > > > also
> > > > > > > # ensures perf is built with appropriate -f*-prefix-map options,
> > > > > > > # avoiding the 'buildpaths' QA warning.
> > > > > > >
> > > > > > > too verbose?
> > > > > >
> > > > > > If it were me I'd probably write:
> > > > > >
> > > > > > # The perf makefile has "unset CFLAGS" as "Linux kernel build 
> > > > > > system is
> > > > > > # expected to do the right thing".
> > > > >
> > > > > It's not the perf makefile, it's right there in our recipe itself. I
> > > > > don't think upstream perf is to blame.
> > > >
> > > > Sorry, I misunderstood. I thought this was the perf environment that
> > > > was doing this so in that case your comment does make much more sense
> > > > than mine.
> > >
> > > OK. Bruce, should I resend?
> >
> > Yes, let's go for a resend with the comment added. If we can avoid even 
> > some of
> > the pain wondering about this again .. our future selves will thank us :)
> >
> > >
> > > > Out of interest did you see what happens if you allow our CFLAGS in and
> > > > remove that unset?
> > >
> > > I don't think I've tried that, but I've tried a few other things that I
> > > thought would be cleaner but which then exploded, so in the end I
> > > decided that just lifting exactly what the poky distro does should be
> > > safest and have the highest likelyhood of being accepted.
> >
> > This is not directed at Rasmus, but a general comment ..
> >
> > For pretty much anything kernel, and perf has always strongly been in
> > that category, we've always unset everything and allowed the Makefiles
> > (and the nested mess of tests, includes and trickery) to set their own
> > flags. It has saved subtle runtime issues and this is one area that the
> > developers tend to know what they are doing.
>
> For the kernel itself, yes, they do. For userspace binaries, we do in
> general have a good idea of how binaries should be being built and
> we're a bit ahead of the curve on the flags/features that should be
> configured.

And I'm saying that these userspace packages in the kernel are
almost as opinionated as the kernel. I generally trust their options
and don't want to control all aspects of the flags. I certainly don't
want to support them as we climb through the new kernel versions,
so keeping the defaults is a much better option.

>
> > When there's a chance to append, they've give us a variable to do so,
> > that's why we've always used EXTRA_CFLAGS, and that likely is the
> > right place to use here as well. But even then, we shouldn't pass ALL of
> > our flags in there, just what we think needs to be in addition to the
> > perf generated set of CFLAGS.
>
> I'm not entirely 

Re: [OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support

[Julien Stephan]

Le ven. 20 oct. 2023 à 16:04, Richard Purdie
 a écrit :
>
> On Fri, 2023-10-20 at 14:57 +0200, Julien Stephan wrote:
> > Le jeu. 19 oct. 2023 à 20:34, Alexandre Belloni
> >  a écrit :
> > >
> > > On 19/10/2023 20:20:33+0200, Julien Stephan wrote:
> > > > Le jeu. 19 oct. 2023 à 15:49, Alexandre Belloni
> > > >  a écrit :
> > > > >
> > > > > Hello,
> > > > >
> > > > > On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> > > > > > add support for PEP517 [1]
> > > > > >
> > > > > > if a pyproject.toml file is found, use it to create the recipe,
> > > > > > otherwise fallback to the old setup.py method.
> > > > > >
> > > > > > [YOCTO #14737]
> > > > > >
> > > > > > [1]: https://peps.python.org/pep-0517/
> > > > > >
> > > > > > Signed-off-by: Julien Stephan 
> > > > > > ---
> > > > > >  .../lib/recipetool/create_buildsys_python.py  | 234 
> > > > > > +-
> > > > > >  1 file changed, 233 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/scripts/lib/recipetool/create_buildsys_python.py 
> > > > > > b/scripts/lib/recipetool/create_buildsys_python.py
> > > > > > index 69f6f5ca511..0b601d50a4b 100644
> > > > > > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > > > > > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > > > > > @@ -18,6 +18,7 @@ import os
> > > > > >  import re
> > > > > >  import sys
> > > > > >  import subprocess
> > > > > > +import toml
> > > > >
> > > > > This fails on the autobuilders because we don't have the toml module 
> > > > > installed so I guess you need to add a dependency.
> > > > >
> > > >
> > > > Hello,
> > > >
> > > > Sure I 'll do it. Just to confirm, I should add it here:
> > > > https://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host
> > > > ?
> > >
> > > I guess the preferred way would be to depend on python3-toml-native
> > > instead of requiring installation on the host.
> > >
> >
> > Hi Alexandre,
> >
> > How am I supposed to do that for a script? Is that even possible? Am I
> > missing something obvious?
>
> As far as I know you're not missing anything obvious. If the toml
> dependency was in the target recipe this would be easier but needing
> this from recipetool is harder as it is running under the host python.
>
> Adding dependencies for the host is hard as it needs to be added on the
> docs, on the autobuilder workers and into our buildtools-extended-
> tarballs and generally impacts a lot of people/places.
>
> I think moving the import into the code and having recipe tool error
> and ask the user to install the dependency might be the best solution
> for now. That does give us a challenge over where/when we can test the
> code though.
>
> On the autobuilder we could run recipetool for this test using the
> python3native from a recipe sysroot where the toml dependency is
> available I guess but that is a bit ugly.
>
> As Tim mentions, with python 3.11 onwards, this problem does go away.
> We could also make the test conditional upon the host python version I
> guess so it only runs on newer hosts?
>

Hi Richard,

Thank you for the detailed explanation.
I think I will go and use tomllib and skip the test on systems with
python < 3.11 if that is okay for everyone.

Makes me realize that I didn't add selftest for pep517, I will add
them for the next version of the series.

Have a good week end

Cheers

Julien


> Cheers,
>
> Richard

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

[Trevor Gamblin]

the test_lic_files_chksum_modified_not_mentioned test in patchtest
wasn't picking up on 'License-Update:' tags correctly. Use pyparsing's
AtLineStart class to simplify the regex setup and search.

Signed-off-by: Trevor Gamblin 
---
 meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py 
b/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
index cb3e7c9d341..fa4a28c7b22 100644
--- a/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
+++ b/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
@@ -12,8 +12,7 @@ class LicFilesChkSum(base.Metadata):
 metadata = 'LIC_FILES_CHKSUM'
 license  = 'LICENSE'
 closed   = 'CLOSED'
-lictag   = 'License-Update'
-lictag_re  = pyparsing.Regex("^%s:" % lictag)
+lictag_re  = pyparsing.AtLineStart("License-Update:")
 
 def test_lic_files_chksum_presence(self):
 if not self.added:
@@ -71,5 +70,5 @@ class LicFilesChkSum(base.Metadata):
 if self.lictag_re.search_string(commit.commit_message):
break
 else:
-self.fail('LIC_FILES_CHKSUM changed on target %s but there 
is no "%s" tag in commit message. Include it with a brief description' % (pn, 
self.lictag),
+self.fail('LIC_FILES_CHKSUM changed on target %s but there 
is no "License-Update:" tag in commit message. Include it with a brief 
description' % pn,
   data=[('Current checksum', pretest), ('New 
checksum', test)])
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189542): 
https://lists.openembedded.org/g/openembedded-core/message/189542
Mute This Topic: https://lists.openembedded.org/mt/102082363/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] selftest/sstatetests: add tests for 'bitbake -S printdiff'

[Richard Purdie]

On Fri, 2023-10-20 at 16:34 +0200, Alexander Kanavin wrote:
> On Fri, 20 Oct 2023 at 15:44, Richard Purdie
>  wrote:
> > I did idly wonder if we need to set the sig handler to not use
> > hashequiv for these tests? I haven't checked if that would help though,
> > I'm just making a wild guess.
> 
> I fired it up with BB_HASHSERVE = "auto" set inside the test, let's see:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2307

BB_SIGNATURE_HANDLER = "OEBasicHash"

is the thing I had in mind FWIW but that should be ok.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189541): 
https://lists.openembedded.org/g/openembedded-core/message/189541
Mute This Topic: https://lists.openembedded.org/mt/102035446/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] selftest/sstatetests: add tests for 'bitbake -S printdiff'

[Alexander Kanavin]

On Fri, 20 Oct 2023 at 15:44, Richard Purdie
 wrote:
> I did idly wonder if we need to set the sig handler to not use
> hashequiv for these tests? I haven't checked if that would help though,
> I'm just making a wild guess.

I fired it up with BB_HASHSERVE = "auto" set inside the test, let's see:
https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2307

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189540): 
https://lists.openembedded.org/g/openembedded-core/message/189540
Mute This Topic: https://lists.openembedded.org/mt/102035446/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] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Richard Purdie]

On Fri, 2023-10-20 at 08:52 -0400, Bruce Ashfield wrote:
> On Fri, Oct 20, 2023 at 7:19 AM Rasmus Villemoes
>  wrote:
> > 
> > On 20/10/2023 12.13, Richard Purdie wrote:
> > > On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote:
> > > > On 20/10/2023 11.38, Richard Purdie wrote:
> > > > > On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
> > > > > > On 19/10/2023 14.48, Richard Purdie wrote:
> > > > 
> > > > > > > The fact this works suggests perf is ignoring TARGET_CFLAGS. Is 
> > > > > > > there
> > > > > > > anything in the perf build system where we should be passing in 
> > > > > > > cflags
> > > > > > > we really want used?
> > > > > > 
> > > > > > Well, IIUC, the normal way TARGET_CFLAGS would take effect is via 
> > > > > > the
> > > > > > 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
> > > > > > do_compile and do_install start with
> > > > > > 
> > > > > > # Linux kernel build system is expected to do the right 
> > > > > > thing
> > > > > > unset CFLAGS
> > > > > > 
> > > > > > And perf's build system does indeed add lots of flags of its own, at
> > > > > > least for most TUs, but nowhere is any -f(macro/debug/file)-prefix 
> > > > > > being
> > > > > > set.
> > > > > > 
> > > > > > So I do think that TARGET_CC_ARCH is the best place for flags that 
> > > > > > we
> > > > > > really want used. At least as an initial step, because this is 
> > > > > > known to
> > > > > > work when using the security_flags.inc file. Maybe there's some 
> > > > > > cleaner
> > > > > > way where we don't unset CFLAGS, but that could be a giant can of 
> > > > > > worms.
> > > > > > 
> > > > > > And yes, a comment should be added. Is something like
> > > > > > 
> > > > > > # Perf's build system adds its own optimization flags for most TUs,
> > > > > > # overriding the flags included here. But for some, perf does not 
> > > > > > add
> > > > > > # any -O option, so ensure the distro's chosen optimization gets 
> > > > > > used
> > > > > > # for those. Since ${SELECTED_OPTIMIZATION} always includes
> > > > > > # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this 
> > > > > > also
> > > > > > # ensures perf is built with appropriate -f*-prefix-map options,
> > > > > > # avoiding the 'buildpaths' QA warning.
> > > > > > 
> > > > > > too verbose?
> > > > > 
> > > > > If it were me I'd probably write:
> > > > > 
> > > > > # The perf makefile has "unset CFLAGS" as "Linux kernel build system 
> > > > > is
> > > > > # expected to do the right thing".
> > > > 
> > > > It's not the perf makefile, it's right there in our recipe itself. I
> > > > don't think upstream perf is to blame.
> > > 
> > > Sorry, I misunderstood. I thought this was the perf environment that
> > > was doing this so in that case your comment does make much more sense
> > > than mine.
> > 
> > OK. Bruce, should I resend?
> 
> Yes, let's go for a resend with the comment added. If we can avoid even some 
> of
> the pain wondering about this again .. our future selves will thank us :)
> 
> > 
> > > Out of interest did you see what happens if you allow our CFLAGS in and
> > > remove that unset?
> > 
> > I don't think I've tried that, but I've tried a few other things that I
> > thought would be cleaner but which then exploded, so in the end I
> > decided that just lifting exactly what the poky distro does should be
> > safest and have the highest likelyhood of being accepted.
> 
> This is not directed at Rasmus, but a general comment ..
> 
> For pretty much anything kernel, and perf has always strongly been in
> that category, we've always unset everything and allowed the Makefiles
> (and the nested mess of tests, includes and trickery) to set their own
> flags. It has saved subtle runtime issues and this is one area that the
> developers tend to know what they are doing.

For the kernel itself, yes, they do. For userspace binaries, we do in
general have a good idea of how binaries should be being built and
we're a bit ahead of the curve on the flags/features that should be
configured.

> When there's a chance to append, they've give us a variable to do so,
> that's why we've always used EXTRA_CFLAGS, and that likely is the
> right place to use here as well. But even then, we shouldn't pass ALL of
> our flags in there, just what we think needs to be in addition to the
> perf generated set of CFLAGS.

I'm not entirely convinced of that. Which CFLAGS do we have which would
be harmful to userspace binaries?

I'm basically saying we should at least investigate this as I'm not
sure which things we have in CFLAGS would be problematic to userspace
binaries in general. It may not work and that is fine but I don't think
perf userspace should be that sensitive to the things we usually have
set.

Cheers,

Richard

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

Re: [OE-core] CVE work synchronization proposal

[Michael Opdenacker via lists.openembedded.org]

Hi Marta

On 20.10.23 at 10:36, Marta Rybczynska wrote:

Hello everyone,
We have a constant flow of work on pending CVEs. During my discussion
with multiple people, there is a common need for synchronization of
this work to avoid duplication or forgotten fixes.

We have a decision on the tooling to make: do we want to create a
Bugzilla entry for each new open CVE? An alternative is to use a wiki
page (this has been prototyped by Ross) with heavy scripting to
automate the tedious part.

Today I propose you to use a special wiki page and the following procedure:

On the wiki page, always add all additional information after a ; sign
to allow scripting. The first part of each line (until ";" ) will be
auto-generated. The second part contains information about the issue,
like who is investigating or what the situation is.

There is a separate list for each branch, as we realize that people
concentrate on various branches.

Workflow:

* Mark name of a person preparing a patch for each branch
* If you have additional information (like a link to a patch), add it
to the record
* If a patch is posted to the mailing list, post a link to it (this
will be automated)
* When a patch reaches the "next" branch, mark it too (this will be
automated too)
* When the patch reaches the final branch, the line of the CVE is
automatically removed (this is already automated)
* The list is (re)generated every day


Please have a look at the procedure proposal and how the tracking
might look like:

https://wiki.yoctoproject.org/wiki/Synchronization_CVEs



This looks very useful. Thanks!
If I understand correctly, the fact that the beginning of each line is 
generated automatically is a way to make sure nobody with Wiki write 
rights can hide a vulnerability by removing it from the list, right?


Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189538): 
https://lists.openembedded.org/g/openembedded-core/message/189538
Mute This Topic: https://lists.openembedded.org/mt/102077364/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 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support

[Richard Purdie]

On Fri, 2023-10-20 at 14:57 +0200, Julien Stephan wrote:
> Le jeu. 19 oct. 2023 à 20:34, Alexandre Belloni
>  a écrit :
> > 
> > On 19/10/2023 20:20:33+0200, Julien Stephan wrote:
> > > Le jeu. 19 oct. 2023 à 15:49, Alexandre Belloni
> > >  a écrit :
> > > > 
> > > > Hello,
> > > > 
> > > > On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> > > > > add support for PEP517 [1]
> > > > > 
> > > > > if a pyproject.toml file is found, use it to create the recipe,
> > > > > otherwise fallback to the old setup.py method.
> > > > > 
> > > > > [YOCTO #14737]
> > > > > 
> > > > > [1]: https://peps.python.org/pep-0517/
> > > > > 
> > > > > Signed-off-by: Julien Stephan 
> > > > > ---
> > > > >  .../lib/recipetool/create_buildsys_python.py  | 234 
> > > > > +-
> > > > >  1 file changed, 233 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/scripts/lib/recipetool/create_buildsys_python.py 
> > > > > b/scripts/lib/recipetool/create_buildsys_python.py
> > > > > index 69f6f5ca511..0b601d50a4b 100644
> > > > > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > > > > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > > > > @@ -18,6 +18,7 @@ import os
> > > > >  import re
> > > > >  import sys
> > > > >  import subprocess
> > > > > +import toml
> > > > 
> > > > This fails on the autobuilders because we don't have the toml module 
> > > > installed so I guess you need to add a dependency.
> > > > 
> > > 
> > > Hello,
> > > 
> > > Sure I 'll do it. Just to confirm, I should add it here:
> > > https://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host
> > > ?
> > 
> > I guess the preferred way would be to depend on python3-toml-native
> > instead of requiring installation on the host.
> > 
> 
> Hi Alexandre,
> 
> How am I supposed to do that for a script? Is that even possible? Am I
> missing something obvious?

As far as I know you're not missing anything obvious. If the toml
dependency was in the target recipe this would be easier but needing
this from recipetool is harder as it is running under the host python.

Adding dependencies for the host is hard as it needs to be added on the
docs, on the autobuilder workers and into our buildtools-extended-
tarballs and generally impacts a lot of people/places.

I think moving the import into the code and having recipe tool error
and ask the user to install the dependency might be the best solution
for now. That does give us a challenge over where/when we can test the
code though.

On the autobuilder we could run recipetool for this test using the
python3native from a recipe sysroot where the toml dependency is
available I guess but that is a bit ugly.

As Tim mentions, with python 3.11 onwards, this problem does go away.
We could also make the test conditional upon the host python version I
guess so it only runs on newer hosts?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189537): 
https://lists.openembedded.org/g/openembedded-core/message/189537
Mute This Topic: https://lists.openembedded.org/mt/102055999/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] shared-mime-info: Fix missing sentinel warning

[Ross Burton]

On 20 Oct 2023, at 14:58, Ross Burton  wrote:
> We might want to belt-and-braces this by backporting the fix to LLVM too?  
> https://github.com/llvm/llvm-project/issues/6057

Hm maybe not. That’s the referenced bug in the shared-mime-info commit but it 
was closed years ago…

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189536): 
https://lists.openembedded.org/g/openembedded-core/message/189536
Mute This Topic: https://lists.openembedded.org/mt/102065318/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] shared-mime-info: Fix missing sentinel warning

[Ross Burton]

We might want to belt-and-braces this by backporting the fix to LLVM too?  
https://github.com/llvm/llvm-project/issues/6057

Ross

> On 19 Oct 2023, at 18:44, Khem Raj via lists.openembedded.org 
>  wrote:
> 
> Clang finds it, gcc does not.
> 
> Signed-off-by: Khem Raj 
> ---
> v2: Some more warnings fixed with clang
> .../0001-Fix-literal-as-per-c-11.patch| 279 ++
> ...001-Fix-string-literal-concatenation.patch |  39 +++
> .../shared-mime-info/shared-mime-info_git.bb  |   5 +-
> 3 files changed, 322 insertions(+), 1 deletion(-)
> create mode 100644 
> meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
> create mode 100644 
> meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-string-literal-concatenation.patch
> 
> diff --git 
> a/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
>  
> b/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
> new file mode 100644
> index 000..25f409c206e
> --- /dev/null
> +++ 
> b/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
> @@ -0,0 +1,279 @@
> +From 157c16b09f54741aefbc4be6a3507455f0378389 Mon Sep 17 00:00:00 2001
> +From: Biswapriyo Nath 
> +Date: Sun, 8 Oct 2023 13:26:43 +
> +Subject: [PATCH] Fix missing sentinel warning with clang
> +
> +This fixes the compiler warnings similar as following.
> +
> +../src/update-mime-database.cpp:393:50: warning: missing sentinel in 
> function call [-Wsentinel]
> +  393 | g_strconcat(namespaceURI, " ", localName, 
> NULL),
> +  |  
>  ^
> +  |  
>  , nullptr
> +
> +Upstream-Status: Backport 
> [https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/157c16b09f54741aefbc4be6a3507455f0378389]
> +Signed-off-by: Khem Raj 
> +---
> + src/update-mime-database.cpp | 58 ++--
> + 1 file changed, 29 insertions(+), 29 deletions(-)
> +
> +--- a/src/update-mime-database.cpp
>  b/src/update-mime-database.cpp
> +@@ -390,7 +390,7 @@ static void add_namespace(Type *type, co
> + }
> + 
> + g_hash_table_insert(namespace_hash,
> +- g_strconcat(namespaceURI, " ", localName, NULL),
> ++ g_strconcat(namespaceURI, " ", localName, nullptr),
> + type);
> + }
> + 
> +@@ -1023,7 +1023,7 @@ static void write_out_type(gpointer key,
> + char *lower;
> + 
> + lower = g_ascii_strdown(type->media, -1);
> +- media = g_strconcat(mime_dir, "/", lower, NULL);
> ++ media = g_strconcat(mime_dir, "/", lower, nullptr);
> + g_free(lower);
> + #ifdef _WIN32
> + fs::create_directory(media);
> +@@ -1032,7 +1032,7 @@ static void write_out_type(gpointer key,
> + #endif
> + 
> + lower = g_ascii_strdown(type->subtype, -1);
> +- filename = g_strconcat(media, "/", lower, ".xml.new", NULL);
> ++ filename = g_strconcat(media, "/", lower, ".xml.new", nullptr);
> + g_free(lower);
> + g_free(media);
> + media = NULL;
> +@@ -1622,7 +1622,7 @@ static Magic *magic_new(xmlNode *node, T
> + magic_free(magic);
> + magic = NULL;
> + (*error)->message = g_strconcat(
> +- _("Error in  element: "), old, NULL);
> ++ _("Error in  element: "), old, nullptr);
> + g_free(old);
> + } else if (magic->matches == NULL) {
> + magic_free(magic);
> +@@ -1843,7 +1843,7 @@ static TreeMagic *tree_magic_new(xmlNode
> + tree_magic_free(magic);
> + magic = NULL;
> + (*error)->message = g_strconcat(
> +- _("Error in  element: "), old, NULL);
> ++ _("Error in  element: "), old, nullptr);
> + g_free(old);
> + }
> + }
> +@@ -1960,7 +1960,7 @@ static void delete_old_types(const gchar
> + 
> + for (i = 0; i < G_N_ELEMENTS(media_types); i++)
> + {
> +- const fs::path media_dir = g_strconcat(mime_dir, "/", media_types[i], 
> NULL);
> ++ const fs::path media_dir = g_strconcat(mime_dir, "/", media_types[i], 
> nullptr);
> + 
> + if (!fs::is_directory(fs::status(media_dir)))
> + continue;
> +@@ -1973,13 +1973,13 @@ static void delete_old_types(const gchar
> + continue;
> + 
> + char *type_name = g_strconcat(media_types[i], "/",
> +- dir_entry.path().filename().string().c_str(), NULL);
> ++ dir_entry.path().filename().string().c_str(), nullptr);
> + type_name[strlen(type_name) - 4] = '\0';
> + if (!g_hash_table_lookup(types, type_name))
> + {
> + char *path;
> + path = g_strconcat(mime_dir, "/",
> +- type_name, ".xml", NULL);
> ++ type_name, ".xml", nullptr);
> + #if 0
> + g_warning("Removing old info for type %s",
> + path);
> +@@ -2002,7 +2002,7 @@ static void add_ns(gpointer key, gpointe
> + Type *type = (Type *) value;
> + 
> + g_ptr_array_add(lines, g_strconcat(ns, " ", type->media,
> +-   "/", type->subtype, "\n", NULL));
> ++   "/", type->subtype, "\n", nullptr));
> + }
> + 
> + /* Write all the collected namespace rules to 'XMLnamespaces' */
> +@@ -2038,7 +2038,7 @@ static void write_subclass(gpointer key,
> 

Re: [OE-core] [mickledore] glibc: stable 2.37 branch updates.

[Steve Sakoman]

On Thu, Oct 19, 2023 at 1:02 PM Khem Raj  wrote:
>
>
>
> On Thu, Oct 19, 2023 at 5:16 AM Sanjana.Venkatesh via lists.openembedded.org 
>  wrote:
>>
>> Hi Khem,
>>
>> We tried increasing the memory and no regression failures were found.
>>
>
>
> Thanks for following up
>
> Steve
>
> We can cherry pick this for mickledore I think now

Done!

Steve

>
>> Here is the test results:
>>
>> Regression testing is done and below are the test results.
>> Before glibc update
>> Summary of test results:
>> PASS:4727
>> FAIL:240
>> XPASS:4
>> XFAIL:16
>> UNSUPPORTED:220
>>
>> After glibc update
>> Summary of test results:
>> PASS:4733
>> FAIL:235
>> XPASS:4
>> XFAIL:16
>> UNSUPPORTED:221
>>
>> These are the newly added test cases
>> PASS: io/tst-fcntl-lock-lfs
>> UNSUPPORTED: nss/mtrace-tst-nss-gai-hv2-canonname
>>
>> These are the tests which were failing before and passed after increasing 
>> the memory:
>> PASS: nptl/tst-thread-affinity-pthread
>> PASS: nptl/tst-thread-affinity-pthread2
>> PASS: nptl/tst-thread-affinity-sched
>>
>>
>>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189534): 
https://lists.openembedded.org/g/openembedded-core/message/189534
Mute This Topic: https://lists.openembedded.org/mt/101774187/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] selftest/sstatetests: add tests for 'bitbake -S printdiff'

[Richard Purdie]

On Fri, 2023-10-20 at 15:12 +0200, Alexander Kanavin wrote:
> On Wed, 18 Oct 2023 at 21:39, Alexandre Belloni
>  wrote:
> > ERROR: Can't find a task we're supposed to have written out? (hash: 
> > e79d70b9c2cc72030c1ce822525510699a1eeb1ddf5986271d3217422244366a)?
> > ERROR: Can't find a task we're supposed to have written out? (hash: 
> > 999250461834bf74545962a8577bc26854a3d08bb2a96140d5efe314e0ef2d63)?
> 
> This is proving tricky to reproduce. It happens fairly reliably in
> oe-selftest-armhost, but so far never on regular oe-selftest, or in
> standalone local build on an arm host where I run only the selftests
> that are failing. It seems like one of those dreaded selftest things
> that fail only in particular execution order with other tests.
> 
> The only idea I have right now is to run specially configured
> oe-selftest-armhost which would run only a subset (e.g. just
> sstatetests) and see if it can be narrowed down from there.
> 
> I'm also tempted to set this aside for now as it has all the signs of
> protracted, painful debugging slog, and push the esdk/sstate build
> registry subject, so there's something to show for it soon.

I did idly wonder if we need to set the sig handler to not use
hashequiv for these tests? I haven't checked if that would help though,
I'm just making a wild guess.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189533): 
https://lists.openembedded.org/g/openembedded-core/message/189533
Mute This Topic: https://lists.openembedded.org/mt/102035446/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 4/4] package_rpm.bbclass: Support compression override

[Niko Mauno via lists.openembedded.org]

On 20.10.2023 16.00, Richard Purdie wrote:

Is it common for people to need to manipulate rpms on target without
rpm being present using busybox? Do you know if busybox plans to add
zstd support?

As far as I could tell when we looked at this, the rpm world was moving
over to zstd so adding in conditional xz support for a limited use case
probably just creates a maintenance headache going forward as it isn't
something we test or plan to test?

Are you using this on an LTS release or master?


Hi Richard,

After moving to Yocto Kirkstone (LTS) which we currently use, we started
getting developer reports of 'no gzip/bzip2/xz magic' error from BusyBox
applet. For example developer uploads an rpm file to target device and
then unpacks it in runtime using 'rpm2cpio  | cpio -idmv'
command.

We don't include rpm package on target filesystems as that would
increase rootfs footprint approximately 5 MB. Including only rpm2cpio
from rpm package needs still accompanying libraries, increasing the size
by 2.5 MB approximately which also feels too big.

I checked the discussions from BusyBox mailing list and found that in
2021 the maintainer seemed reluctant to accept the proposed zstd support
because it was not optimized for embedded systems.
http://lists.busybox.net/pipermail/busybox/2021-September/089179.html

BR, Niko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189532): 
https://lists.openembedded.org/g/openembedded-core/message/189532
Mute This Topic: https://lists.openembedded.org/mt/102080114/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 3/3] lighttpd: modernize lighttpd.conf

[Glenn Strauss]

From: Glenn Strauss 

- remove obsolete modules
- replace mod_compress directives with mod_deflate
- do not enable debug.log-request-handling by default
  (should not be enabled *by default* on any production system,
   especially not an embedded system)
- update TLS syntax for modern recommended use
  (separate files for certificate+chain, and private key)
- remove incorrect comment about server.event-handler
  lighttpd defaults correctly to use kqueue on *BSD systems
- remove ancient config which disables range requests for PDF
  (cargo-culted config from ~15 years ago to address problem
   in then-popular PDF client)
- use recommend config file include syntax
  (more efficient and more deterministic include file ordering)

Signed-off-by: Glenn Strauss 
---
 .../lighttpd/lighttpd/lighttpd.conf   | 38 ---
 1 file changed, 8 insertions(+), 30 deletions(-)

diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.conf 
b/meta/recipes-extended/lighttpd/lighttpd/lighttpd.conf
index 6e8402d242..47a6c93349 100644
--- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.conf
+++ b/meta/recipes-extended/lighttpd/lighttpd/lighttpd.conf
@@ -16,8 +16,6 @@ server.modules  = (
 #   "mod_redirect",
 #   "mod_alias",
 "mod_access",
-#   "mod_cml",
-#   "mod_trigger_b4_dl",
 #   "mod_auth",
 #   "mod_status",
 #   "mod_setenv",
@@ -27,11 +25,9 @@ server.modules  = (
 #   "mod_evhost",
 #   "mod_userdir",
 #   "mod_cgi",
-#   "mod_compress",
 #   "mod_ssi",
-#   "mod_usertrack",
 #   "mod_expire",
-#   "mod_secdownload",
+#   "mod_deflate",
 #   "mod_rrdtool",
 #  "mod_webdav",
 "mod_accesslog" )
@@ -47,9 +43,6 @@ server.errorlog = "/www/logs/lighttpd.error.log"
 index-file.names= ( "index.php", "index.html",
 "index.htm", "default.htm" )
 
-## set the event-handler (read the performance section in the manual)
-# server.event-handler = "freebsd-kqueue" # needed on OS X
-
 # mimetype mapping
 mimetype.assign = (
   ".pdf"  =>  "application/pdf",
@@ -115,7 +108,6 @@ mimetype.assign = (
 
  accesslog module
 accesslog.filename  = "/www/logs/access.log"
-debug.log-request-handling = "enable"
 
 
 
@@ -127,10 +119,6 @@ debug.log-request-handling = "enable"
 #  of the document-root
 url.access-deny = ( "~", ".inc" )
 
-$HTTP["url"] =~ "\.pdf$" {
-  server.range-requests = "disable"
-}
-
 ##
 # which extensions should not be handle via static-file transfer
 #
@@ -177,6 +165,7 @@ static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
 #dir-listing.activate   = "enable"
 
 ## enable debugging
+#debug.log-request-header-on-error = "enable"
 #debug.log-request-header   = "enable"
 #debug.log-response-header  = "enable"
 #debug.log-request-handling = "enable"
@@ -194,8 +183,9 @@ static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
 #server.groupname   = "wwwrun"
 
  compress module
-#compress.cache-dir = "/tmp/lighttpd/cache/compress/"
-#compress.filetype  = ("text/plain", "text/html")
+#deflate.cache-dir  = "/tmp/lighttpd/cache/compress/"
+#deflate.mimetypes  = ("text/plain", "text/html")
+#deflate.allowed-encodings  = ("gzip")
 
  proxy module
 ## read proxy.txt for more info
@@ -227,7 +217,8 @@ static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
 
  SSL engine
 #ssl.engine = "enable"
-#ssl.pemfile= "server.pem"
+#ssl.pemfile= "/path/to/fullchain.pem"
+#ssl.privkey= "/path/to/privkey.pem"
 
  status module
 #status.status-url  = "/server-status"
@@ -291,19 +282,6 @@ static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
 #setenv.add-request-header  = ( "TRAV_ENV" => "mysql://user@host/db" )
 #setenv.add-response-header = ( "X-Secret-Message" => "42" )
 
-## for mod_trigger_b4_dl
-# trigger-before-download.gdbm-filename = "/home/weigon/testbase/trigger.db"
-# trigger-before-download.memcache-hosts = ( "127.0.0.1:11211" )
-# trigger-before-download.trigger-url = "^/trigger/"
-# trigger-before-download.download-url = "^/download/"
-# trigger-before-download.deny-url = "http://127.0.0.1/index.html;
-# trigger-before-download.trigger-timeout = 10
-
-## for mod_cml
-## don't forget to add index.cml to server.indexfiles
-# cml.extension   = ".cml"

[OE-core] [PATCH 1/3] lighttpd: upgrade 1.4.71 -> 1.4.72

[Glenn Strauss]

From: Glenn Strauss 

Signed-off-by: Glenn Strauss 
---
 .../lighttpd/{lighttpd_1.4.71.bb => lighttpd_1.4.72.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/lighttpd/{lighttpd_1.4.71.bb => 
lighttpd_1.4.72.bb} (97%)

diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.71.bb 
b/meta/recipes-extended/lighttpd/lighttpd_1.4.72.bb
similarity index 97%
rename from meta/recipes-extended/lighttpd/lighttpd_1.4.71.bb
rename to meta/recipes-extended/lighttpd/lighttpd_1.4.72.bb
index 3959f88b98..87058719f9 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.71.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.72.bb
@@ -16,7 +16,7 @@ SRC_URI = 
"http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.t
file://lighttpd \
"
 
-SRC_URI[sha256sum] = 
"b8b6915da20396fdc354df3324d5e440169b2e5ea7859e3a775213841325afac"
+SRC_URI[sha256sum] = 
"f7cade4d69b754a0748c01463c33cd8b456ca9cc03bb09e85a71bcbcd54e55ec"
 
 DEPENDS = "virtual/crypt"
 
-- 
2.41.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189529): 
https://lists.openembedded.org/g/openembedded-core/message/189529
Mute This Topic: https://lists.openembedded.org/mt/102080918/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 2/3] lighttpd: update init script

[Glenn Strauss]

From: Glenn Strauss 

- add configtest option
- add configtest before starting, restart, reload, force-reload
- change reload,force-reload to use lighttpd graceful restart
  via kill signal USR1

Signed-off-by: Glenn Strauss 
---
 .../lighttpd/lighttpd/lighttpd| 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd 
b/meta/recipes-extended/lighttpd/lighttpd/lighttpd
index 82fbaa523b..f369dce42c 100644
--- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd
+++ b/meta/recipes-extended/lighttpd/lighttpd/lighttpd
@@ -6,9 +6,14 @@ NAME=lighttpd
 DESC="Lighttpd Web Server"
 OPTS="-f /etc/lighttpd/lighttpd.conf"
 
+configtest() {
+   "$DAEMON" $OPTS -tt || exit 1
+}
+
 case "$1" in
   start)
echo -n "Starting $DESC: "
+   configtest
start-stop-daemon --start -x "$DAEMON" -- $OPTS
echo "$NAME."
;;
@@ -17,16 +22,26 @@ case "$1" in
start-stop-daemon --stop -x "$DAEMON"
echo "$NAME."
;;
-  restart|force-reload)
+  restart)
echo -n "Restarting $DESC: "
+   configtest
start-stop-daemon --stop -x "$DAEMON"
sleep 1
start-stop-daemon --start -x "$DAEMON" -- $OPTS
echo "$NAME."
;;
+  reload|force-reload)
+   echo -n "Reloading $DESC: "
+   configtest
+   killall -USR1 "${DAEMON##*/}"
+   echo "$NAME."
+   ;;
+  configtest)
+   configtest
+   ;;
   *)
N=/etc/init.d/$NAME
-   echo "Usage: $N {start|stop|restart|force-reload}" >&2
+   echo "Usage: $N {start|stop|restart|reload|force-reload|configtest}" >&2
exit 1
;;
 esac
-- 
2.41.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189530): 
https://lists.openembedded.org/g/openembedded-core/message/189530
Mute This Topic: https://lists.openembedded.org/mt/102080919/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 0/3] lighttpd-1.4.72

[Glenn Strauss]

From: Glenn Strauss 


Glenn Strauss (3):
  lighttpd: upgrade 1.4.71 -> 1.4.72
  lighttpd: update init script
  lighttpd: modernize lighttpd.conf

 .../lighttpd/lighttpd/lighttpd| 19 +-
 .../lighttpd/lighttpd/lighttpd.conf   | 38 ---
 ...{lighttpd_1.4.71.bb => lighttpd_1.4.72.bb} |  2 +-
 3 files changed, 26 insertions(+), 33 deletions(-)
 rename meta/recipes-extended/lighttpd/{lighttpd_1.4.71.bb => 
lighttpd_1.4.72.bb} (97%)

-- 
2.41.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189528): 
https://lists.openembedded.org/g/openembedded-core/message/189528
Mute This Topic: https://lists.openembedded.org/mt/102080914/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] selftest/sstatetests: add tests for 'bitbake -S printdiff'

[Alexander Kanavin]

On Wed, 18 Oct 2023 at 21:39, Alexandre Belloni
 wrote:
> ERROR: Can't find a task we're supposed to have written out? (hash: 
> e79d70b9c2cc72030c1ce822525510699a1eeb1ddf5986271d3217422244366a)?
> ERROR: Can't find a task we're supposed to have written out? (hash: 
> 999250461834bf74545962a8577bc26854a3d08bb2a96140d5efe314e0ef2d63)?

This is proving tricky to reproduce. It happens fairly reliably in
oe-selftest-armhost, but so far never on regular oe-selftest, or in
standalone local build on an arm host where I run only the selftests
that are failing. It seems like one of those dreaded selftest things
that fail only in particular execution order with other tests.

The only idea I have right now is to run specially configured
oe-selftest-armhost which would run only a subset (e.g. just
sstatetests) and see if it can be narrowed down from there.

I'm also tempted to set this aside for now as it has all the signs of
protracted, painful debugging slog, and push the esdk/sstate build
registry subject, so there's something to show for it soon.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189527): 
https://lists.openembedded.org/g/openembedded-core/message/189527
Mute This Topic: https://lists.openembedded.org/mt/102035446/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 4/4] package_rpm.bbclass: Support compression override

[Richard Purdie]

On Fri, 2023-10-20 at 12:44 +, Niko Mauno via
lists.openembedded.org wrote:
> From: Niko Mauno 
> 
> Commit 4a4d5f78a6962dda5f63e9891825c80a8a87bf66 ("package_rpm: use zstd
> instead of xz") changed the rpm package compressor from 'xz' to 'zstd'
> which results in decompression failure with BusyBox-provided 'rpm2cpio'
> applet and 'rpm' applet when given the '-i' (Install package) option:
> 
>   rpm2cpio: no gzip/bzip2/xz magic
> 
> In order to maintain compatibility with BusyBox introduce new variable
> which can be overridden like:
> 
>   RPM_COMPRESSION = "xz"
> 
> to enable rpm decompression without including the full rpm package in
> the resulting root filesystem.

Is it common for people to need to manipulate rpms on target without
rpm being present using busybox? Do you know if busybox plans to add
zstd support?

As far as I could tell when we looked at this, the rpm world was moving
over to zstd so adding in conditional xz support for a limited use case
probably just creates a maintenance headache going forward as it isn't
something we test or plan to test?

Are you using this on an LTS release or master?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189526): 
https://lists.openembedded.org/g/openembedded-core/message/189526
Mute This Topic: https://lists.openembedded.org/mt/102080114/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 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support

[Julien Stephan]

Le jeu. 19 oct. 2023 à 20:34, Alexandre Belloni
 a écrit :
>
> On 19/10/2023 20:20:33+0200, Julien Stephan wrote:
> > Le jeu. 19 oct. 2023 à 15:49, Alexandre Belloni
> >  a écrit :
> > >
> > > Hello,
> > >
> > > On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> > > > add support for PEP517 [1]
> > > >
> > > > if a pyproject.toml file is found, use it to create the recipe,
> > > > otherwise fallback to the old setup.py method.
> > > >
> > > > [YOCTO #14737]
> > > >
> > > > [1]: https://peps.python.org/pep-0517/
> > > >
> > > > Signed-off-by: Julien Stephan 
> > > > ---
> > > >  .../lib/recipetool/create_buildsys_python.py  | 234 +-
> > > >  1 file changed, 233 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/scripts/lib/recipetool/create_buildsys_python.py 
> > > > b/scripts/lib/recipetool/create_buildsys_python.py
> > > > index 69f6f5ca511..0b601d50a4b 100644
> > > > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > > > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > > > @@ -18,6 +18,7 @@ import os
> > > >  import re
> > > >  import sys
> > > >  import subprocess
> > > > +import toml
> > >
> > > This fails on the autobuilders because we don't have the toml module 
> > > installed so I guess you need to add a dependency.
> > >
> >
> > Hello,
> >
> > Sure I 'll do it. Just to confirm, I should add it here:
> > https://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host
> > ?
>
> I guess the preferred way would be to depend on python3-toml-native
> instead of requiring installation on the host.
>

Hi Alexandre,

How am I supposed to do that for a script? Is that even possible? Am I
missing something obvious?

Cheers
Julien

> >
> > Cheers
> > Julien
> >
> > > >  from recipetool.create import RecipeHandler
> > > >
> > > >  logger = logging.getLogger('recipetool')
> > > > @@ -656,6 +657,235 @@ class 
> > > > PythonSetupPyRecipeHandler(PythonRecipeHandler):
> > > >
> > > >  handled.append('buildsystem')
> > > >
> > > > +class PythonPyprojectTomlRecipeHandler(PythonRecipeHandler):
> > > > +"""Base class to support PEP517 and PEP518
> > > > +
> > > > +PEP517 https://peps.python.org/pep-0517/#source-trees
> > > > +PEP518 https://peps.python.org/pep-0518/#build-system-table
> > > > +"""
> > > > +
> > > > +# PEP621: 
> > > > https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
> > > > +# add only the ones that map to a BB var
> > > > +# potentially missing: optional-dependencies
> > > > +bbvar_map = {
> > > > +"name": "PN",
> > > > +"version": "PV",
> > > > +"Homepage": "HOMEPAGE",
> > > > +"description": "SUMMARY",
> > > > +"license": "LICENSE",
> > > > +"dependencies": "RDEPENDS:${PN}",
> > > > +"requires": "DEPENDS",
> > > > +}
> > > > +
> > > > +replacements = [
> > > > +("license", r" +$", ""),
> > > > +("license", r"^ +", ""),
> > > > +("license", r" ", "-"),
> > > > +("license", r"^GNU-", ""),
> > > > +("license", r"-[Ll]icen[cs]e(,?-[Vv]ersion)?", ""),
> > > > +("license", r"^UNKNOWN$", ""),
> > > > +# Remove currently unhandled version numbers from these 
> > > > variables
> > > > +("requires", r"\[[^\]]+\]$", ""),
> > > > +("requires", r"^([^><= ]+).*", r"\1"),
> > > > +("dependencies", r"\[[^\]]+\]$", ""),
> > > > +("dependencies", r"^([^><= ]+).*", r"\1"),
> > > > +]
> > > > +
> > > > +build_backend_map = {
> > > > +"setuptools.build_meta": "python_setuptools_build_meta",
> > > > +"poetry.core.masonry.api": "python_poetry_core",
> > > > +"flit_core.buildapi": "python_flit_core",
> > > > +}
> > > > +
> > > > +excluded_native_pkgdeps = [
> > > > +# already provided by python_setuptools_build_meta.bbclass
> > > > +"python3-setuptools-native",
> > > > +"python3-wheel-native",
> > > > +# already provided by python_poetry_core.bbclass
> > > > +"python3-poetry-core-native",
> > > > +# already provided by python_flit_core.bbclass
> > > > +"python3-flit-core-native",
> > > > +]
> > > > +
> > > > +# add here a list of known and often used packages and the 
> > > > corresponding bitbake package
> > > > +known_deps_map = {
> > > > +"setuptools": "python3-setuptools",
> > > > +"wheel": "python3-wheel",
> > > > +"poetry-core": "python3-poetry-core",
> > > > +"flit_core": "python3-flit-core",
> > > > +"setuptools-scm": "python3-setuptools-scm",
> > > > +}
> > > > +
> > > > +def __init__(self):
> > > > +pass
> > > > +
> > > > +def process(self, srctree, classes, lines_before, lines_after, 
> > > > handled, extravalues):
> > > > +info = {}
> > > > +
> > > > +if 'buildsystem' in handled:
> > > > +return False
> > > > +
> > 

Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Bruce Ashfield]

On Fri, Oct 20, 2023 at 7:19 AM Rasmus Villemoes
 wrote:
>
> On 20/10/2023 12.13, Richard Purdie wrote:
> > On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote:
> >> On 20/10/2023 11.38, Richard Purdie wrote:
> >>> On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
>  On 19/10/2023 14.48, Richard Purdie wrote:
> >>
> > The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
> > anything in the perf build system where we should be passing in cflags
> > we really want used?
> 
>  Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
>  'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
>  do_compile and do_install start with
> 
>  # Linux kernel build system is expected to do the right thing
>  unset CFLAGS
> 
>  And perf's build system does indeed add lots of flags of its own, at
>  least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
>  set.
> 
>  So I do think that TARGET_CC_ARCH is the best place for flags that we
>  really want used. At least as an initial step, because this is known to
>  work when using the security_flags.inc file. Maybe there's some cleaner
>  way where we don't unset CFLAGS, but that could be a giant can of worms.
> 
>  And yes, a comment should be added. Is something like
> 
>  # Perf's build system adds its own optimization flags for most TUs,
>  # overriding the flags included here. But for some, perf does not add
>  # any -O option, so ensure the distro's chosen optimization gets used
>  # for those. Since ${SELECTED_OPTIMIZATION} always includes
>  # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
>  # ensures perf is built with appropriate -f*-prefix-map options,
>  # avoiding the 'buildpaths' QA warning.
> 
>  too verbose?
> >>>
> >>> If it were me I'd probably write:
> >>>
> >>> # The perf makefile has "unset CFLAGS" as "Linux kernel build system is
> >>> # expected to do the right thing".
> >>
> >> It's not the perf makefile, it's right there in our recipe itself. I
> >> don't think upstream perf is to blame.
> >
> > Sorry, I misunderstood. I thought this was the perf environment that
> > was doing this so in that case your comment does make much more sense
> > than mine.
>
> OK. Bruce, should I resend?

Yes, let's go for a resend with the comment added. If we can avoid even some of
the pain wondering about this again .. our future selves will thank us :)

>
> > Out of interest did you see what happens if you allow our CFLAGS in and
> > remove that unset?
>
> I don't think I've tried that, but I've tried a few other things that I
> thought would be cleaner but which then exploded, so in the end I
> decided that just lifting exactly what the poky distro does should be
> safest and have the highest likelyhood of being accepted.

This is not directed at Rasmus, but a general comment ..

For pretty much anything kernel, and perf has always strongly been in
that category, we've always unset everything and allowed the Makefiles
(and the nested mess of tests, includes and trickery) to set their own
flags. It has saved subtle runtime issues and this is one area that the
developers tend to know what they are doing.

When there's a chance to append, they've give us a variable to do so,
that's why we've always used EXTRA_CFLAGS, and that likely is the
right place to use here as well. But even then, we shouldn't pass ALL of
our flags in there, just what we think needs to be in addition to the
perf generated set of CFLAGS.

Bruce

>
> > I also wondered if EXTRA_CFLAGS in EXTRA_OEMAKE
> > might be an option?
>
> Based on quick reading of perf build documentation, yes, EXTRA_CFLAGS
> seems like a reasonable approach. What I'm a little worried about is the
> TUs where perf apparently does not by itself add all its cflags (-O6 and
> whatnot), so I'm not sure if they would be built with what is passed via
> EXTRA_CFLAGS.
>
> I will experiment sometime next week if I remember and nothing else
> preempts that plan.
>
> > I'm a bit worried that the current situation all feels a little
> > fragile.
>
> Agree. But the QA checks do help quite a lot here.
>
> Rasmus
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189524): 
https://lists.openembedded.org/g/openembedded-core/message/189524
Mute This Topic: https://lists.openembedded.org/mt/102058904/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 4/4] package_rpm.bbclass: Support compression override

[Niko Mauno via lists.openembedded.org]

From: Niko Mauno 

Commit 4a4d5f78a6962dda5f63e9891825c80a8a87bf66 ("package_rpm: use zstd
instead of xz") changed the rpm package compressor from 'xz' to 'zstd'
which results in decompression failure with BusyBox-provided 'rpm2cpio'
applet and 'rpm' applet when given the '-i' (Install package) option:

  rpm2cpio: no gzip/bzip2/xz magic

In order to maintain compatibility with BusyBox introduce new variable
which can be overridden like:

  RPM_COMPRESSION = "xz"

to enable rpm decompression without including the full rpm package in
the resulting root filesystem.

Signed-off-by: Niko Mauno 
---
 meta/classes-global/package_rpm.bbclass | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/meta/classes-global/package_rpm.bbclass 
b/meta/classes-global/package_rpm.bbclass
index 246106ea4f..da25b7682c 100644
--- a/meta/classes-global/package_rpm.bbclass
+++ b/meta/classes-global/package_rpm.bbclass
@@ -13,6 +13,9 @@ RPMBUILD = "rpmbuild"
 
 PKGWRITEDIRRPM = "${WORKDIR}/deploy-rpms"
 
+# Override variable to use alternative 'xz' or 'none' compression
+RPM_COMPRESSION ?= "zstd"
+
 # Maintaining the perfile dependencies has significant overhead when writing 
the
 # packages. When set, this value merges them for efficiency.
 MERGEPERFILEDEPS = "1"
@@ -659,6 +662,7 @@ python do_package_rpm () {
 
 # Setup the rpmbuild arguments...
 rpmbuild = d.getVar('RPMBUILD')
+rpmcomp = d.getVar('RPM_COMPRESSION')
 
 # Too many places in dnf stack assume that arch-independent packages are 
"noarch".
 # Let's not fight against this.
@@ -682,8 +686,16 @@ python do_package_rpm () {
 cmd = cmd + " --define '_use_internal_dependency_generator 0'"
 cmd = cmd + " --define '_binaries_in_noarch_packages_terminate_build 0'"
 cmd = cmd + " --define '_build_id_links none'"
-cmd = cmd + " --define '_binary_payload w19T%d.zstdio'" % 
int(d.getVar("ZSTD_THREADS"))
-cmd = cmd + " --define '_source_payload w19T%d.zstdio'" % 
int(d.getVar("ZSTD_THREADS"))
+if rpmcomp == "zstd":
+cmd = cmd + " --define '_binary_payload w19T%d.zstdio'" % 
int(d.getVar("ZSTD_THREADS"))
+cmd = cmd + " --define '_source_payload w19T%d.zstdio'" % 
int(d.getVar("ZSTD_THREADS"))
+elif rpmcomp == 'xz':
+cmd = cmd + " --define '_binary_payload w6T%d.xzdio'" % 
int(d.getVar("XZ_THREADS"))
+cmd = cmd + " --define '_source_payload w6T%d.xzdio'" % 
int(d.getVar("XZ_THREADS"))
+elif rpmcomp == 'none':
+pass
+else:
+bb.fatal('unsupported rpm compression method: "%s"' % rpmcomp)
 cmd = cmd + " --define 'clamp_mtime_to_source_date_epoch 1'"
 cmd = cmd + " --define 'use_source_date_epoch_as_buildtime 1'"
 cmd = cmd + " --define '_buildhost reproducible'"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189523): 
https://lists.openembedded.org/g/openembedded-core/message/189523
Mute This Topic: https://lists.openembedded.org/mt/102080114/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 3/4] package_rpm.bbclass: Remove unused definitions

[Niko Mauno via lists.openembedded.org]

From: Niko Mauno 

Some local variables defined in do_package_rpm() are not referenced, so
remove such dead code lines.

Signed-off-by: Niko Mauno 
---
 meta/classes-global/package_rpm.bbclass | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/classes-global/package_rpm.bbclass 
b/meta/classes-global/package_rpm.bbclass
index 402fa5c4e8..246106ea4f 100644
--- a/meta/classes-global/package_rpm.bbclass
+++ b/meta/classes-global/package_rpm.bbclass
@@ -633,7 +633,6 @@ python do_package_rpm () {
 workdir = d.getVar('WORKDIR')
 tmpdir = d.getVar('TMPDIR')
 pkgd = d.getVar('PKGD')
-pkgdest = d.getVar('PKGDEST')
 if not workdir or not pkgd or not tmpdir:
 bb.error("Variables incorrectly set, unable to package")
 return
@@ -660,8 +659,6 @@ python do_package_rpm () {
 
 # Setup the rpmbuild arguments...
 rpmbuild = d.getVar('RPMBUILD')
-targetsys = d.getVar('TARGET_SYS')
-targetvendor = d.getVar('HOST_VENDOR')
 
 # Too many places in dnf stack assume that arch-independent packages are 
"noarch".
 # Let's not fight against this.
@@ -669,7 +666,6 @@ python do_package_rpm () {
 if package_arch == "all":
 package_arch = "noarch"
 
-sdkpkgsuffix = (d.getVar('SDKPKGSUFFIX') or "nativesdk").replace("-", "_")
 d.setVar('PACKAGE_ARCH_EXTEND', package_arch)
 pkgwritedir = d.expand('${PKGWRITEDIRRPM}/${PACKAGE_ARCH_EXTEND}')
 d.setVar('RPM_PKGWRITEDIR', pkgwritedir)
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189522): 
https://lists.openembedded.org/g/openembedded-core/message/189522
Mute This Topic: https://lists.openembedded.org/mt/102080112/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 2/4] package_rpm.bbclass: Minor cosmetic and style fixes

[Niko Mauno via lists.openembedded.org]

From: Niko Mauno 

Add the missing conventional space characters around bitbake variable
assignment operators. Also fix a typo on a comment line.

Signed-off-by: Niko Mauno 
---
 meta/classes-global/package_rpm.bbclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes-global/package_rpm.bbclass 
b/meta/classes-global/package_rpm.bbclass
index 992446a033..402fa5c4e8 100644
--- a/meta/classes-global/package_rpm.bbclass
+++ b/meta/classes-global/package_rpm.bbclass
@@ -8,12 +8,12 @@ inherit package
 
 IMAGE_PKGTYPE ?= "rpm"
 
-RPM="rpm"
-RPMBUILD="rpmbuild"
+RPM = "rpm"
+RPMBUILD = "rpmbuild"
 
 PKGWRITEDIRRPM = "${WORKDIR}/deploy-rpms"
 
-# Maintaining the perfile dependencies has singificant overhead when writing 
the
+# Maintaining the perfile dependencies has significant overhead when writing 
the
 # packages. When set, this value merges them for efficiency.
 MERGEPERFILEDEPS = "1"
 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189521): 
https://lists.openembedded.org/g/openembedded-core/message/189521
Mute This Topic: https://lists.openembedded.org/mt/102080104/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/4] package_rpm.bbclass: Fix some pycodestyle issues

[Niko Mauno via lists.openembedded.org]

From: Niko Mauno 

Fix following subset of observations reported by version 2.10.0 of
pycodestyle utility:

  meta/classes-global/package_rpm.bbclass:65:46: E231 missing whitespace after 
','
  meta/classes-global/package_rpm.bbclass:66:46: E231 missing whitespace after 
','
  meta/classes-global/package_rpm.bbclass:107:19: E231 missing whitespace after 
','
  meta/classes-global/package_rpm.bbclass:109:69: E202 whitespace before ')'
  meta/classes-global/package_rpm.bbclass:122:103: W291 trailing whitespace
  meta/classes-global/package_rpm.bbclass:194:74: W291 trailing whitespace
  meta/classes-global/package_rpm.bbclass:448:16: E713 test for membership 
should be 'not in'
  meta/classes-global/package_rpm.bbclass:450:16: E713 test for membership 
should be 'not in'
  meta/classes-global/package_rpm.bbclass:520:1: W293 blank line contains 
whitespace
  meta/classes-global/package_rpm.bbclass:521:15: E231 missing whitespace after 
','
  meta/classes-global/package_rpm.bbclass:542:12: E713 test for membership 
should be 'not in'
  meta/classes-global/package_rpm.bbclass:544:12: E713 test for membership 
should be 'not in'
  meta/classes-global/package_rpm.bbclass:647:67: W291 trailing whitespace

Signed-off-by: Niko Mauno 
---
 meta/classes-global/package_rpm.bbclass | 26 -
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/classes-global/package_rpm.bbclass 
b/meta/classes-global/package_rpm.bbclass
index 85d0bd7fce..992446a033 100644
--- a/meta/classes-global/package_rpm.bbclass
+++ b/meta/classes-global/package_rpm.bbclass
@@ -62,8 +62,8 @@ def write_rpm_perfiledata(srcname, d):
 for dep in depends_dict:
 ver = depends_dict[dep]
 if dep and ver:
-ver = ver.replace("(","")
-ver = ver.replace(")","")
+ver = ver.replace("(", "")
+ver = ver.replace(")", "")
 outfile.write(dep + " " + ver + " ")
 else:
 outfile.write(dep + " ")
@@ -104,9 +104,9 @@ python write_specfile () {
 import oe.packagedata
 
 # append information for logs and patches to %prep
-def add_prep(d,spec_files_bottom):
+def add_prep(d, spec_files_bottom):
 if d.getVarFlag('ARCHIVER_MODE', 'srpm') == '1' and 
bb.data.inherits_class('archiver', d):
-spec_files_bottom.append('%%prep -n %s' % d.getVar('PN') )
+spec_files_bottom.append('%%prep -n %s' % d.getVar('PN'))
 spec_files_bottom.append('%s' % "echo \"include logs and patches, 
Please check them in SOURCES\"")
 spec_files_bottom.append('')
 
@@ -119,7 +119,7 @@ python write_specfile () {
 source_list = os.listdir(ar_outdir)
 source_number = 0
 for source in source_list:
-# do_deploy_archives may have already run (from sstate) 
meaning a .src.rpm may already 
+# do_deploy_archives may have already run (from sstate) 
meaning a .src.rpm may already
 # exist in ARCHIVER_OUTDIR so skip if present.
 if source.endswith(".src.rpm"):
 continue
@@ -191,7 +191,7 @@ python write_specfile () {
 
 def walk_files(walkpath, target, conffiles, dirfiles):
 # We can race against the ipk/deb backends which create CONTROL or 
DEBIAN directories
-# when packaging. We just ignore these files which are created in 
+# when packaging. We just ignore these files which are created in
 # packages-split/ and not package/
 # We have the odd situation where the CONTROL/DEBIAN directory can be 
removed in the middle of
 # of the walk, the isdir() test would then fail and the walk code 
would assume its a file
@@ -445,9 +445,9 @@ python write_specfile () {
 rprovides = bb.utils.explode_dep_versions2(splitrprovides)
 rreplaces = bb.utils.explode_dep_versions2(splitrreplaces)
 for dep in rreplaces:
-if not dep in robsoletes:
+if dep not in robsoletes:
 robsoletes[dep] = rreplaces[dep]
-if not dep in rprovides:
+if dep not in rprovides:
 rprovides[dep] = rreplaces[dep]
 splitrobsoletes = bb.utils.join_deps(robsoletes, commasep=False)
 splitrprovides = bb.utils.join_deps(rprovides, commasep=False)
@@ -517,8 +517,8 @@ python write_specfile () {
 spec_files_bottom.append('')
 
 del localdata
-
-add_prep(d,spec_files_bottom)
+
+add_prep(d, spec_files_bottom)
 spec_preamble_top.append('Summary: %s' % srcsummary)
 spec_preamble_top.append('Name: %s' % srcname)
 spec_preamble_top.append('Version: %s' % srcversion)
@@ -539,9 +539,9 @@ python write_specfile () {
 rprovides = bb.utils.explode_dep_versions2(srcrprovides)
 rreplaces = 

[OE-core][mickledore][PATCH] shadow: Fix CVE-2023-4641

[Xiangyu Chen]

From: Xiangyu Chen 

shadow-utils: possible password leak during passwd(1) change

Signed-off-by: Xiangyu Chen 
---
 .../shadow/files/CVE-2023-4641.patch  | 147 ++
 meta/recipes-extended/shadow/shadow.inc   |   1 +
 2 files changed, 148 insertions(+)
 create mode 100644 meta/recipes-extended/shadow/files/CVE-2023-4641.patch

diff --git a/meta/recipes-extended/shadow/files/CVE-2023-4641.patch 
b/meta/recipes-extended/shadow/files/CVE-2023-4641.patch
new file mode 100644
index 00..1fabfe928e
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2023-4641.patch
@@ -0,0 +1,147 @@
+From 25dbe2ce166a13322b7536ff2f738786ea2e61e7 Mon Sep 17 00:00:00 2001
+From: Alejandro Colomar 
+Date: Sat, 10 Jun 2023 16:20:05 +0200
+Subject: [PATCH] gpasswd(1): Fix password leak
+
+How to trigger this password leak?
+~~
+
+When gpasswd(1) asks for the new password, it asks twice (as is usual
+for confirming the new password).  Each of those 2 password prompts
+uses agetpass() to get the password.  If the second agetpass() fails,
+the first password, which has been copied into the 'static' buffer
+'pass' via STRFCPY(), wasn't being zeroed.
+
+agetpass() is defined in <./libmisc/agetpass.c> (around line 91), and
+can fail for any of the following reasons:
+
+-  malloc(3) or readpassphrase(3) failure.
+
+   These are going to be difficult to trigger.  Maybe getting the system
+   to the limits of memory utilization at that exact point, so that the
+   next malloc(3) gets ENOMEM, and possibly even the OOM is triggered.
+   About readpassphrase(3), ENFILE and EINTR seem the only plausible
+   ones, and EINTR probably requires privilege or being the same user;
+   but I wouldn't discard ENFILE so easily, if a process starts opening
+   files.
+
+-  The password is longer than PASS_MAX.
+
+   The is plausible with physical access.  However, at that point, a
+   keylogger will be a much simpler attack.
+
+And, the attacker must be able to know when the second password is being
+introduced, which is not going to be easy.
+
+How to read the password after the leak?
+
+
+Provoking the leak yourself at the right point by entering a very long
+password is easy, and inspecting the process stack at that point should
+be doable.  Try to find some consistent patterns.
+
+Then, search for those patterns in free memory, right after the victim
+leaks their password.
+
+Once you get the leak, a program should read all the free memory
+searching for patterns that gpasswd(1) leaves nearby the leaked
+password.
+
+On 6/10/23 03:14, Seth Arnold wrote:
+> An attacker process wouldn't be able to use malloc(3) for this task.
+> There's a handful of tools available for userspace to allocate memory:
+>
+> -  brk / sbrk
+> -  mmap MAP_ANONYMOUS
+> -  mmap /dev/zero
+> -  mmap some other file
+> -  shm_open
+> -  shmget
+>
+> Most of these return only pages of zeros to a process.  Using mmap of an
+> existing file, you can get some of the contents of the file demand-loaded
+> into the memory space on the first use.
+>
+> The MAP_UNINITIALIZED flag only works if the kernel was compiled with
+> CONFIG_MMAP_ALLOW_UNINITIALIZED.  This is rare.
+>
+> malloc(3) doesn't zero memory, to our collective frustration, but all the
+> garbage in the allocations is from previous allocations in the current
+> process.  It isn't leftover from other processes.
+>
+> The avenues available for reading the memory:
+> -  /dev/mem and /dev/kmem (requires root, not available with Secure Boot)
+> -  /proc/pid/mem (requires ptrace privileges, mediated by YAMA)
+> -  ptrace (requires ptrace privileges, mediated by YAMA)
+> -  causing memory to be swapped to disk, and then inspecting the swap
+>
+> These all require a certain amount of privileges.
+
+How to fix it?
+~~
+
+memzero(), which internally calls explicit_bzero(3), or whatever
+alternative the system provides with a slightly different name, will
+make sure that the buffer is zeroed in memory, and optimizations are not
+allowed to impede this zeroing.
+
+This is not really 100% effective, since compilers may place copies of
+the string somewhere hidden in the stack.  Those copies won't get zeroed
+by explicit_bzero(3).  However, that's arguably a compiler bug, since
+compilers should make everything possible to avoid optimizing strings
+that are later passed to explicit_bzero(3).  But we all know that
+sometimes it's impossible to have perfect knowledge in the compiler, so
+this is plausible.  Nevertheless, there's nothing we can do against such
+issues, except minimizing the time such passwords are stored in plain
+text.
+
+Security concerns
+~
+
+We believe this isn't easy to exploit.  Nevertheless, and since the fix
+is trivial, this fix should probably be applied soon, and backported to
+all supported distributions, to prevent someone else having more
+imagination than us to find a 

Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Rasmus Villemoes via lists.openembedded.org]

On 20/10/2023 12.13, Richard Purdie wrote:
> On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote:
>> On 20/10/2023 11.38, Richard Purdie wrote:
>>> On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
 On 19/10/2023 14.48, Richard Purdie wrote:
>>
> The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
> anything in the perf build system where we should be passing in cflags
> we really want used?

 Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
 do_compile and do_install start with

 # Linux kernel build system is expected to do the right thing
 unset CFLAGS

 And perf's build system does indeed add lots of flags of its own, at
 least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
 set.

 So I do think that TARGET_CC_ARCH is the best place for flags that we
 really want used. At least as an initial step, because this is known to
 work when using the security_flags.inc file. Maybe there's some cleaner
 way where we don't unset CFLAGS, but that could be a giant can of worms.

 And yes, a comment should be added. Is something like

 # Perf's build system adds its own optimization flags for most TUs,
 # overriding the flags included here. But for some, perf does not add
 # any -O option, so ensure the distro's chosen optimization gets used
 # for those. Since ${SELECTED_OPTIMIZATION} always includes
 # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
 # ensures perf is built with appropriate -f*-prefix-map options,
 # avoiding the 'buildpaths' QA warning.

 too verbose?
>>>
>>> If it were me I'd probably write:
>>>
>>> # The perf makefile has "unset CFLAGS" as "Linux kernel build system is
>>> # expected to do the right thing". 
>>
>> It's not the perf makefile, it's right there in our recipe itself. I
>> don't think upstream perf is to blame.
> 
> Sorry, I misunderstood. I thought this was the perf environment that
> was doing this so in that case your comment does make much more sense
> than mine.

OK. Bruce, should I resend?

> Out of interest did you see what happens if you allow our CFLAGS in and
> remove that unset? 

I don't think I've tried that, but I've tried a few other things that I
thought would be cleaner but which then exploded, so in the end I
decided that just lifting exactly what the poky distro does should be
safest and have the highest likelyhood of being accepted.

> I also wondered if EXTRA_CFLAGS in EXTRA_OEMAKE
> might be an option?

Based on quick reading of perf build documentation, yes, EXTRA_CFLAGS
seems like a reasonable approach. What I'm a little worried about is the
TUs where perf apparently does not by itself add all its cflags (-O6 and
whatnot), so I'm not sure if they would be built with what is passed via
EXTRA_CFLAGS.

I will experiment sometime next week if I remember and nothing else
preempts that plan.

> I'm a bit worried that the current situation all feels a little
> fragile.

Agree. But the QA checks do help quite a lot here.

Rasmus


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189518): 
https://lists.openembedded.org/g/openembedded-core/message/189518
Mute This Topic: https://lists.openembedded.org/mt/102058904/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 3/4] scripts:recipetool:create_buildsys_python: refactor code for futur PEP517 addition

[Julien Stephan]

Le ven. 20 oct. 2023 à 08:01, Alexandre Belloni
 a écrit :
>
> Hello,
>
> On 19/10/2023 09:36:52+0200, Julien Stephan wrote:
> > In order to prepare the support for pyproject.toml (PEP517 [1]) enabled
> > projects, refactor the code and move setup.py specific code into a
> > specific class in order to allow sharing the PythonRecipeHandler class
> >
> > No functionnal changes expected
> >
>
> I tested with only the first 3 patches and unfortunately, thre were
> functional changes:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5886/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5935/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5952/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5936/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2296/steps/14/logs/stdio
>
> 2023-10-19 07:23:07,712 - oe-selftest - INFO - 1: 20/39 149/543 (20.20s) (0 
> failed) (recipetool.RecipetoolCreateTests.test_recipetool_create_github)
> 2023-10-19 07:23:07,712 - oe-selftest - INFO - 
> testtools.testresult.real._StringException: Traceback (most recent call last):
>   File 
> "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/recipetool.py",
>  line 451, in test_recipetool_create_github
> self.assertTrue(os.path.isfile(recipefile))
>   File "/usr/lib/python3.11/unittest/case.py", line 715, in assertTrue
> raise self.failureException(msg)
> AssertionError: False is not true

Hi Alexandre,

I am sorry, I did run a full self test for devtool but I forgot to run
it for recipetool..
I found the issue. This is not this commit, but the one where I now
prepend "python3-" for all created recipes. I will update the self
tests accordingly :)

Cheers
Julien

>
> > [1]: https://peps.python.org/pep-0517/#source-tree
> >
> > Signed-off-by: Julien Stephan 
> > ---
> >  .../lib/recipetool/create_buildsys_python.py  | 748 +-
> >  1 file changed, 385 insertions(+), 363 deletions(-)
> >
> > diff --git a/scripts/lib/recipetool/create_buildsys_python.py 
> > b/scripts/lib/recipetool/create_buildsys_python.py
> > index 502e1dfbc3d..69f6f5ca511 100644
> > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > @@ -37,63 +37,8 @@ class PythonRecipeHandler(RecipeHandler):
> >  assume_provided = ['builtins', 'os.path']
> >  # Assumes that the host python3 builtin_module_names is sane for 
> > target too
> >  assume_provided = assume_provided + list(sys.builtin_module_names)
> > +excluded_fields = []
> >
> > -bbvar_map = {
> > -'Name': 'PN',
> > -'Version': 'PV',
> > -'Home-page': 'HOMEPAGE',
> > -'Summary': 'SUMMARY',
> > -'Description': 'DESCRIPTION',
> > -'License': 'LICENSE',
> > -'Requires': 'RDEPENDS:${PN}',
> > -'Provides': 'RPROVIDES:${PN}',
> > -'Obsoletes': 'RREPLACES:${PN}',
> > -}
> > -# PN/PV are already set by recipetool core & desc can be extremely long
> > -excluded_fields = [
> > -'Description',
> > -]
> > -setup_parse_map = {
> > -'Url': 'Home-page',
> > -'Classifiers': 'Classifier',
> > -'Description': 'Summary',
> > -}
> > -setuparg_map = {
> > -'Home-page': 'url',
> > -'Classifier': 'classifiers',
> > -'Summary': 'description',
> > -'Description': 'long-description',
> > -}
> > -# Values which are lists, used by the setup.py argument based metadata
> > -# extraction method, to determine how to process the setup.py output.
> > -setuparg_list_fields = [
> > -'Classifier',
> > -'Requires',
> > -'Provides',
> > -'Obsoletes',
> > -'Platform',
> > -'Supported-Platform',
> > -]
> > -setuparg_multi_line_values = ['Description']
> > -replacements = [
> > -('License', r' +$', ''),
> > -('License', r'^ +', ''),
> > -('License', r' ', '-'),
> > -('License', r'^GNU-', ''),
> > -('License', r'-[Ll]icen[cs]e(,?-[Vv]ersion)?', ''),
> > -('License', r'^UNKNOWN$', ''),
> > -
> > -# Remove currently unhandled version numbers from these variables
> > -('Requires', r' *\([^)]*\)', ''),
> > -('Provides', r' *\([^)]*\)', ''),
> > -('Obsoletes', r' *\([^)]*\)', ''),
> > -('Install-requires', r'^([^><= ]+).*', r'\1'),
> > -('Extras-require', r'^([^><= ]+).*', r'\1'),
> > -('Tests-require', r'^([^><= ]+).*', r'\1'),
> > -
> > -# Remove unhandled dependency on particular features (e.g. 
> > foo[PDF])
> > -('Install-requires', r'\[[^\]]+\]$', ''),
> > -]
> >
> >  classifier_license_map = {
> >  'License :: OSI Approved :: Academic Free License (AFL)': 'AFL',
> > @@ -166,122 

[OE-core][PATCH] shadow: update 4.13 -> 4.14.1

[Xiangyu Chen]

From: Xiangyu Chen 

Based on Alex's 4.13->4.14.0 patch (oe-core maillist #187776)

Refresh patch: commonio.c-fix-unexpected-open-failure-in-chroot-env.patch

Drop patches:
0001-Disable-use-of-syslog-for-sysroot.patch
0001-Fix-can-not-print-full-login.patch
0001-Overhaul-valid_field.patch
CVE-2023-29383.patch

License-Update: formatting, spdx conversion

Depends update: libbsd

A similar fix is added to musl in order to define non-standard 
__BEGIN_DECLS/__END_DECLS.

Signed-off-by: Xiangyu Chen 
---
 ...01-Disable-use-of-syslog-for-sysroot.patch | 52 ---
 .../0001-Fix-can-not-print-full-login.patch   | 41 
 .../files/0001-Overhaul-valid_field.patch | 65 ---
 .../shadow/files/CVE-2023-29383.patch | 53 ---
 ...nexpected-open-failure-in-chroot-env.patch | 22 ---
 meta/recipes-extended/shadow/shadow.inc   | 18 ++---
 .../{shadow_4.13.bb => shadow_4.14.1.bb}  |  0
 7 files changed, 19 insertions(+), 232 deletions(-)
 delete mode 100644 
meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
 delete mode 100644 
meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
 delete mode 100644 
meta/recipes-extended/shadow/files/0001-Overhaul-valid_field.patch
 delete mode 100644 meta/recipes-extended/shadow/files/CVE-2023-29383.patch
 rename meta/recipes-extended/shadow/{shadow_4.13.bb => shadow_4.14.1.bb} (100%)

diff --git 
a/meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
 
b/meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
deleted file mode 100644
index fa1532c831..00
--- 
a/meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
+++ /dev/null
@@ -1,52 +0,0 @@
-From 85d0444229ee3d14fefcf10d093f49c862826f82 Mon Sep 17 00:00:00 2001
-From: Richard Purdie 
-Date: Thu, 14 Apr 2022 23:11:53 +
-Subject: [PATCH] Disable use of syslog for shadow-native tools
-
-Disable use of syslog to prevent sysroot user and group additions from
-writing entries to the host's syslog. This patch should only be used
-with the shadow-native recipe.
-
-Upstream-Status: Inappropriate [OE specific configuration]
-Signed-off-by: Richard Purdie 
-Signed-off-by: Peter Kjellerstedt 
-

- configure.ac  | 2 +-
- src/login_nopam.c | 3 ++-
- 2 files changed, 3 insertions(+), 2 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 924254a..603af81 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -191,7 +191,7 @@ AC_DEFINE_UNQUOTED(PASSWD_PROGRAM, 
"$shadow_cv_passwd_dir/passwd",
-   [Path to passwd program.])
- 
- dnl XXX - quick hack, should disappear before anyone notices :).
--AC_DEFINE(USE_SYSLOG, 1, [Define to use syslog().])
-+#AC_DEFINE(USE_SYSLOG, 1, [Define to use syslog().])
- if test "$ac_cv_func_ruserok" = "yes"; then
-   AC_DEFINE(RLOGIN, 1, [Define if login should support the -r flag for 
rlogind.])
-   AC_DEFINE(RUSEROK, 0, [Define to the ruserok() "success" return value 
(0 or 1).])
-diff --git a/src/login_nopam.c b/src/login_nopam.c
-index df6ba88..fc24e13 100644
 a/src/login_nopam.c
-+++ b/src/login_nopam.c
-@@ -29,7 +29,6 @@
- #ifndef USE_PAM
- #ident "$Id$"
- 
--#include "prototypes.h"
- /*
-  * This module implements a simple but effective form of login access
-  * control based on login names and on host (or domain) names, internet
-@@ -57,6 +56,8 @@
- #include 
- #include /* for inet_ntoa() */
- 
-+#include "prototypes.h"
-+
- #if !defined(MAXHOSTNAMELEN) || (MAXHOSTNAMELEN < 64)
- #undef MAXHOSTNAMELEN
- #define MAXHOSTNAMELEN 256
diff --git 
a/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch 
b/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
deleted file mode 100644
index 89f9c05c8d..00
--- a/meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-commit 670cae834827a8f794e6f7464fa57790d911b63c
-Author: SoumyaWind <121475834+soumyaw...@users.noreply.github.com>
-Date:   Tue Dec 27 17:40:17 2022 +0530
-
-shadow: Fix can not print full login timeout message
-
-Login timed out message prints only first few bytes when write is 
immediately followed by exit.
-Calling exit from new handler provides enough time to display full message.
-
-Upstream-Status: Backport 
[https://github.com/shadow-maint/shadow/commit/670cae834827a8f794e6f7464fa57790d911b63c]
-
-diff --git a/src/login.c b/src/login.c
-index 116e2cb3..c55f4de0 100644
 a/src/login.c
-+++ b/src/login.c
-@@ -120,6 +120,7 @@ static void get_pam_user (char **ptr_pam_user);
- 
- static void init_env (void);
- static void alarm_handler (int);
-+static void exit_handler (int);
- 
- /*
-  * usage - print login command usage and exit
-@@ -391,11 +392,16 @@ static void init_env (void)
- #endif/* !USE_PAM */
- }
- 
-+static void exit_handler 

Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Richard Purdie]

On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote:
> On 20/10/2023 11.38, Richard Purdie wrote:
> > On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
> > > On 19/10/2023 14.48, Richard Purdie wrote:
> 
> > > > The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
> > > > anything in the perf build system where we should be passing in cflags
> > > > we really want used?
> > > 
> > > Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
> > > 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
> > > do_compile and do_install start with
> > > 
> > > # Linux kernel build system is expected to do the right thing
> > > unset CFLAGS
> > > 
> > > And perf's build system does indeed add lots of flags of its own, at
> > > least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
> > > set.
> > > 
> > > So I do think that TARGET_CC_ARCH is the best place for flags that we
> > > really want used. At least as an initial step, because this is known to
> > > work when using the security_flags.inc file. Maybe there's some cleaner
> > > way where we don't unset CFLAGS, but that could be a giant can of worms.
> > > 
> > > And yes, a comment should be added. Is something like
> > > 
> > > # Perf's build system adds its own optimization flags for most TUs,
> > > # overriding the flags included here. But for some, perf does not add
> > > # any -O option, so ensure the distro's chosen optimization gets used
> > > # for those. Since ${SELECTED_OPTIMIZATION} always includes
> > > # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
> > > # ensures perf is built with appropriate -f*-prefix-map options,
> > > # avoiding the 'buildpaths' QA warning.
> > > 
> > > too verbose?
> > 
> > If it were me I'd probably write:
> > 
> > # The perf makefile has "unset CFLAGS" as "Linux kernel build system is
> > # expected to do the right thing". 
> 
> It's not the perf makefile, it's right there in our recipe itself. I
> don't think upstream perf is to blame.

Sorry, I misunderstood. I thought this was the perf environment that
was doing this so in that case your comment does make much more sense
than mine.

Out of interest did you see what happens if you allow our CFLAGS in and
remove that unset? I also wondered if EXTRA_CFLAGS in EXTRA_OEMAKE
might be an option?

I'm a bit worried that the current situation all feels a little
fragile.

> > and security flags amongst other things so force our 
> > # cflags in.
> 
> This has nothing to do with the security flags. That file still contains
> 
> TARGET_CC_ARCH:append:class-target = " ${SECURITY_CFLAGS}"
> 
> and TARGET_CC_ARCH is included in the CC value we pass to perf's make,
> with or without this patch. So if the distro includes
> security_flags.inc, perf gets built with those flags as expected.
> 
> But when that file is _not_ included, we do miss the prefix-map flags,
> which should be passed regardless of any security distro settings. I
> think the line I'm moving out of security_flags.inc have never really
> had any business being there in the first place, regardless of whether
> adding ${SELECTED_OPTIMIZATION} to TARGET_CC_ARCH is the most
> appropriate method to get those prefix-map options passed.

I agree. It was added as a "lets get security flags roughly working and
find out where the issues are" and has unfortunately stuck around and
not been properly fixed.

>  But since
> that's how the poky distro has achieved that until now, it seems to be
> the least invasive and least risky fix for distros that don't use
> security_flags.inc.

Agreed, however I am interested to see if we can remove some of the
complexity instead as that would be better overall I think if we could
do it.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189514): 
https://lists.openembedded.org/g/openembedded-core/message/189514
Mute This Topic: https://lists.openembedded.org/mt/102058904/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] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Rasmus Villemoes via lists.openembedded.org]

On 20/10/2023 11.38, Richard Purdie wrote:
> On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
>> On 19/10/2023 14.48, Richard Purdie wrote:

>>> The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
>>> anything in the perf build system where we should be passing in cflags
>>> we really want used?
>>
>> Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
>> 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
>> do_compile and do_install start with
>>
>> # Linux kernel build system is expected to do the right thing
>> unset CFLAGS
>>
>> And perf's build system does indeed add lots of flags of its own, at
>> least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
>> set.
>>
>> So I do think that TARGET_CC_ARCH is the best place for flags that we
>> really want used. At least as an initial step, because this is known to
>> work when using the security_flags.inc file. Maybe there's some cleaner
>> way where we don't unset CFLAGS, but that could be a giant can of worms.
>>
>> And yes, a comment should be added. Is something like
>>
>> # Perf's build system adds its own optimization flags for most TUs,
>> # overriding the flags included here. But for some, perf does not add
>> # any -O option, so ensure the distro's chosen optimization gets used
>> # for those. Since ${SELECTED_OPTIMIZATION} always includes
>> # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
>> # ensures perf is built with appropriate -f*-prefix-map options,
>> # avoiding the 'buildpaths' QA warning.
>>
>> too verbose?
> 
> If it were me I'd probably write:
> 
> # The perf makefile has "unset CFLAGS" as "Linux kernel build system is
> # expected to do the right thing". 

It's not the perf makefile, it's right there in our recipe itself. I
don't think upstream perf is to blame.

> It doesn't and we need our prefix 
> # map options 

Yes.

> and security flags amongst other things so force our 
> # cflags in.

This has nothing to do with the security flags. That file still contains

TARGET_CC_ARCH:append:class-target = " ${SECURITY_CFLAGS}"

and TARGET_CC_ARCH is included in the CC value we pass to perf's make,
with or without this patch. So if the distro includes
security_flags.inc, perf gets built with those flags as expected.

But when that file is _not_ included, we do miss the prefix-map flags,
which should be passed regardless of any security distro settings. I
think the line I'm moving out of security_flags.inc have never really
had any business being there in the first place, regardless of whether
adding ${SELECTED_OPTIMIZATION} to TARGET_CC_ARCH is the most
appropriate method to get those prefix-map options passed. But since
that's how the poky distro has achieved that until now, it seems to be
the least invasive and least risky fix for distros that don't use
security_flags.inc.

Rasmus


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189513): 
https://lists.openembedded.org/g/openembedded-core/message/189513
Mute This Topic: https://lists.openembedded.org/mt/102058904/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] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Richard Purdie]

On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
> On 19/10/2023 14.48, Richard Purdie wrote:
> > On Thu, 2023-10-19 at 14:32 +0200, Rasmus Villemoes via
> > lists.openembedded.org wrote:
> > > From: Rasmus Villemoes 
> > > 
> > > Building perf without security_flags.inc being included in one's
> > > distro results in the buildpaths warning
> > > 
> > > WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
> > > package perf contains reference to TMPDIR
> > > 
> > > because the ${DEBUG_PREFIX_MAP} does not get used. Most recipes get
> > > that from CFLAGS, but the perf recipe explicitly unsets that.
> > > 
> > > Now ${SELECTED_OPTIMIZATION} of course contains more than just
> > > ${DEBUG_FLAGS}/${DEBUG_PREFIX_MAP}. For most TUs, perf's build system
> > > adds its own optimization flags (-O6 for odd reasons), so for those
> > > including the -O2 or -Og doesn't change anything. But looking at the
> > > .o.cmd files show that there are some TUs which currently get built
> > > without any -O flag. So for those adding the distro's
> > > SELECTED_OPTIMIZATION seem to be the right thing to do.
> > > 
> > > Signed-off-by: Rasmus Villemoes 
> > > ---
> > >  meta/conf/distro/include/security_flags.inc | 1 -
> > >  meta/recipes-kernel/perf/perf.bb| 1 +
> > >  2 files changed, 1 insertion(+), 1 deletion(-)
> > 
> > The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
> > anything in the perf build system where we should be passing in cflags
> > we really want used?
> 
> Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
> 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
> do_compile and do_install start with
> 
> # Linux kernel build system is expected to do the right thing
> unset CFLAGS
> 
> And perf's build system does indeed add lots of flags of its own, at
> least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
> set.
> 
> So I do think that TARGET_CC_ARCH is the best place for flags that we
> really want used. At least as an initial step, because this is known to
> work when using the security_flags.inc file. Maybe there's some cleaner
> way where we don't unset CFLAGS, but that could be a giant can of worms.
> 
> And yes, a comment should be added. Is something like
> 
> # Perf's build system adds its own optimization flags for most TUs,
> # overriding the flags included here. But for some, perf does not add
> # any -O option, so ensure the distro's chosen optimization gets used
> # for those. Since ${SELECTED_OPTIMIZATION} always includes
> # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
> # ensures perf is built with appropriate -f*-prefix-map options,
> # avoiding the 'buildpaths' QA warning.
> 
> too verbose?

If it were me I'd probably write:

# The perf makefile has "unset CFLAGS" as "Linux kernel build system is
# expected to do the right thing". It doesn't and we need our prefix 
# map options and security flags amongst other things so force our 
# cflags in.

Cheers,

Richard





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

[OE-core] CVE work synchronization proposal

[Marta Rybczynska]

Hello everyone,
We have a constant flow of work on pending CVEs. During my discussion
with multiple people, there is a common need for synchronization of
this work to avoid duplication or forgotten fixes.

We have a decision on the tooling to make: do we want to create a
Bugzilla entry for each new open CVE? An alternative is to use a wiki
page (this has been prototyped by Ross) with heavy scripting to
automate the tedious part.

Today I propose you to use a special wiki page and the following procedure:

On the wiki page, always add all additional information after a ; sign
to allow scripting. The first part of each line (until ";" ) will be
auto-generated. The second part contains information about the issue,
like who is investigating or what the situation is.

There is a separate list for each branch, as we realize that people
concentrate on various branches.

Workflow:

* Mark name of a person preparing a patch for each branch
* If you have additional information (like a link to a patch), add it
to the record
* If a patch is posted to the mailing list, post a link to it (this
will be automated)
* When a patch reaches the "next" branch, mark it too (this will be
automated too)
* When the patch reaches the final branch, the line of the CVE is
automatically removed (this is already automated)
* The list is (re)generated every day


Please have a look at the procedure proposal and how the tracking
might look like:

https://wiki.yoctoproject.org/wiki/Synchronization_CVEs

Kind regards,
Marta

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

[OE-core][master][mickledore][PATCH] grub2: fix CVE-2023-4693

[Xiangyu Chen]

From: Xiangyu Chen 

There an out-of-bounds read at fs/ntfs.c, a physically present attacker
may leverage that by presenting a specially crafted NTFS file system
image to read arbitrary memory locations. A successful attack may allow
sensitive data cached in memory or EFI variables values to be leaked
presenting a high Confidentiality risk.

Signed-off-by: Xiangyu Chen 
---
 .../grub/files/CVE-2023-4693.patch| 63 +++
 meta/recipes-bsp/grub/grub2.inc   |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-bsp/grub/files/CVE-2023-4693.patch

diff --git a/meta/recipes-bsp/grub/files/CVE-2023-4693.patch 
b/meta/recipes-bsp/grub/files/CVE-2023-4693.patch
new file mode 100644
index 00..544226a9aa
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/CVE-2023-4693.patch
@@ -0,0 +1,63 @@
+From 0ed2458cc4eff6d9a9199527e2a0b6d445802f94 Mon Sep 17 00:00:00 2001
+From: Maxim Suhanov 
+Date: Mon, 28 Aug 2023 16:32:33 +0300
+Subject: fs/ntfs: Fix an OOB read when reading data from the resident $DATA
+ attribute
+
+When reading a file containing resident data, i.e., the file data is stored in
+the $DATA attribute within the NTFS file record, not in external clusters,
+there are no checks that this resident data actually fits the corresponding
+file record segment.
+
+When parsing a specially-crafted file system image, the current NTFS code will
+read the file data from an arbitrary, attacker-chosen memory offset and of
+arbitrary, attacker-chosen length.
+
+This allows an attacker to display arbitrary chunks of memory, which could
+contain sensitive information like password hashes or even plain-text,
+obfuscated passwords from BS EFI variables.
+
+This fix implements a check to ensure that resident data is read from the
+corresponding file record segment only.
+
+Fixes: CVE-2023-4693
+
+Upstream-Status: Backport from 
+[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0ed2458cc4eff6d9a9199527e2a0b6d445802f94]
+CVE: CVE-2023-4693
+
+Reported-by: Maxim Suhanov 
+Signed-off-by: Maxim Suhanov 
+Reviewed-by: Daniel Kiper 
+Signed-off-by: Xiangyu Chen 
+---
+ grub-core/fs/ntfs.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
+index c3c4db1..a68e173 100644
+--- a/grub-core/fs/ntfs.c
 b/grub-core/fs/ntfs.c
+@@ -401,7 +401,18 @@ read_data (struct grub_ntfs_attr *at, grub_uint8_t *pa, 
grub_uint8_t *dest,
+ {
+   if (ofs + len > u32at (pa, 0x10))
+   return grub_error (GRUB_ERR_BAD_FS, "read out of range");
+-  grub_memcpy (dest, pa + u32at (pa, 0x14) + ofs, len);
++
++  if (u32at (pa, 0x10) > (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR))
++  return grub_error (GRUB_ERR_BAD_FS, "resident attribute too large");
++
++  if (pa >= at->mft->buf + (at->mft->data->mft_size << GRUB_NTFS_BLK_SHR))
++  return grub_error (GRUB_ERR_BAD_FS, "resident attribute out of range");
++
++  if (u16at (pa, 0x14) + u32at (pa, 0x10) >
++(grub_addr_t) at->mft->buf + (at->mft->data->mft_size << 
GRUB_NTFS_BLK_SHR) - (grub_addr_t) pa)
++  return grub_error (GRUB_ERR_BAD_FS, "resident attribute out of range");
++
++  grub_memcpy (dest, pa + u16at (pa, 0x14) + ofs, len);
+   return 0;
+ }
+ 
+-- 
+cgit v1.1
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 5ce8699363..f594e7d3a4 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -43,6 +43,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://0001-risc-v-Handle-R_RISCV_CALL_PLT-reloc.patch \
file://0001-fs-ext2-Ignore-checksum-seed-incompat-feature.patch \
file://CVE-2023-4692.patch \
+   file://CVE-2023-4693.patch \
 "
 
 SRC_URI[sha256sum] = 
"23b64b4c741569f9426ed2e3d0e6780796fca081bee4c99f62aa3f53ae803f5f"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189509): 
https://lists.openembedded.org/g/openembedded-core/message/189509
Mute This Topic: https://lists.openembedded.org/mt/102077328/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] perf: lift TARGET_CC_ARCH modification out of security_flags.inc

[Rasmus Villemoes via lists.openembedded.org]

On 19/10/2023 14.48, Richard Purdie wrote:
> On Thu, 2023-10-19 at 14:32 +0200, Rasmus Villemoes via
> lists.openembedded.org wrote:
>> From: Rasmus Villemoes 
>>
>> Building perf without security_flags.inc being included in one's
>> distro results in the buildpaths warning
>>
>> WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
>> package perf contains reference to TMPDIR
>>
>> because the ${DEBUG_PREFIX_MAP} does not get used. Most recipes get
>> that from CFLAGS, but the perf recipe explicitly unsets that.
>>
>> Now ${SELECTED_OPTIMIZATION} of course contains more than just
>> ${DEBUG_FLAGS}/${DEBUG_PREFIX_MAP}. For most TUs, perf's build system
>> adds its own optimization flags (-O6 for odd reasons), so for those
>> including the -O2 or -Og doesn't change anything. But looking at the
>> .o.cmd files show that there are some TUs which currently get built
>> without any -O flag. So for those adding the distro's
>> SELECTED_OPTIMIZATION seem to be the right thing to do.
>>
>> Signed-off-by: Rasmus Villemoes 
>> ---
>>  meta/conf/distro/include/security_flags.inc | 1 -
>>  meta/recipes-kernel/perf/perf.bb| 1 +
>>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
> anything in the perf build system where we should be passing in cflags
> we really want used?

Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
do_compile and do_install start with

# Linux kernel build system is expected to do the right thing
unset CFLAGS

And perf's build system does indeed add lots of flags of its own, at
least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
set.

So I do think that TARGET_CC_ARCH is the best place for flags that we
really want used. At least as an initial step, because this is known to
work when using the security_flags.inc file. Maybe there's some cleaner
way where we don't unset CFLAGS, but that could be a giant can of worms.

And yes, a comment should be added. Is something like

# Perf's build system adds its own optimization flags for most TUs,
# overriding the flags included here. But for some, perf does not add
# any -O option, so ensure the distro's chosen optimization gets used
# for those. Since ${SELECTED_OPTIMIZATION} always includes
# ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
# ensures perf is built with appropriate -f*-prefix-map options,
# avoiding the 'buildpaths' QA warning.

too verbose?

Rasmus


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189508): 
https://lists.openembedded.org/g/openembedded-core/message/189508
Mute This Topic: https://lists.openembedded.org/mt/102058904/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] libx11: Security Fix for CVE-2023-43785, CVE-2023-43786 and CVE-2023-43787

[Siddharth via lists.openembedded.org]

From: Siddharth Doshi 

CVE's Fixed:
CVE-2023-43785: libX11: out-of-bounds memory access in _XkbReadKeySyms()
CVE-2023-43786: libX11: stack exhaustion from infinite recursion in 
PutSubImage()
CVE-2023-43787: libX11: integer overflow in XCreateImage() leading to a heap 
overflow

Signed-off-by: Siddharth Doshi 
---
 .../xorg-lib/libx11/CVE-2023-43785.patch  | 62 ++
 .../xorg-lib/libx11/CVE-2023-43786-0001.patch | 41 
 .../xorg-lib/libx11/CVE-2023-43786-0002.patch | 45 +
 .../xorg-lib/libx11/CVE-2023-43786-0003.patch | 51 +++
 .../xorg-lib/libx11/CVE-2023-43787.patch  | 63 +++
 .../xorg-lib/libx11_1.7.3.1.bb|  5 ++
 6 files changed, 267 insertions(+)
 create mode 100644 meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43785.patch
 create mode 100644 
meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43786-0001.patch
 create mode 100644 
meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43786-0002.patch
 create mode 100644 
meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43786-0003.patch
 create mode 100644 meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43787.patch

diff --git a/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43785.patch 
b/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43785.patch
new file mode 100644
index 00..64f8776cc9
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43785.patch
@@ -0,0 +1,62 @@
+From 6858d468d9ca55fb4c5fd70b223dbc78a3358a7f Mon Sep 17 00:00:00 2001
+From: Alan Coopersmith 
+Date: Sun, 17 Sep 2023 14:19:40 -0700
+Subject: [PATCH] CVE-2023-43785: out-of-bounds memory access in
+ _XkbReadKeySyms()
+
+Make sure we allocate enough memory in the first place, and
+also handle error returns from _XkbReadBufferCopyKeySyms() when
+it detects out-of-bounds issues.
+
+Reported-by: Gregory James DUCK 
+Signed-off-by: Alan Coopersmith 
+
+Upstream-Status: Backport from 
[https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/6858d468d9ca55fb4c5fd70b223dbc78a3358a7f]
+CVE: CVE-2023-43785
+Signed-off-by: Siddharth Doshi 
+---
+ src/xkb/XKBGetMap.c | 14 +-
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/src/xkb/XKBGetMap.c b/src/xkb/XKBGetMap.c
+index 2891d21..31199e4 100644
+--- a/src/xkb/XKBGetMap.c
 b/src/xkb/XKBGetMap.c
+@@ -182,7 +182,8 @@ _XkbReadKeySyms(XkbReadBufferPtr buf, XkbDescPtr xkb, 
xkbGetMapReply *rep)
+ if (offset + newMap->nSyms >= map->size_syms) {
+ register int sz;
+ 
+-sz = map->size_syms + 128;
++sz = offset + newMap->nSyms;
++sz = ((sz + (unsigned) 128) / 128) * 128;
+ _XkbResizeArray(map->syms, map->size_syms, sz, KeySym);
+ if (map->syms == NULL) {
+ map->size_syms = 0;
+@@ -191,8 +192,9 @@ _XkbReadKeySyms(XkbReadBufferPtr buf, XkbDescPtr xkb, 
xkbGetMapReply *rep)
+ map->size_syms = sz;
+ }
+ if (newMap->nSyms > 0) {
+-_XkbReadBufferCopyKeySyms(buf, (KeySym *) >syms[offset],
+-  newMap->nSyms);
++if (_XkbReadBufferCopyKeySyms(buf, (KeySym *) 
>syms[offset],
++  newMap->nSyms) == 0)
++return BadLength;
+ offset += newMap->nSyms;
+ }
+ else {
+@@ -222,8 +224,10 @@ _XkbReadKeySyms(XkbReadBufferPtr buf, XkbDescPtr xkb, 
xkbGetMapReply *rep)
+ newSyms = XkbResizeKeySyms(xkb, i + rep->firstKeySym, tmp);
+ if (newSyms == NULL)
+ return BadAlloc;
+-if (newMap->nSyms > 0)
+-_XkbReadBufferCopyKeySyms(buf, newSyms, newMap->nSyms);
++if (newMap->nSyms > 0) {
++if (_XkbReadBufferCopyKeySyms(buf, newSyms, newMap->nSyms) == 
0)
++return BadLength;
++}
+ else
+ newSyms[0] = NoSymbol;
+ oldMap->kt_index[0] = newMap->ktIndex[0];
+-- 
+2.35.7
+
diff --git a/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43786-0001.patch 
b/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43786-0001.patch
new file mode 100644
index 00..db5b7067aa
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43786-0001.patch
@@ -0,0 +1,41 @@
+From 204c3393c4c90a29ed6bef64e43849536e863a86 Mon Sep 17 00:00:00 2001
+From: Alan Coopersmith 
+Date: Thu, 7 Sep 2023 15:54:30 -0700
+Subject: [PATCH] CVE-2023-43786: stack exhaustion from infinite recursion in
+ PutSubImage()
+
+When splitting a single line of pixels into chunks to send to the
+X server, be sure to take into account the number of bits per pixel,
+so we don't just loop forever trying to send more pixels than fit in
+the given request size and not breaking them down into a small enough
+chunk to fix.
+
+Fixes: "almost complete rewrite" (Dec. 12, 1987) from X11R2
+Signed-off-by: Alan 

[OE-core][master][mickledore][PATCH] grub2: fix CVE-2023-4692

[Xiangyu Chen]

From: Xiangyu Chen 

Crafted file system images can cause heap-based buffer overflow and may
allow arbitrary code execution and secure boot bypass

Reference:
https://security-tracker.debian.org/tracker/CVE-2023-4692

Signed-off-by: Xiangyu Chen 
---
 .../grub/files/CVE-2023-4692.patch| 98 +++
 meta/recipes-bsp/grub/grub2.inc   |  1 +
 2 files changed, 99 insertions(+)
 create mode 100644 meta/recipes-bsp/grub/files/CVE-2023-4692.patch

diff --git a/meta/recipes-bsp/grub/files/CVE-2023-4692.patch 
b/meta/recipes-bsp/grub/files/CVE-2023-4692.patch
new file mode 100644
index 00..305fcc93d8
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/CVE-2023-4692.patch
@@ -0,0 +1,98 @@
+From 43651027d24e62a7a463254165e1e46e42aecdea Mon Sep 17 00:00:00 2001
+From: Maxim Suhanov 
+Date: Mon, 28 Aug 2023 16:31:57 +0300
+Subject: [PATCH] fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST 
attribute
+ for the $MFT file
+
+When parsing an extremely fragmented $MFT file, i.e., the file described
+using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer
+containing bytes read from the underlying drive to store sector numbers,
+which are consumed later to read data from these sectors into another buffer.
+
+These sectors numbers, two 32-bit integers, are always stored at predefined
+offsets, 0x10 and 0x14, relative to first byte of the selected entry within
+the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem.
+
+However, when parsing a specially-crafted file system image, this may cause
+the NTFS code to write these integers beyond the buffer boundary, likely
+causing the GRUB memory allocator to misbehave or fail. These integers contain
+values which are controlled by on-disk structures of the NTFS file system.
+
+Such modification and resulting misbehavior may touch a memory range not
+assigned to the GRUB and owned by firmware or another EFI application/driver.
+
+This fix introduces checks to ensure that these sector numbers are never
+written beyond the boundary.
+
+Fixes: CVE-2023-4692
+
+Upstream-Status: Backport from 
+[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=43651027d24e62a7a463254165e1e46e42aecdea]
+CVE: CVE-2023-4692
+
+Reported-by: Maxim Suhanov 
+Signed-off-by: Maxim Suhanov 
+Reviewed-by: Daniel Kiper 
+Signed-off-by: Xiangyu Chen 
+---
+ grub-core/fs/ntfs.c | 18 +-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/fs/ntfs.c b/grub-core/fs/ntfs.c
+index bbdbe24..c3c4db1 100644
+--- a/grub-core/fs/ntfs.c
 b/grub-core/fs/ntfs.c
+@@ -184,7 +184,7 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+ }
+   if (at->attr_end)
+ {
+-  grub_uint8_t *pa;
++  grub_uint8_t *pa, *pa_end;
+ 
+   at->emft_buf = grub_malloc (at->mft->data->mft_size << 
GRUB_NTFS_BLK_SHR);
+   if (at->emft_buf == NULL)
+@@ -209,11 +209,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+   }
+ at->attr_nxt = at->edat_buf;
+ at->attr_end = at->edat_buf + u32at (pa, 0x30);
++pa_end = at->edat_buf + n;
+   }
+   else
+   {
+ at->attr_nxt = at->attr_end + u16at (pa, 0x14);
+ at->attr_end = at->attr_end + u32at (pa, 4);
++pa_end = at->mft->buf + (at->mft->data->mft_size << 
GRUB_NTFS_BLK_SHR);
+   }
+   at->flags |= GRUB_NTFS_AF_ALST;
+   while (at->attr_nxt < at->attr_end)
+@@ -230,6 +232,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+ at->flags |= GRUB_NTFS_AF_GPOS;
+ at->attr_cur = at->attr_nxt;
+ pa = at->attr_cur;
++
++if ((pa >= pa_end) || (pa_end - pa < 0x18))
++  {
++grub_error (GRUB_ERR_BAD_FS, "can\'t parse attribute list");
++return NULL;
++  }
++
+ grub_set_unaligned32 ((char *) pa + 0x10,
+   grub_cpu_to_le32 (at->mft->data->mft_start));
+ grub_set_unaligned32 ((char *) pa + 0x14,
+@@ -240,6 +249,13 @@ find_attr (struct grub_ntfs_attr *at, grub_uint8_t attr)
+   {
+ if (*pa != attr)
+   break;
++
++  if ((pa >= pa_end) || (pa_end - pa < 0x18))
++{
++grub_error (GRUB_ERR_BAD_FS, "can\'t parse attribute list");
++return NULL;
++  }
++
+ if (read_attr
+ (at, pa + 0x10,
+  u32at (pa, 0x10) * (at->mft->data->mft_size << 
GRUB_NTFS_BLK_SHR),
+-- 
+cgit v1.1
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 41839698dc..5ce8699363 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -42,6 +42,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
file://CVE-2022-3775.patch \
file://0001-risc-v-Handle-R_RISCV_CALL_PLT-reloc.patch \
file://0001-fs-ext2-Ignore-checksum-seed-incompat-feature.patch \
+ 

Re: [OE-core] Detecting unimplemented ptests with heuristics

[Yoann Congal]

On 10/19/23 17:21, Michael Opdenacker wrote:
> Hi Yoann

Hi,
 
> On 19.10.23 at 10:00, Yoann Congal wrote:
>> Hi everyone,
>>
>> We recently implemented a way to detect recipes for upstream code that 
>> contain unit tests but does not implement ptests.
>> Those recipes make good candidates for increasing the ptests coverage.
>>
>> This is implemented as a QA check. The check is disabled by default since it 
>> generates a lot of warning at build.
>> In order to activate it (in local.conf for exemple) :
>> WARN_QA += "unimplemented-ptest"
>>
>> The warnings looks like:
>> WARNING: time-1.9-r0 do_patch: QA Issue: time: autotools-based tests 
>> detected [unimplemented-ptest]
>>   I've generated the list for the unimplemented ptests for oe-core and for 
>> meta-openembedded:
>>    329 unimplemented-ptests_oe-core.log: 
>> https://gist.github.com/ycongal-smile/dd51b0e450a8f0083e9d5cc10eeeb060#file-unimplemented-ptests_oe-core-log
>>   1080 unimplemented-ptests_meta-openembedded.log: 
>> https://gist.github.com/ycongal-smile/dd51b0e450a8f0083e9d5cc10eeeb060#file-unimplemented-ptests_meta-openembedded-log
> 
> Thanks, indeed, I "own" recipes that were flagged :)
> Maybe, you could find a way to notify the maintainers of such recipes, as in 
> the AUH upgrade status reports 
> (https://lists.openembedded.org/g/openembedded-core/message/188589 for 
> example).

Good idea, Thanks!

I've created a bug to not forget : 
15249 – Notify the maintainers of unimplemented ptests
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15249
I've CC'd you :)

Regards,
-- 
Yoann Congal
Smile ECS - Tech Expert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189505): 
https://lists.openembedded.org/g/openembedded-core/message/189505
Mute This Topic: https://lists.openembedded.org/mt/102056219/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.bbclass: support embedded SW components with different version number

[Mikko Rapeli]

On Fri, Oct 20, 2023 at 08:56:43AM +0100, Jose Quaresma wrote:
> Mikko Rapeli  escreveu no dia quinta, 19/10/2023
> à(s) 13:45:
> 
> > Hi,
> >
> > Could something like this work?
> >
> > --- a/meta/lib/oe/cve_check.py
> > +++ b/meta/lib/oe/cve_check.py
> > @@ -140,15 +140,14 @@ def get_patched_cves(d):
> >  return patched_cves
> >
> >
> > -def get_cpe_ids(cve_product, version):
> > +def get_cpe_ids(cve_product, cve_version):
> >  """
> >  Get list of CPE identifiers for the given product and version
> >  """
> >
> > -version = version.split("+git")[0]
> > -
> >  cpe_ids = []
> >  for product in cve_product.split():
> > +version = (d.getVar("CVE_VERSION_%s" % product) or
> > cve_version).split("+git")[0]
> >
> 
> Looks like your patch fixes the remaining issue
> but don't know if it will be better to get the CVE_VERSION_ after
> splitting  the vendor from the product

This is now in v2. For the CVE_VERSION_%s, it uses what ever product was defined
in CVE_PRODUCT space separated list so it is used before vendor and product 
split.

Cheers,

-Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189504): 
https://lists.openembedded.org/g/openembedded-core/message/189504
Mute This Topic: https://lists.openembedded.org/mt/101991269/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] systemd: fix packaging tpm2 plugin for cryptsetup

[Jose Quaresma]

Hi Alexandre,

This patch is still on master-next but It is no longer necessary because
[2] was merged on master and contains the same fixes.

[2]
https://git.yoctoproject.org/poky/commit/?id=64f76114da1f2d79e24a6a79572f2682b6379452

Jose

Erik Schilling  escreveu no dia quarta,
18/10/2023 à(s) 11:40:

> On Wed Oct 18, 2023 at 11:26 AM CEST, Jose Quaresma wrote:
> > Erik Schilling  escreveu no dia quarta,
> > 18/10/2023 à(s) 07:33:
> >
> > > On Tue Oct 17, 2023 at 10:51 AM CEST, Jose Quaresma wrote:
> > > > Hi Erik,
> > > >
> > > > Erik Schilling  escreveu no dia terça,
> > > > 17/10/2023 à(s) 06:51:
> > > >
> > > > > On Mon Oct 16, 2023 at 6:31 PM CEST, Jose Quaresma wrote:
> > > > > > Erik Schilling  escreveu no dia
> segunda,
> > > > > > 16/10/2023 à(s) 13:02:
> > > > > >
> > > > > > > When building with `cryptsetup` and `tpm2` in the
> > > > > > > PACKAGECONFIG, this plugin will be emitted.
> > > > > > >
> > > > > > > Cc: Kristian Klausen 
> > > > > > > Cc: Mikko Rapeli 
> > > > > > > Cc: Javier Tia 
> > > > > > > Fixes: 7b7dfbfaed ("systemd: Add tpm2 PACKAGECONFIG")
> > > > > > > Signed-off-by: Erik Schilling 
> > > > > > > ---
> > > > > > >  meta/recipes-core/systemd/systemd_254.4.bb | 1 +
> > > > > > >  1 file changed, 1 insertion(+)
> > > > > > >
> > > > > > > diff --git a/meta/recipes-core/systemd/systemd_254.4.bb
> > > > > > > b/meta/recipes-core/systemd/systemd_254.4.bb
> > > > > > > index 77724eb822..6ecfbaf293 100644
> > > > > > > --- a/meta/recipes-core/systemd/systemd_254.4.bb
> > > > > > > +++ b/meta/recipes-core/systemd/systemd_254.4.bb
> > > > > > > @@ -645,6 +645,7 @@ FILES:${PN} = " ${base_bindir}/* \
> > > > > > >  ${sysconfdir}/X11/xinit/xinitrc.d/* \
> > > > > > >  ${rootlibexecdir}/systemd/* \
> > > > > > >  ${rootlibdir}/systemd/libsystemd-core* \
> > > > > > > +
> > > > > > > ${rootlibdir}/cryptsetup/libcryptsetup-token-systemd-tpm2* \
> > > > > > >
> > > > > >
> > > > > > The systemd-cryptenroll was packed in the systemd-extra-utils so
> > > packing
> > > > > > the plugin
> > > > > > on the main systemd package is a bit weird.
> > > > > > I wonder if a new package like systemd-crypt is better
> appropriate
> > > for
> > > > > this
> > > > > > where we
> > > > > > going to put the systemd-cryptenroll and all the plugins
> available in
> > > > > > ${rootlibdir}/cryptsetup
> > > > >
> > > > > Ah, did not realize that... I agree that breaking up systemd into
> > > > > smaller packages would probably be a good thing. Currently
> building an
> > > > > image with systemd in the initramfs and main image gives little
> choice
> > > > > over which components go where... I will try a systemd-crypt
> variant.
> > > > > Will also take a look at how other distros solve this.
> > > > >
> > > >
> > > > I've been using this systemd-crypt package on my distro for some
> time now
> > > > but I've forgotten to send it.
> > > > In this package additionally to the TPM plugin I also have another
> for
> > > the
> > > > PKVS#11.
> > > > I have all of these in a bbappend and I can easily extract.
> > >
> > >
> > > Ah that sounds great!
> > >
> > >
> > > > So you don't have to worry, I still do it today.
> > >
> > > Sorry, I do not understand what you mean here. Did you mean that you
> > > plan to send a patch?
> > >
> >
> > I apologize for not being clear. I sent the patch serie yesterday
> > [1]
> https://patchwork.yoctoproject.org/project/oe-core/list/?series=17834
>
> Thanks a lot! Will try it out in the next days!
>
> - Erik
>
> >
> >
> > >
> > > - Erik
> > >
> > > > > >
> > > > > >  ${libdir}/pam.d \
> > > > > > >  ${nonarch_libdir}/pam.d \
> > > > > > >  ${systemd_unitdir}/* \
> > > > > > >
> > > > > > > ---
> > > > > > > base-commit: 97f0a73c0a9db5506310328cd29f165eab3c509d
> > > > > > > change-id: 20231016-b4-systemd-tpm2-crypt-plugin-5064c458e726
> > > > > > >
> > > > > > > Best regards,
> > > > > > > --
> > > > > > > Erik Schilling 
> > > > > > >
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189503): 
https://lists.openembedded.org/g/openembedded-core/message/189503
Mute This Topic: https://lists.openembedded.org/mt/101993740/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.bbclass: support embedded SW components with different version number

[Jose Quaresma]

Mikko Rapeli  escreveu no dia quinta, 19/10/2023
à(s) 13:45:

> Hi,
>
> Could something like this work?
>
> --- a/meta/lib/oe/cve_check.py
> +++ b/meta/lib/oe/cve_check.py
> @@ -140,15 +140,14 @@ def get_patched_cves(d):
>  return patched_cves
>
>
> -def get_cpe_ids(cve_product, version):
> +def get_cpe_ids(cve_product, cve_version):
>  """
>  Get list of CPE identifiers for the given product and version
>  """
>
> -version = version.split("+git")[0]
> -
>  cpe_ids = []
>  for product in cve_product.split():
> +version = (d.getVar("CVE_VERSION_%s" % product) or
> cve_version).split("+git")[0]
>

Looks like your patch fixes the remaining issue
but don't know if it will be better to get the CVE_VERSION_ after
splitting  the vendor from the product

Jose


>  # CVE_PRODUCT in recipes may include vendor information for CPE
> identifiers. If not,
>  # use wildcard for vendor.
>  if ":" in product:
>
> Cheers,
>
> -Mikko
>


-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189502): 
https://lists.openembedded.org/g/openembedded-core/message/189502
Mute This Topic: https://lists.openembedded.org/mt/101991269/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] cve-check.bbclass: support embedded SW components with different version number

[Mikko Rapeli]

Many recipes embed other SW components. The name and version of the
embedded SW component differs from the main recipe. To detect CVEs in the
embedded SW component, it needs to be added to CVE_PRODUCT list using
name of the SW product in CVE database or with "vendor:product" syntax.
Then the version of the embedded SW component can be set using
CVE_VERSION_product variable.

For example in meta-arm, trusted-firmware-a embeds mbed_tls SW component.
Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database
uses product name "mbed_tls":

CVE_PRODUCT += "mbed_tls"

and set the version of mbed_tls:

CVE_VERSION_mbed_tls = "2.28.4"

(Real patches for both are a bit more complex due to conditional build
enabling mbed_tls support and due to mbed_tls version being set in an
.inc file.)

Now trusted-firmware-a CVE check output shows:

NOTE: recipe 
trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0: task 
do_cve_check: Started
WARNING: 
trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0 
do_cve_check: Found unpatched CVE (CVE-2021-36647 CVE-2021-43666 CVE-2021-45451 
CVE-2023-43615), for more information check 
/home/builder/src/base/build/tmp/work/arm64-poky-linux/trusted-firmware-a/2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122/temp/cve.log
NOTE: recipe 
trusted-firmware-a-2.9.0+gitd3e71ead6ea5bc3555ac90a446efec84ef6c6122-r0: task 
do_cve_check: Succeeded

Here CVE-2023-43615 is a newly added and fixed CVE in version 2.28.5 and the 
CVEs
from 2021 need to be checked but are likely fixed in 2.28.3 and newer 2.28.y 
releases.

Note that CVE-2023-43615 does not impact trusted-firmware-a since it doesn't use
TLS or null or RC4 ciphers, but I think it's a good idea to extend
CVE checker for this use case. I hope the "CVE_VERSION_vendor:product"
does not cause odd breakages.

Signed-off-by: Mikko Rapeli 
---
 meta/classes/create-spdx-2.2.bbclass |  2 +-
 meta/classes/cve-check.bbclass   | 28 +++-
 meta/lib/oe/cve_check.py |  5 ++---
 3 files changed, 22 insertions(+), 13 deletions(-)

v1: https://lists.openembedded.org/g/openembedded-core/message/189260

v2: adapt SPDX too

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass
index b0aef80db1..5b842e67ee 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -590,7 +590,7 @@ python do_create_spdx() {
 if patched_cves:
 recipe.sourceInfo = "CVEs fixed: " + patched_cves
 
-cpe_ids = oe.cve_check.get_cpe_ids(d.getVar("CVE_PRODUCT"), 
d.getVar("CVE_VERSION"))
+cpe_ids = oe.cve_check.get_cpe_ids(d, d.getVar("CVE_PRODUCT"), 
d.getVar("CVE_VERSION"))
 if cpe_ids:
 for cpe_id in cpe_ids:
 cpe = oe.spdx.SPDXExternalReference()
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index b55f4299da..9c41d54188 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -309,7 +309,16 @@ def check_cves(d, patched_cves):
 # If this has been unset then we're not scanning for CVEs here (for 
example, image recipes)
 if not products:
 return ([], [], [], [])
-pv = d.getVar("CVE_VERSION").split("+git")[0]
+
+# Version is PV, CVE_VERSION or CVE_VERSION_%s where %s is one of the 
entries in CVE_PRODUCT.
+# Enables checking embedded SW component CVEs provided that CVE_PRODUCT 
contains the embedded SW
+# component and that version of that component is set via 
CVE_VERSION_embedded_component variable.
+pv = {}
+for product in products:
+version = (d.getVar("CVE_VERSION_%s" % product) or "").split("+git")[0]
+if version == "":
+version = d.getVar("CVE_VERSION").split("+git")[0]
+pv[product] = version
 
 # If the recipe has been skipped/ignored we return empty lists
 if pn in d.getVar("CVE_CHECK_SKIP_RECIPE").split():
@@ -329,6 +338,7 @@ def check_cves(d, patched_cves):
 
 # For each of the known product names (e.g. curl has CPEs using curl and 
libcurl)...
 for product in products:
+full_product = product
 cves_in_product = False
 if ":" in product:
 vendor, product = product.split(":", 1)
@@ -341,7 +351,7 @@ def check_cves(d, patched_cves):
 cve = cverow[0]
 
 if cve in cve_ignore:
-bb.note("%s-%s ignores %s" % (product, pv, cve))
+bb.note("%s-%s ignores %s" % (product, pv[full_product], cve))
 cves_ignored.append(cve)
 continue
 elif cve in patched_cves:
@@ -366,27 +376,27 @@ def check_cves(d, patched_cves):
 version_start = convert_cve_version(version_start)
 version_end = convert_cve_version(version_end)
 
-if (operator_start == '=' and pv == version_start) or 
version_start == '-':
+if (operator_start == '=' and pv[full_product] == 

[OE-core] [PATCH] package_qa_check_rdepends: Allow /usr/bin/sh if usrmerge

[Jörg Sommer via lists . openembedded . org]

If the distro feature usrmerge is set, all files from /bin are moved to
/usr/bin, i.e. /usr/bin/sh is the same as /bin/sh and should be allowed be
ignored, because it's always present.

Signed-off-by: Jörg Sommer 
---
 meta/classes-global/insane.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes-global/insane.bbclass 
b/meta/classes-global/insane.bbclass
index 6f3cd3026d..ecc868a4e0 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -923,8 +923,12 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, 
taskdeps, packages, d):
 
 if "file-rdeps" not in skip:
 ignored_file_rdeps = set(['/bin/sh', '/usr/bin/env', 
'rtld(GNU_HASH)'])
+if bb.utils.contains('DISTRO_FEATURES', 'usrmerge', True, False, 
d):
+ignored_file_rdeps |= set(['/usr/bin/sh'])
 if bb.data.inherits_class('nativesdk', d):
 ignored_file_rdeps |= set(['/bin/bash', '/usr/bin/perl', 
'perl'])
+if bb.utils.contains('DISTRO_FEATURES', 'usrmerge', True, 
False, d):
+ignored_file_rdeps |= set(['/usr/bin/bash'])
 # For Saving the FILERDEPENDS
 filerdepends = {}
 rdep_data = oe.packagedata.read_subpkgdata(pkg, d)
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189500): 
https://lists.openembedded.org/g/openembedded-core/message/189500
Mute This Topic: https://lists.openembedded.org/mt/102076957/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.bbclass: support embedded SW components with different version number

[Jose Quaresma]

Mikko Rapeli  escreveu no dia quinta, 19/10/2023
à(s) 13:21:

> Hi,
>
> On Thu, Oct 19, 2023 at 12:54:44PM +0100, Jose Quaresma wrote:
> > Hi
> >
> > This change will need some adaptations in the create-spdx.bbclass to
> handle
> > this new variable with _PN
>
> Good point. How does SPDX tooling handle embedded SW components in recipe
> sources?
>

As far as I know SPDX doesn't support this at all because the class has a
way of knowing that these components exist.


>
> I presume it does not because recipe and license don't handle it either.
> Should
> there be a more generic PN_subpn, PV_subpn, LICENSE_subpn and matching
> CVE_PRODUCT
> and CVE_VERSION? I don't have use cases for these currently. I would like
> to fix
> the CVE reporting issues with embedded SW components though. mbedtls being
> one good
> example.
>
> Or would it be better to convert mbedtls users to use the meta-oe side
> recipe for it?
>

In a perfect world this would be the way but as we know the world is far
from perfect :)


>
> Additionally I don't currently read the SDPX output. I don't have use
> cases for it.
> I do check recipes and their metadata like LICENSE though. Feels like the
> SDPX data
> is used as reporting/export data format which is fed to some other tools
> which are
> not open source.


> Can of worms...
>

Given that one of the main characteristics of the SPDX metadata is that
they enable and have a complete description
of the software used, this can and will be used by other tools to do all
types of analysis.
AI models will love eating this...


>
> Cheers,
>
> -Mikko
>


-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189499): 
https://lists.openembedded.org/g/openembedded-core/message/189499
Mute This Topic: https://lists.openembedded.org/mt/101991269/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 0/2] Add a display limit for regression report generation

[Alexis Lothoré via lists . openembedded . org]

Hello Alexandre,

On 10/20/23 08:05, Alexandre Belloni via lists.openembedded.org wrote:
> Hello Alexis,> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5886/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5935/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5952/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5936/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2296/steps/14/logs/stdio
> 
> 
> 2023-10-19 07:28:44,229 - oe-selftest - INFO - 
> resulttooltests.ResultToolTests.test_can_match_non_static_ptest_names 
> (subunit.RemotedTestCase)
> 2023-10-19 07:28:44,229 - oe-selftest - INFO -  ... ERROR
> Stderr:
> 2023-10-19 07:05:57,080 - oe-selftest - INFO - Adding: "include selftest.inc" 
> in 
> /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-271681/conf/local.conf
> 2023-10-19 07:05:57,081 - oe-selftest - INFO - Adding: "include bblayers.inc" 
> in bblayers.conf
> 2023-10-19 07:28:44,229 - oe-selftest - INFO - 6: 24/42 185/543 (0.01s) (0 
> failed) 
> (resulttooltests.ResultToolTests.test_can_match_non_static_ptest_names)
> 2023-10-19 07:28:44,230 - oe-selftest - INFO - 
> testtools.testresult.real._StringException: Traceback (most recent call last):
>   File 
> "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/resulttooltests.py",
>  line 372, in test_can_match_non_static_ptest_names
> result, resultstring = regression.compare_result(
>^^
> TypeError: compare_result() missing 1 required positional argument: 
> 'display_limit'

Looks like I forgot to update/run selftests locally before pushing... Sorry for
the mess and thanks for the notification.
Anyway, Ross and Richard gave some relevant feedback
(https://lore.kernel.org/yocto/90d7fe40-32eb-4d67-b099-9e0c764fc...@arm.com/) on
this so I will prepare a v2, which fill also fix this selftest.

Thanks,

Alexis
-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189498): 
https://lists.openembedded.org/g/openembedded-core/message/189498
Mute This Topic: https://lists.openembedded.org/mt/102057050/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 0/2] Add a display limit for regression report generation

[Alexandre Belloni via lists.openembedded.org]

Hello Alexis,

On 19/10/2023 11:53:50+0200, Alexis Lothoré via lists.openembedded.org wrote:
> It has been observed that useful information in regression report can be
> drowned in huge regression lists which are often false-positives (for
> example, a whole set of tests has been temporarily disabled).
> 
> This series brings a default limit to how many changes are displayed per
> base/target comparison. This default can still be overriden on commandline,
> for example to have a better look at the whole regression list when trying
> to debug an issue (i.e. by disabling the limit)
> 
> First commit implement the limit, its default value and the corresponding
> commandline option in resulttool.
> Second commit allow yocto_testresults_query.py to drive this value.
> 
> As a result, one can for example do the following:
> - yocto_testresults_query 4.3_M1 4.3_M2
>   -> will display at most 50 regressions per test
> - yocto_testresults_query -l 10 4.3_M1 4.3_M2
>   -> override the display limit and reduce it to 10 regressions per pair.
> - yocto_testresults_query -l 0 4.3_M1 4.3_M2
>   -> disable the display limit, print all regressions
> 
> An example of regression report with display limit can be found here:
> https://pastebin.com/6QbfGstR
> 
> Alexis Lothoré (2):
>   scripts/resulttool: limit the number of changes displayed per test
>   scripts/yocto_testresults_query: add option to change display limit
> 

This causes:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5886/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5935/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5952/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5936/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2296/steps/14/logs/stdio


2023-10-19 07:28:44,229 - oe-selftest - INFO - 
resulttooltests.ResultToolTests.test_can_match_non_static_ptest_names 
(subunit.RemotedTestCase)
2023-10-19 07:28:44,229 - oe-selftest - INFO -  ... ERROR
Stderr:
2023-10-19 07:05:57,080 - oe-selftest - INFO - Adding: "include selftest.inc" 
in 
/home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-271681/conf/local.conf
2023-10-19 07:05:57,081 - oe-selftest - INFO - Adding: "include bblayers.inc" 
in bblayers.conf
2023-10-19 07:28:44,229 - oe-selftest - INFO - 6: 24/42 185/543 (0.01s) (0 
failed) (resulttooltests.ResultToolTests.test_can_match_non_static_ptest_names)
2023-10-19 07:28:44,230 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/resulttooltests.py",
 line 372, in test_can_match_non_static_ptest_names
result, resultstring = regression.compare_result(
   ^^
TypeError: compare_result() missing 1 required positional argument: 
'display_limit'


2023-10-19 07:28:44,311 - oe-selftest - INFO - 
resulttooltests.ResultToolTests.test_regression_can_get_regression_result 
(subunit.RemotedTestCase)
2023-10-19 07:28:44,311 - oe-selftest - INFO -  ... ERROR
Stderr:
2023-10-19 07:05:57,080 - oe-selftest - INFO - Adding: "include selftest.inc" 
in 
/home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-271681/conf/local.conf
2023-10-19 07:05:57,081 - oe-selftest - INFO - Adding: "include bblayers.inc" 
in bblayers.conf
2023-10-19 07:28:44,312 - oe-selftest - INFO - 6: 31/42 192/543 (0.01s) (2 
failed) 
(resulttooltests.ResultToolTests.test_regression_can_get_regression_result)
2023-10-19 07:28:44,312 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/resulttooltests.py",
 line 85, in test_regression_can_get_regression_result
result, text = regression.compare_result(self.logger, "BaseTestRunName", 
"TargetTestRunName", base_result_data, target_result_data)
   

TypeError: compare_result() missing 1 required positional argument: 
'display_limit'


>  scripts/lib/resulttool/regression.py | 23 +++
>  scripts/yocto_testresults_query.py   | 13 ++---
>  2 files changed, 29 insertions(+), 7 deletions(-)
> 
> -- 
> 2.42.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 (#189497): 
https://lists.openembedded.org/g/openembedded-core/message/189497
Mute This Topic: https://lists.openembedded.org/mt/102057050/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: 

Re: [OE-core] [PATCH v2 3/4] scripts:recipetool:create_buildsys_python: refactor code for futur PEP517 addition

[Alexandre Belloni via lists.openembedded.org]

Hello,

On 19/10/2023 09:36:52+0200, Julien Stephan wrote:
> In order to prepare the support for pyproject.toml (PEP517 [1]) enabled
> projects, refactor the code and move setup.py specific code into a
> specific class in order to allow sharing the PythonRecipeHandler class
> 
> No functionnal changes expected
> 

I tested with only the first 3 patches and unfortunately, thre were
functional changes:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5886/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5935/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5952/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5936/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2296/steps/14/logs/stdio

2023-10-19 07:23:07,712 - oe-selftest - INFO - 1: 20/39 149/543 (20.20s) (0 
failed) (recipetool.RecipetoolCreateTests.test_recipetool_create_github)
2023-10-19 07:23:07,712 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/recipetool.py",
 line 451, in test_recipetool_create_github
self.assertTrue(os.path.isfile(recipefile))
  File "/usr/lib/python3.11/unittest/case.py", line 715, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true

> [1]: https://peps.python.org/pep-0517/#source-tree
> 
> Signed-off-by: Julien Stephan 
> ---
>  .../lib/recipetool/create_buildsys_python.py  | 748 +-
>  1 file changed, 385 insertions(+), 363 deletions(-)
> 
> diff --git a/scripts/lib/recipetool/create_buildsys_python.py 
> b/scripts/lib/recipetool/create_buildsys_python.py
> index 502e1dfbc3d..69f6f5ca511 100644
> --- a/scripts/lib/recipetool/create_buildsys_python.py
> +++ b/scripts/lib/recipetool/create_buildsys_python.py
> @@ -37,63 +37,8 @@ class PythonRecipeHandler(RecipeHandler):
>  assume_provided = ['builtins', 'os.path']
>  # Assumes that the host python3 builtin_module_names is sane for target 
> too
>  assume_provided = assume_provided + list(sys.builtin_module_names)
> +excluded_fields = []
>  
> -bbvar_map = {
> -'Name': 'PN',
> -'Version': 'PV',
> -'Home-page': 'HOMEPAGE',
> -'Summary': 'SUMMARY',
> -'Description': 'DESCRIPTION',
> -'License': 'LICENSE',
> -'Requires': 'RDEPENDS:${PN}',
> -'Provides': 'RPROVIDES:${PN}',
> -'Obsoletes': 'RREPLACES:${PN}',
> -}
> -# PN/PV are already set by recipetool core & desc can be extremely long
> -excluded_fields = [
> -'Description',
> -]
> -setup_parse_map = {
> -'Url': 'Home-page',
> -'Classifiers': 'Classifier',
> -'Description': 'Summary',
> -}
> -setuparg_map = {
> -'Home-page': 'url',
> -'Classifier': 'classifiers',
> -'Summary': 'description',
> -'Description': 'long-description',
> -}
> -# Values which are lists, used by the setup.py argument based metadata
> -# extraction method, to determine how to process the setup.py output.
> -setuparg_list_fields = [
> -'Classifier',
> -'Requires',
> -'Provides',
> -'Obsoletes',
> -'Platform',
> -'Supported-Platform',
> -]
> -setuparg_multi_line_values = ['Description']
> -replacements = [
> -('License', r' +$', ''),
> -('License', r'^ +', ''),
> -('License', r' ', '-'),
> -('License', r'^GNU-', ''),
> -('License', r'-[Ll]icen[cs]e(,?-[Vv]ersion)?', ''),
> -('License', r'^UNKNOWN$', ''),
> -
> -# Remove currently unhandled version numbers from these variables
> -('Requires', r' *\([^)]*\)', ''),
> -('Provides', r' *\([^)]*\)', ''),
> -('Obsoletes', r' *\([^)]*\)', ''),
> -('Install-requires', r'^([^><= ]+).*', r'\1'),
> -('Extras-require', r'^([^><= ]+).*', r'\1'),
> -('Tests-require', r'^([^><= ]+).*', r'\1'),
> -
> -# Remove unhandled dependency on particular features (e.g. foo[PDF])
> -('Install-requires', r'\[[^\]]+\]$', ''),
> -]
>  
>  classifier_license_map = {
>  'License :: OSI Approved :: Academic Free License (AFL)': 'AFL',
> @@ -166,122 +111,34 @@ class PythonRecipeHandler(RecipeHandler):
>  def __init__(self):
>  pass
>  
> -def process(self, srctree, classes, lines_before, lines_after, handled, 
> extravalues):
> -if 'buildsystem' in handled:
> -return False
> -
> -# Check for non-zero size setup.py files
> -setupfiles = RecipeHandler.checkfiles(srctree, ['setup.py'])
> -for fn in setupfiles:
> -if os.path.getsize(fn):
> -break
> -else:
> -return False
> -
> -#