Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] package_qa_check_rdepends: Allow /usr/bin/sh if usrmerge
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] cve-check.bbclass: support embedded SW components with different version number
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] == versio
Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] systemd: fix packaging tpm2 plugin for cryptsetup
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
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] Detecting unimplemented ptests with heuristics
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][master][mickledore][PATCH] grub2: fix CVE-2023-4692
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 \ +
[OE-core][kirkstone][PATCH] libx11: Security Fix for CVE-2023-43785, CVE-2023-43786 and CVE-2023-43787
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 *) &map->syms[offset], +- newMap->nSyms); ++if (_XkbReadBufferCopyKeySyms(buf, (KeySym *) &map->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:
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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][master][mickledore][PATCH] grub2: fix CVE-2023-4693
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] CVE work synchronization proposal
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] shadow: update 4.13 -> 4.14.1
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 (unus
Re: [OE-core] [PATCH v2 3/4] scripts:recipetool:create_buildsys_python: refactor code for futur PEP517 addition
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 +111,
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore][PATCH] shadow: Fix CVE-2023-4641
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 way.
[OE-core] [PATCH 1/4] package_rpm.bbclass: Fix some pycodestyle issues
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 = bb.utils.explode_dep_versions2(srcrrep
[OE-core] [PATCH 2/4] package_rpm.bbclass: Minor cosmetic and style fixes
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 3/4] package_rpm.bbclass: Remove unused definitions
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 4/4] package_rpm.bbclass: Support compression override
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
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 4/4] package_rpm.bbclass: Support compression override
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] selftest/sstatetests: add tests for 'bitbake -S printdiff'
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 0/3] lighttpd-1.4.72
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] lighttpd: upgrade 1.4.71 -> 1.4.72
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
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 3/3] lighttpd: modernize lighttpd.conf
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"
Re: [OE-core] [PATCH 4/4] package_rpm.bbclass: Support compression override
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] selftest/sstatetests: add tests for 'bitbake -S printdiff'
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] [mickledore] glibc: stable 2.37 branch updates.
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] shared-mime-info: Fix missing sentinel warning
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] [PATCH v2] shared-mime-info: Fix missing sentinel warning
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 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
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] CVE work synchronization proposal
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] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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: https://li
Re: [OE-core] [PATCH v2] selftest/sstatetests: add tests for 'bitbake -S printdiff'
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 v2] selftest/sstatetests: add tests for 'bitbake -S printdiff'
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] patchtest: fix lic_files_chksum test regex
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 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
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 convi
[OE-core][mickledore 00/24] Patch review
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
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 02/24] dmidecode: fixup for CVE-2023-30630
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, + &size, 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 03/24] qemu: ignore RHEL specific CVE-2023-2680
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 04/24] cve-check: add CVSS vector string to CVE database and reports
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 06/24] libx11: upgrade to 1.8.7
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
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 07/24] libxpm: upgrade to 3.5.17
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 08/24] linux-yocto/6.1: update to v6.1.55
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 reg
[OE-core][mickledore 09/24] linux-yocto/6.1: update to v6.1.56
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 controller
[OE-core][mickledore 10/24] linux-yocto/6.1: tiny: fix arm 32 boot
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 11/24] linux-yocto/6.1: update to v6.1.57
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 &tx->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 iommu/media
[OE-core][mickledore 12/24] cve-exclusion_6.1.inc: update for 6.1.57
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 13/24] vim: Upgrade 9.0.2009 -> 9.0.2048
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 14/24] uboot-extlinux-config.bbclass: fix missed override syntax migration
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 15/24] shadow: fix patch Upstream-Status
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 16/24] libevent: fix patch Upstream-Status
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 17/24] fontcache.bbclass: avoid native recipes depending on target fontconfig
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 18/24] insane.bbclass: Count raw bytes in shebang-size
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 19/24] oeqa/selftest: Fix broken symlink removal handling
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 20/24] oeqa/utils/gitarchive: Handle broken commit counts in results repo
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 22/24] oeqa/concurrencytest: Remove invalid buffering option
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 23/24] packages.bbclass: Correct the check for conflicts with renamed packages
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
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 24/24] busybox: Set PATH in syslog initscript
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] cve-check.bbclass: support embedded SW components with different version number
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 check_c
Re: [OE-core][mickledore][PATCH] weston: default to launcher-seatd
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 4/4] package_rpm.bbclass: Support compression override
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] lib/oe/sstatesig.py: dump locked.sigs.inc only when explicitly asked via -S lockedsigs
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
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] libsndfile1: fix CVE-2022-33065
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 (&au_fmt, 0, sizeof (au_fmt)) ; + psf_binheader_readf (psf, "pm", 0, &marker) ; +@@ -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: https://github.com/libsndfile/libsndfile/
Re: [OE-core][mickledore][PATCH] weston: default to launcher-seatd
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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][mickledore][PATCH] weston: default to launcher-seatd
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] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] openssl: Match target name for riscv64/riscv32
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][master][mickledore][PATCH] grub2: fix CVE-2023-4692
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 > --- a/meta/recipes-bsp/grub/gr
Re: [OE-core] [PATCH 2/2] selftest/sstatetests: add a test for CDN sstate cache
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] -=-=-=-=-=-=-=-=-=-=-=-