[OE-core] [kirkstone][PATCH 1/2] files: overlayfs-etc: refactor preinit template
From: Vyacheslav Yurkov
Signed-off-by: Vyacheslav Yurkov
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
meta/files/overlayfs-etc-preinit.sh.in | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/meta/files/overlayfs-etc-preinit.sh.in
b/meta/files/overlayfs-etc-preinit.sh.in
index 43c9b04eb9..0e80849f12 100644
--- a/meta/files/overlayfs-etc-preinit.sh.in
+++ b/meta/files/overlayfs-etc-preinit.sh.in
@@ -15,19 +15,23 @@ mount -t sysfs sysfs /sys
[ -z "$CONSOLE" ] && CONSOLE="/dev/console"
+BASE_OVERLAY_ETC_DIR={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc
+UPPER_DIR=$BASE_OVERLAY_ETC_DIR/upper
+WORK_DIR=$BASE_OVERLAY_ETC_DIR/work
+
mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}
if mount -n -t {OVERLAYFS_ETC_FSTYPE} \
-o {OVERLAYFS_ETC_MOUNT_OPTIONS} \
{OVERLAYFS_ETC_DEVICE} {OVERLAYFS_ETC_MOUNT_POINT}
then
-mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper
-mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/work
+mkdir -p $UPPER_DIR
+mkdir -p $WORK_DIR
mount -n -t overlay \
--o upperdir={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper \
+-o upperdir=$UPPER_DIR \
-o lowerdir=/etc \
--o workdir={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/work \
+-o workdir=$WORK_DIR \
-o index=off,xino=off,redirect_dir=off,metacopy=off \
-{OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc/upper /etc || \
+$UPPER_DIR /etc || \
echo "PREINIT: Mounting etc-overlay failed!"
else
echo "PREINIT: Mounting failed!"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171960):
https://lists.openembedded.org/g/openembedded-core/message/171960
Mute This Topic: https://lists.openembedded.org/mt/94425835/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone][PATCH 2/2] classes: files: Extend overlayfs-etc class
From: Vyacheslav Yurkov
Add the ability to expose the lower layer of /etc when mounting overlay.
This is the similar to what overlayroot script from initramfs-framework does.
By default, this option is turned off to keep an old behavior intact.
Signed-off-by: Vyacheslav Yurkov
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
meta/classes/overlayfs-etc.bbclass | 5 -
meta/files/overlayfs-etc-preinit.sh.in | 9 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/meta/classes/overlayfs-etc.bbclass
b/meta/classes/overlayfs-etc.bbclass
index 91afee695c..40116e4c6e 100644
--- a/meta/classes/overlayfs-etc.bbclass
+++ b/meta/classes/overlayfs-etc.bbclass
@@ -34,6 +34,7 @@ OVERLAYFS_ETC_DEVICE ??= ""
OVERLAYFS_ETC_USE_ORIG_INIT_NAME ??= "1"
OVERLAYFS_ETC_MOUNT_OPTIONS ??= "defaults"
OVERLAYFS_ETC_INIT_TEMPLATE ??=
"${COREBASE}/meta/files/overlayfs-etc-preinit.sh.in"
+OVERLAYFS_ETC_EXPOSE_LOWER ??= "0"
python create_overlayfs_etc_preinit() {
overlayEtcMountPoint = d.getVar("OVERLAYFS_ETC_MOUNT_POINT")
@@ -54,13 +55,15 @@ python create_overlayfs_etc_preinit() {
preinitPath = oe.path.join(d.getVar("IMAGE_ROOTFS"),
d.getVar("base_sbindir"), "preinit")
initBaseName = oe.path.join(d.getVar("base_sbindir"), "init")
origInitNameSuffix = ".orig"
+exposeLower = oe.types.boolean(d.getVar('OVERLAYFS_ETC_EXPOSE_LOWER'))
args = {
'OVERLAYFS_ETC_MOUNT_POINT': overlayEtcMountPoint,
'OVERLAYFS_ETC_MOUNT_OPTIONS': d.getVar('OVERLAYFS_ETC_MOUNT_OPTIONS'),
'OVERLAYFS_ETC_FSTYPE': overlayEtcFsType,
'OVERLAYFS_ETC_DEVICE': overlayEtcDevice,
-'SBIN_INIT_NAME': initBaseName + origInitNameSuffix if useOrigInit
else initBaseName
+'SBIN_INIT_NAME': initBaseName + origInitNameSuffix if useOrigInit
else initBaseName,
+'OVERLAYFS_ETC_EXPOSE_LOWER': "true" if exposeLower else "false"
}
if useOrigInit:
diff --git a/meta/files/overlayfs-etc-preinit.sh.in
b/meta/files/overlayfs-etc-preinit.sh.in
index 0e80849f12..8db076f4ba 100644
--- a/meta/files/overlayfs-etc-preinit.sh.in
+++ b/meta/files/overlayfs-etc-preinit.sh.in
@@ -18,6 +18,7 @@ mount -t sysfs sysfs /sys
BASE_OVERLAY_ETC_DIR={OVERLAYFS_ETC_MOUNT_POINT}/overlay-etc
UPPER_DIR=$BASE_OVERLAY_ETC_DIR/upper
WORK_DIR=$BASE_OVERLAY_ETC_DIR/work
+LOWER_DIR=$BASE_OVERLAY_ETC_DIR/lower
mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}
if mount -n -t {OVERLAYFS_ETC_FSTYPE} \
@@ -26,6 +27,14 @@ if mount -n -t {OVERLAYFS_ETC_FSTYPE} \
then
mkdir -p $UPPER_DIR
mkdir -p $WORK_DIR
+
+if {OVERLAYFS_ETC_EXPOSE_LOWER}; then
+mkdir -p $LOWER_DIR
+
+# provide read-only access to original /etc content
+mount -o bind,ro /etc $LOWER_DIR
+fi
+
mount -n -t overlay \
-o upperdir=$UPPER_DIR \
-o lowerdir=/etc \
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171961):
https://lists.openembedded.org/g/openembedded-core/message/171961
Mute This Topic: https://lists.openembedded.org/mt/94425836/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][kirkstone][PATCH V2] openssl: export necessary env vars in SDK
In current SDK, when running the following command in python shell, we get an error. $ python3 >>> from cryptography.hazmat.backends import openssl The error message is as below: cryptography.exceptions.InternalError: Unknown OpenSSL error. We could set OPENSSL_MODULES explicitly in nativesdk-openssl package so that when SDK is set up, it's in environment and we can get rid of the above error. Also, there are other env vars that need to be exported. And we export all of them to keep sync with openssl-native.bbclass. Signed-off-by: Chen Qi --- .../openssl/files/environment.d-openssl.sh| 4 1 file changed, 4 insertions(+) diff --git a/meta/recipes-connectivity/openssl/files/environment.d-openssl.sh b/meta/recipes-connectivity/openssl/files/environment.d-openssl.sh index b9cc24a7ac..516bbd1c56 100644 --- a/meta/recipes-connectivity/openssl/files/environment.d-openssl.sh +++ b/meta/recipes-connectivity/openssl/files/environment.d-openssl.sh @@ -1 +1,5 @@ export OPENSSL_CONF="$OECORE_NATIVE_SYSROOT/usr/lib/ssl/openssl.cnf" +export SSL_CERT_DIR="$OECORE_NATIVE_SYSROOT/usr/lib/ssl/certs" +export SSL_CERT_FILE="$OECORE_NATIVE_SYSROOT/usr/lib/ssl/cert.pem" +export OPENSSL_MODULES="$OECORE_NATIVE_SYSROOT/usr/lib/ossl-modules/" +export OPENSSL_ENGINES="$OECORE_NATIVE_SYSROOT/usr/lib/engines-3" -- 2.37.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171962): https://lists.openembedded.org/g/openembedded-core/message/171962 Mute This Topic: https://lists.openembedded.org/mt/94427115/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] grub: disable build on armv7ve/a with hardfp
Hi,
On Wed, Oct 19, 2022 at 3:54 AM Yu, Mingli wrote:
> From: Mingli Yu
>
> The commit(75dbdea940 grub: Allow build on armv7ve/a with softfp)
> enable build on armv7ve/a with softfp, but it acutally enable
> build on armv7ve/a with hardfp altogether and result in below build
> failure:
> | checking for compile options to get strict alignment...
> -mno-unaligned-access
> | checking if compiler generates unaligned accesses... no
> | checking if C symbols get an underscore after compilation... no
> | checking whether target compiler is working... no
> | configure: error: cannot compile for the target
>
> So update the check to disable build on armv7ve/a with hardfp.
>
> Signed-off-by: Mingli Yu
> ---
> meta/recipes-bsp/grub/grub2.inc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-bsp/grub/grub2.inc
> b/meta/recipes-bsp/grub/grub2.inc
> index 2545b99b6a..7161c4560b 100644
> --- a/meta/recipes-bsp/grub/grub2.inc
> +++ b/meta/recipes-bsp/grub/grub2.inc
> @@ -50,8 +50,8 @@ COMPATIBLE_HOST = "${GRUB_COMPATIBLE_HOST}"
> # Grub doesn't support hard float toolchain and won't be able to
> forcefully
> # disable it on some of the target CPUs. See 'configure.ac' for
> # supported/unsupported CPUs in hardfp.
> -COMPATIBLE_HOST:armv7a = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') ==
> 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
> -COMPATIBLE_HOST:armv7ve = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') ==
> 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
> +COMPATIBLE_HOST:armv7a = "${@'null' if
> bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', True, False, d) else
> d.getVar('GRUB_COMPATIBLE_HOST')}"
> +COMPATIBLE_HOST:armv7ve = "${@'null' if
> bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', True, False, d) else
> d.getVar('GRUB_COMPATIBLE_HOST')}"
>
Sounds like a typo on my side. I'll check my testing as I'm curious how
I've managed to miss this. Thanks for fixing it!
Andrei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171963):
https://lists.openembedded.org/g/openembedded-core/message/171963
Mute This Topic: https://lists.openembedded.org/mt/94423825/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] mesa: Add native patch via a variable
This also begs the question if mesa-gl is actually used by anyone, and what warrants its continued inclusion in core as opposed to product/BSP layers. I'll propose dropping the recipe and merging .inc into mesa.bb once patches start flowing. The original commit was: https://git.yoctoproject.org/poky/commit/?h=master-next&id=015cb13 Alex On Wed, 19 Oct 2022 at 08:54, Alexander Kanavin via lists.openembedded.org wrote: > > On Wed, 19 Oct 2022 at 08:34, Khem Raj wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > wrote: > > > > > > Can you show examples where this is needed? Custom variable does not seem > > > a good idea. I also worry that it’ll break automated updates (it’s bad > > > enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > "require recipes-graphics/mesa/mesa.inc" > > Using recipe includes across layers like this is not a good idea. It > imposes requirements on core to continue providing the .inc, and not > doing anything with mesa that can 'break' users of that include. > > Please make it self-contained. > > Alex > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171964): https://lists.openembedded.org/g/openembedded-core/message/171964 Mute This Topic: https://lists.openembedded.org/mt/94420106/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] create-spdx: Remove ";name=..." for downloadLocation
Signed-off-by: Keiya Nobuta
---
meta/classes/create-spdx.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index 47dd12c383..c190ad3889 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -459,6 +459,7 @@ python do_create_spdx() {
for s in d.getVar('SRC_URI').split():
if not s.startswith("file://"):
+s = s.split(';')[0]
recipe.downloadLocation = s
break
else:
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171965):
https://lists.openembedded.org/g/openembedded-core/message/171965
Mute This Topic: https://lists.openembedded.org/mt/94428129/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] create-spdx: Fix "licenseDeclared" shows weird value
Fixed an issue that "licenseDeclared" shows weird value, for example
`busybox.spdx.json` shows like:
"GPL-2.0-only AND DocumentRef-recipe-busybox:LicenseRef-bzip2-1.0.4"
^^^
unwanted value
Signed-off-by: Keiya Nobuta
---
meta/classes/create-spdx.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index c190ad3889..1661c7d2f0 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -534,7 +534,7 @@ python do_create_spdx() {
recipe_ref.checksum.checksumValue = doc_sha1
sources = collect_dep_sources(d, dep_recipes)
-found_licenses = {license.name:recipe_ref.externalDocumentId + ":" +
license.licenseId for license in doc.hasExtractedLicensingInfos}
+found_licenses = {license.name: license.licenseId for license in
doc.hasExtractedLicensingInfos}
if not recipe_spdx_is_native(d, recipe):
bb.build.exec_func("read_subpackage_metadata", d)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171967):
https://lists.openembedded.org/g/openembedded-core/message/171967
Mute This Topic: https://lists.openembedded.org/mt/94428131/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] gnutls: Unified pakcage names to lower-case
create-spdx can't detect the license properly if the case doesn't
match, so fix it.
Signed-off-by: Keiya Nobuta
---
meta/recipes-support/gnutls/gnutls_3.7.7.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/gnutls/gnutls_3.7.7.bb
b/meta/recipes-support/gnutls/gnutls_3.7.7.bb
index 01fd4dba3d..c7d782e4eb 100644
--- a/meta/recipes-support/gnutls/gnutls_3.7.7.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.7.7.bb
@@ -8,7 +8,7 @@ LICENSE = "GPL-3.0-or-later & LGPL-2.1-or-later"
LICENSE:${PN} = "LGPL-2.1-or-later"
LICENSE:${PN}-xx = "LGPL-2.1-or-later"
LICENSE:${PN}-bin = "GPL-3.0-or-later"
-LICENSE:${PN}-OpenSSL = "GPL-3.0-or-later"
+LICENSE:${PN}-openssl = "GPL-3.0-or-later"
LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
file://doc/COPYING;md5=c678957b0c8e964aa6c70fd77641a71e \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171966):
https://lists.openembedded.org/g/openembedded-core/message/171966
Mute This Topic: https://lists.openembedded.org/mt/94428130/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 3/3] gnutls: Unified pakcage names to lower-case
On Wed, Oct 19, 2022 at 4:08 AM Keiya Nobuta wrote:
>
> create-spdx can't detect the license properly if the case doesn't
> match, so fix it.
I wonder if this could be some sort of QA warning that can flags such
issues, I do see this
might be a common error to make.
>
> Signed-off-by: Keiya Nobuta
> ---
> meta/recipes-support/gnutls/gnutls_3.7.7.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> b/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> index 01fd4dba3d..c7d782e4eb 100644
> --- a/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> +++ b/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> @@ -8,7 +8,7 @@ LICENSE = "GPL-3.0-or-later & LGPL-2.1-or-later"
> LICENSE:${PN} = "LGPL-2.1-or-later"
> LICENSE:${PN}-xx = "LGPL-2.1-or-later"
> LICENSE:${PN}-bin = "GPL-3.0-or-later"
> -LICENSE:${PN}-OpenSSL = "GPL-3.0-or-later"
> +LICENSE:${PN}-openssl = "GPL-3.0-or-later"
>
> LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
> file://doc/COPYING;md5=c678957b0c8e964aa6c70fd77641a71e \
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171968):
https://lists.openembedded.org/g/openembedded-core/message/171968
Mute This Topic: https://lists.openembedded.org/mt/94428130/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] mesa: Add native patch via a variable
On Tue, Oct 18, 2022 at 11:54 PM Alexander Kanavin wrote: > > On Wed, 19 Oct 2022 at 08:34, Khem Raj wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > wrote: > > > > > > Can you show examples where this is needed? Custom variable does not seem > > > a good idea. I also worry that it’ll break automated updates (it’s bad > > > enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > "require recipes-graphics/mesa/mesa.inc" > > Using recipe includes across layers like this is not a good idea. It > imposes requirements on core to continue providing the .inc, and not > doing anything with mesa that can 'break' users of that include. > the reason for .inc to exist does include this usecase. oe-core metadata is extensible by these constructs, it's similar to bbclass perhaps a bit smaller in scope. Getting rid of .inc will state that we do not allow other layers to use it. These are APIs of sorts that oe-core exports and people build on them, its fine if they should be changed but there should some well understood path otherwise they just make hard things harder. The load of upgrading from one release to other is already high and it keeps going up. > Please make it self-contained. > > Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171969): https://lists.openembedded.org/g/openembedded-core/message/171969 Mute This Topic: https://lists.openembedded.org/mt/94420106/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] mesa: Add native patch via a variable
On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org wrote: > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > wrote: >> >> Can you show examples where this is needed? Custom variable does not seem a >> good idea. I also worry that it’ll break automated updates (it’s bad enough >> with mesa-gl, this might make it worse). > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb That is, well, horrible. *If* we’re going to expose a mesa.inc that people outside of core can use to package up their own random Mesa SHA then mesa.inc should just be the packaging logic. However, I don’t understand something about the patch. Why do we only need to apply it on native builds? It’s a backport from upstream, so should be the fix. If it breaks when applied to target builds, is there a bug upstream for that? Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171970): https://lists.openembedded.org/g/openembedded-core/message/171970 Mute This Topic: https://lists.openembedded.org/mt/94420106/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 3/3] gnutls: Unified pakcage names to lower-case
On 19 Oct 2022, at 11:57, Keiya Nobuta via lists.openembedded.org wrote: > > create-spdx can't detect the license properly if the case doesn't > match, so fix it. This isn’t spdx-specific: nothing would have seen that package-specific license. Well spotted! Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171971): https://lists.openembedded.org/g/openembedded-core/message/171971 Mute This Topic: https://lists.openembedded.org/mt/94428130/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] getPatchedFiles in oe.patch doesn't correctly handle filenames with spaces
Hi All, by using Tinfoil together with methods found in oe.* to do software composition analysis, I encountered an error: when parsing python3 recipe, I found patch file [0001-gh-92036-Fix-gc_fini_untrack-GH-92037.patch](https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/0001-gh-92036-Fix-gc_fini_untrack-GH-92037.patch?h=kirkstone) which refers to a filename with spaces: +++ b/Misc/NEWS.d/next/Core and Builtins/2022-04-28-23-37-30.gh-issue-92036.GZJAC9.rst when using function oe.recipeutils.get_recipe_patched_files(d), the file above is returned as "b/Misc/NEWS.d/next/Core", missing the whole part after the space. The problem lies in [function patchedpath]((https://git.yoctoproject.org/poky/tree/meta/lib/oe/patch.py?h=kirkstone#n126) within the static method getPatchedFiles in poky/meta/lib/oe/patch.py, which assumes that there are no spaces in filenames filepth = patchline.split()[1] Even if spaces in filenames are bad practice, my understanding is that they are allowed by git diff and should be supported. To solve this issue, the above line may be modified as follows filepth = patchline[4:] Should I submit a patch for that? Regards, Alberto -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171972): https://lists.openembedded.org/g/openembedded-core/message/171972 Mute This Topic: https://lists.openembedded.org/mt/94434032/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] mesa: Add native patch via a variable
Khem, sorry but no. We have well defined mechanisms for reuse, and including bits and pieces of recipes from completely different layers is not one of them. I do not want to hear even more complaints about 'breaking' things than I already do when trying to make things better, simpler and more maintainable, and I do not want to be paralysed by fear of invisible breakage in custom layers when doing so. If you *really* want to make bits of mesa recipe 'public', put them in a bbclass. Alex On Wed, 19 Oct 2022 at 17:29, Ross Burton wrote: > > On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org > wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > wrote: > >> > >> Can you show examples where this is needed? Custom variable does not seem > >> a good idea. I also worry that it’ll break automated updates (it’s bad > >> enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > That is, well, horrible. > > *If* we’re going to expose a mesa.inc that people outside of core can use to > package up their own random Mesa SHA then mesa.inc should just be the > packaging logic. > > However, I don’t understand something about the patch. > > Why do we only need to apply it on native builds? It’s a backport from > upstream, so should be the fix. If it breaks when applied to target builds, > is there a bug upstream for that? > > Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171973): https://lists.openembedded.org/g/openembedded-core/message/171973 Mute This Topic: https://lists.openembedded.org/mt/94420106/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] mesa: Add native patch via a variable
On Wed, Oct 19, 2022 at 5:29 PM Ross Burton wrote: > On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org gmail@lists.openembedded.org> wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > wrote: > >> > >> Can you show examples where this is needed? Custom variable does not > seem a good idea. I also worry that it’ll break automated updates (it’s bad > enough with mesa-gl, this might make it worse). > > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > That is, well, horrible. > > *If* we’re going to expose a mesa.inc that people outside of core can use > to package up their own random Mesa SHA then mesa.inc should just be the > packaging logic. > Well I've seen many mesa/pulseaudio recipes which were using mesa.inc/pulseaudio.inc and even when they were a bit terrible, then it was still better than duplicating all of it. e.g. https://github.com/webOS-ports/meta-pine64-luneos/commits/8946d3e2350ae83fbb001ba640db59b207341481/recipes-graphics/mesa/mesa_%25.bbappend https://github.com/shr-project/meta-webosose/commits/master/meta-webos/recipes-multimedia/pulseaudio And better than some other recipes which start with "require recipes-foo/foos/foo_1.0.bb" and then set PV to 2.0 and do few other changes. I never expected .inc file to be _required_ wide range of possible versions, people who re-use it to build older or newer version need to deal with possible incompatibilities in their layer even if it sometimes might require whole .inc file to be imported into their layer, when the benefit of reusing it is much smaller than required modifications (e.g. when pulseaudio in oe-core was upgraded to use meson while our old version was still built with autotools or even this small change, but in :prepend https://git.openembedded.org/openembedded-core/commit/?id=e5399a09bf44700f97607b283379172dac0cf9c7 . > > However, I don’t understand something about the patch. > > Why do we only need to apply it on native builds? It’s a backport from > upstream, so should be the fix. If it breaks when applied to target > builds, is there a bug upstream for that? FWIW: I've reported that it breaks builds with DEBUG_BUILD instead of fixing them in: https://lists.openembedded.org/g/openembedded-core/message/169002 but Kai replied that it still works for him until it didn't which probably lead to this change to apply it only in master. I've reported the same in upstream MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439#note_1499443 but I didn't create new ticket about it (as it was supposed to work for others). Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171974): https://lists.openembedded.org/g/openembedded-core/message/171974 Mute This Topic: https://lists.openembedded.org/mt/94420106/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] getPatchedFiles in oe.patch doesn't correctly handle filenames with spaces
On 19 Oct 2022, at 16:40, Alberto Pianon via lists.openembedded.org wrote: > To solve this issue, the above line may be modified as follows > > filepth = patchline[4:] > > Should I submit a patch for that? Yes, but a better solution would be: filepth = pathline.split(maxsplit=1)[1] Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171975): https://lists.openembedded.org/g/openembedded-core/message/171975 Mute This Topic: https://lists.openembedded.org/mt/94434032/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] systemd: add systemd-creds and systemd-cryptenroll to systemd-extra-utils
From: Luca Boccassi
ERROR: systemd-1_251.4-r0 do_package: QA Issue: systemd: Files/directories were
installed but not shipped in any package:
/usr/bin/systemd-creds
/usr/bin/systemd-cryptenroll
Signed-off-by: Luca Boccassi
---
meta/recipes-core/systemd/systemd_251.4.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_251.4.bb
b/meta/recipes-core/systemd/systemd_251.4.bb
index 910ea71bf64..87668cadc75 100644
--- a/meta/recipes-core/systemd/systemd_251.4.bb
+++ b/meta/recipes-core/systemd/systemd_251.4.bb
@@ -518,6 +518,8 @@ FILES:${PN}-extra-utils = "\
${bindir}/systemd-path \
${bindir}/systemd-run \
${bindir}/systemd-cat \
+${bindir}/systemd-creds \
+${bindir}/systemd-cryptenroll \
${bindir}/systemd-delta \
${bindir}/systemd-cgls \
${bindir}/systemd-cgtop \
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171976):
https://lists.openembedded.org/g/openembedded-core/message/171976
Mute This Topic: https://lists.openembedded.org/mt/94437146/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: add usrmerge to REQUIRED_DISTRO_FEATURES
On Wed, 13 Jul 2022 at 00:30, Luca Boccassi wrote:
>
> On Tue, 12 Jul 2022 at 22:55, Richard Purdie
> wrote:
> >
> > On Tue, 2022-07-12 at 18:16 +0100, Luca Boccassi wrote:
> > > On Mon, 11 Jul 2022 at 23:06, Richard Purdie
> > > wrote:
> > > >
> > > > On Mon, 2022-07-11 at 21:29 +0100, Luca Bocassi wrote:
> > > > > From: Luca Boccassi
> > > > >
> > > > > Support for unmerged-usr is deprecated upstream, taints the system
> > > > > and will be
> > > > > removed in the near future.
> > > > > Enforce building merged-usr images when using systemd.
> > > > >
> > > > > Signed-off-by: Luca Boccassi
> > > > > ---
> > > > > We intend to deprecate unmerged-usr at some point, and we are doing
> > > > > the
> > > > > rounds ensuring distros are moving along so that there are no
> > > > > surprises
> > > > > when the time comes.
> > > > >
> > > > > See:
> > > > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html
> > > > >
> > > > > meta/recipes-core/systemd/systemd.inc | 5 +
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/meta/recipes-core/systemd/systemd.inc
> > > > > b/meta/recipes-core/systemd/systemd.inc
> > > > > index b8dbe2263a..f9e109bba4 100644
> > > > > --- a/meta/recipes-core/systemd/systemd.inc
> > > > > +++ b/meta/recipes-core/systemd/systemd.inc
> > > > > @@ -21,3 +21,8 @@ SRC_URI =
> > > > > "git://github.com/systemd/systemd-stable.git;protocol=https;branch=${S
> > > > > "
> > > > >
> > > > > S = "${WORKDIR}/git"
> > > > > +
> > > > > +# unmerged-usr support is deprecated upstream, taints the system and
> > > > > will be
> > > > > +# removed in the near future. Fail the build if it is not enabled.
> > > > > +inherit features_check
> > > > > +REQUIRED_DISTRO_FEATURES = "usrmerge"
> > > >
> > > > Given none of our systemd testing on the autobuilder is done under
> > > > usrmerge and we've never mentioned this requirement to any of our
> > > > userbase before, this is going to come as a bit of a surprise to
> > > > people. The above change will break the autobuilder as things stand :(.
> > >
> > > Yes I was expecting there would be these kind of issues, the purpose
> > > of sending this was mainly to find out about them.
> > > So where are these configurations stored? How can we get them updated?
> >
> > The configuration is yocto-autobuilder-helper but the best place to
> > start is probably the poky-altcfg distro config.
> >
> > Once we change that we'll have to run through the testing, see how much
> > breaks and then find someone to try and fix any issues if/as needed.
> > There is a lot of work just in pulling things together for testing and
> > triaging the result and I'm depressed it will probably end up on my
> > plate when I personally disagree with the decision.
>
> We've been running this configuration internally for ~3 years in our
> Yocto downstream, never seen any issue, not even at the beginning, it
> just worked.
> Nowadays most major distros have switched over, Gentoo's the other one
> left but it's planned for this year.
> Any issues in upstream softwares should have been fixed years ago when
> Fedora started the process.
> So hopefully it shouldn't be too bad?
>
> > I was asked earlier today if we should just make the systemd include
> > files force usrmerge on. The challenge is that OE/YP give users choice
> > to configure their system how they wish, we don't just force
> > configurations upon them. Or only real option is therefore to throw
> > errors and have them decide what to do (which basically amounts to
> > submitting to the upstream decision).
> >
> > > Also is a deprecation notification needed? How is it handled usually?
> >
> > Do we have time for such a notification or are we in the situation
> > where we just throw errors to the user and let them agree to the
> > usrmerge change? The timescale is unclear but if the systems are
> > already throwing deprecation warnings at runtime, this isn't a good
> > experience for our users.
>
> It's not urgent. But the build-time warning has been in place for a
> couple of years now, you should have already seen it.
> The runtime is a taint flag in 'systemctl status', and was introduced
> in the most recent release.
> There is no timeline as of now for dropping legacy compat code and
> configuration, as the runtime taint was just added.
> Certainly won't be this year. I've been doing the rounds ensuring
> everyone who hasn't switched already is aware with plenty of time to
> spare.
FYI, we now have a tentative timeline: first release of H2 2023 will
drop support for split-usr and unmerged-usr:
https://github.com/systemd/systemd/blob/v252-rc2/NEWS#L14
Kind regards,
Luca Boccassi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171977):
https://lists.openembedded.org/g/openembedded-core/message/171977
Mute This Topic: https://lists.openembedded.org/mt/92319509/21656
Group Owner: openembedded-core+ow...@lists.openembedde
Re: [OE-core][kirkstone][PATCH 2/2] tiff: backport fix for CVE-2022-2953
kirkstone now has tiff version 4.3.0.
As described in https://nvd.nist.gov/vuln/detail/CVE-2022-2953, this issue is
reported here: https://gitlab.com/libtiff/libtiff/-/issues/414
Tested with libtiff source code on version 4.3.0 by using " /libtiff$ git
checkout v3.3.0", and follow the step listed in the bug report, cannot
reproduce the bug.
Use " /libtiff$ git checkout b51bb157", is able to reproduce the problem
following step listed above. That confirms the issue occurred after v3.3.0, and
the commit that brings the bug is not on kirkstone, which means the issue/fix
is not applicable for kirkstone.
Zheng Qiu
Linux Developer
___
Wind River
M/ (437) 341-1849
>-Original Message-
>From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Teoh, Jay Shen
>Sent: Thursday, September 29, 2022 4:33 AM
>To: openembedded-core@lists.openembedded.org
>Subject: [OE-core][kirkstone][PATCH 2/2] tiff: backport fix for CVE-2022-2953
>
>[Please note: This e-mail is from an EXTERNAL e-mail address]
>
>From: Teoh Jay Shen
>
>Link for the patch : https://gitlab.com/libtiff/libtiff/-
>/commit/48d6ece8389b01129e7d357f0985c8f938ce3da3
>
>Signed-off-by: Teoh Jay Shen
>---
> .../libtiff/tiff/CVE-2022-2953.patch | 86 +++
> meta/recipes-multimedia/libtiff/tiff_4.4.0.bb | 1 +
> 2 files changed, 87 insertions(+)
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-
>2953.patch
>
>diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch
>b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch
>new file mode 100644
>index 00..2122b46566
>--- /dev/null
>+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-2953.patch
>@@ -0,0 +1,86 @@
>+CVE: CVE-2022-2953
>+Upstream-Status: Backport
>+Signed-off-by: Teoh Jay Shen
>+
>+From 8fe3735942ea1d90d8cef843b55b3efe8ab6feaf Mon Sep 17 00:00:00
>2001
>+From: Su_Laus
>+Date: Mon, 15 Aug 2022 22:11:03 +0200
>+Subject: [PATCH]
>+=?UTF-8?q?According=20to=20Richard=20Nolde=20https://gitl?=
>+
>+=?UTF-8?q?ab.com/libtiff/libtiff/-/issues/401#note=5F877637400=20the=20
>+ti?=
>+=?UTF-8?q?ffcrop=20option=20=E2=80=9E-
>S=E2=80=9C=20is=20also=20mutually
>+?=
>+=?UTF-8?q?=20exclusive=20to=20the=20other=20crop=20options=20(-X|-
>Y),=2
>+0-?=
>+ =?UTF-8?q?Z=20and=20-z.?=
>+MIME-Version: 1.0
>+Content-Type: text/plain; charset=UTF-8
>+Content-Transfer-Encoding: 8bit
>+
>+This is now checked and ends tiffcrop if those arguments are not mutually
>exclusive.
>+
>+This MR will fix the following tiffcrop issues: #349, #414, #422, #423,
>+#424
>+---
>+ tools/tiffcrop.c | 31 ---
>+ 1 file changed, 16 insertions(+), 15 deletions(-)
>+
>+diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c index
>+90286a5e..c3b758ec 100644
>+--- a/tools/tiffcrop.c
> b/tools/tiffcrop.c
>+@@ -173,12 +173,12 @@ static char tiffcrop_rev_date[] = "02-09-2022";
>+ #define ROTATECW_270 32
>+ #define ROTATE_ANY (ROTATECW_90 | ROTATECW_180 | ROTATECW_270)
>+
>+-#define CROP_NONE 0
>+-#define CROP_MARGINS 1
>+-#define CROP_WIDTH2
>+-#define CROP_LENGTH 4
>+-#define CROP_ZONES8
>+-#define CROP_REGIONS 16
>++#define CROP_NONE 0 /* "-S" -> Page_MODE_ROWSCOLS and page-
>>rows/->cols != 0 */
>++#define CROP_MARGINS 1 /* "-m" */
>++#define CROP_WIDTH2 /* "-X" */
>++#define CROP_LENGTH 4 /* "-Y" */
>++#define CROP_ZONES8 /* "-Z" */
>++#define CROP_REGIONS 16 /* "-z" */
>+ #define CROP_ROTATE 32
>+ #define CROP_MIRROR 64
>+ #define CROP_INVERT 128
>+@@ -316,7 +316,7 @@ struct crop_mask {
>+ #define PAGE_MODE_RESOLUTION 1
>+ #define PAGE_MODE_PAPERSIZE2
>+ #define PAGE_MODE_MARGINS 4
>+-#define PAGE_MODE_ROWSCOLS 8
>++#define PAGE_MODE_ROWSCOLS 8/* for -S option */
>+
>+ #define INVERT_DATA_ONLY 10
>+ #define INVERT_DATA_AND_TAG 11
>+@@ -781,7 +781,7 @@ static const char usage_info[] =
>+ " The four debug/dump options are independent, though it makes
>little sense to\n"
>+ " specify a dump file without specifying a detail level.\n"
>+ "\n"
>+-"Note:The (-X|-Y), -Z and -z options are mutually exclusive.\n"
>++"Note:The (-X|-Y), -Z, -z and -S options are mutually exclusive.\n"
>+ " In no case should the options be applied to a given selection
>successively.\n"
>+ "\n"
>+ ;
>+@@ -2131,13 +2131,14 @@ void process_command_opts (int argc, char
>*argv[], char *mp, char *mode, uint32
>+ /*NOTREACHED*/
>+ }
>+ }
>+-/*-- Check for not allowed combinations (e.g. -X, -Y and -Z and -z are
>mutually exclusive) --*/
>+-char XY, Z, R;
>++/*-- Check for not allowed combinations (e.g. -X, -Y and -Z, -z and -S
>are
>mutually exclusive) --*/
>++char XY, Z, R, S;
>+ XY = ((crop_data->crop_mode & CROP_WIDTH) || (crop_data-
>>crop_mode & CROP_LENGTH));
>+ Z = (crop_data->crop_mode & CROP_ZONES);
>+ R = (crop_data->crop_mode & CROP_REGIONS);
[OE-core] [PATCH] populate_sdk_base: ensure ptest-pkgs pulls in ptest-runner
Since "package_manager: Change complementary package handling to not include soft dependencies"[1], complementary packages don't pull in recommendations, just depends. However, ptest.bbclass has a recommends on ptest-runner, so if ptest packages are in an image via the ptest-pkgs IMAGE_FEATURE, ptest-runner doesn't get installed. [ YOCTO #14928 ] [1] oe-core b44b0b9294675f89aa51ff84f532664f4c479677 Signed-off-by: Ross Burton --- meta/classes-recipe/populate_sdk_base.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes-recipe/populate_sdk_base.bbclass b/meta/classes-recipe/populate_sdk_base.bbclass index 0be108ad98e..64a4a58beff 100644 --- a/meta/classes-recipe/populate_sdk_base.bbclass +++ b/meta/classes-recipe/populate_sdk_base.bbclass @@ -15,7 +15,7 @@ COMPLEMENTARY_GLOB[staticdev-pkgs] = '*-staticdev' COMPLEMENTARY_GLOB[doc-pkgs] = '*-doc' COMPLEMENTARY_GLOB[dbg-pkgs] = '*-dbg' COMPLEMENTARY_GLOB[src-pkgs] = '*-src' -COMPLEMENTARY_GLOB[ptest-pkgs] = '*-ptest' +COMPLEMENTARY_GLOB[ptest-pkgs] = '*-ptest ptest-runner' COMPLEMENTARY_GLOB[bash-completion-pkgs] = '*-bash-completion' def complementary_globs(featurevar, d): -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171979): https://lists.openembedded.org/g/openembedded-core/message/171979 Mute This Topic: https://lists.openembedded.org/mt/94440433/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] externalsrc: move back to classes
The externalsrc class was moved to classes-recipe as part of oe-core
f5c1280, but it can be used in both recipe and global contexts so move
it back to classes/.
Signed-off-by: Ross Burton
---
meta/{classes-recipe => classes}/externalsrc.bbclass | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta/{classes-recipe => classes}/externalsrc.bbclass (100%)
diff --git a/meta/classes-recipe/externalsrc.bbclass
b/meta/classes/externalsrc.bbclass
similarity index 100%
rename from meta/classes-recipe/externalsrc.bbclass
rename to meta/classes/externalsrc.bbclass
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171980):
https://lists.openembedded.org/g/openembedded-core/message/171980
Mute This Topic: https://lists.openembedded.org/mt/94440439/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] scripts/oe-check-sstate: cleanup
The scriptutils import isn't used, there's no need to run bitbake
in a shell environment, and invoke bitbake as a list instead of a
string.
Signed-off-by: Ross Burton
---
scripts/oe-check-sstate | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/scripts/oe-check-sstate b/scripts/oe-check-sstate
index f4cc5869de4..7f9f835da4c 100755
--- a/scripts/oe-check-sstate
+++ b/scripts/oe-check-sstate
@@ -18,7 +18,6 @@ import re
scripts_path = os.path.dirname(os.path.realpath(__file__))
lib_path = scripts_path + '/lib'
sys.path = sys.path + [lib_path]
-import scriptutils
import scriptpath
scriptpath.add_bitbake_lib_path()
import argparse_oe
@@ -51,11 +50,8 @@ def check(args):
env['TMPDIR:forcevariable'] = tmpdir
try:
-output = subprocess.check_output(
-'bitbake -n %s' % ' '.join(args.target),
-stderr=subprocess.STDOUT,
-env=env,
-shell=True)
+cmd = ['bitbake', '--dry-run'] + args.target
+output = subprocess.check_output(cmd, stderr=subprocess.STDOUT,
env=env)
task_re = re.compile('NOTE: Running setscene task [0-9]+ of [0-9]+
\(([^)]+)\)')
tasks = []
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171981):
https://lists.openembedded.org/g/openembedded-core/message/171981
Mute This Topic: https://lists.openembedded.org/mt/94440450/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] scripts/oe-check-sstate: force build to run for all targets, specifically populate_sysroot
Since the commit "populate_sdk_base/images: Drop use of 'meta' class and
hence do_build dependencies"[1], builds of images or SDKs don't
recursively depend on the top-level do_build target. This is typically
a good thing: images just depend on the packages themselves and those
dependencies already exist, but they don't need each recipes sysroot to
be populated.
However, eSDK generation is partly done via the script oe-check-sstate,
which does a 'dry-run' build of the target and collates all of the
sstate that is used. With this commit the sstate that is used is a
fraction of what would be needed in the SDK, specifically there are no
sysroots populated during the build, so there are no sysroots in the
SDK.
This is obviously a problem, as the entire point of an eSDK is to
contain a sysroot. Resolve this problem by forcing bitbake to run the
build task for all targets, so that all potentially needed sstate is
collated.
[YOCTO #14626]
[1]
https://github.com/openembedded/openembedded-core/commit/41d7f1aa2cc9ef5dba4db38435402d4c9c0a63e1
Tested-by: Andrej Valek
Signed-off-by: Ross Burton
---
scripts/oe-check-sstate | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/oe-check-sstate b/scripts/oe-check-sstate
index 7f9f835da4c..4187e774581 100755
--- a/scripts/oe-check-sstate
+++ b/scripts/oe-check-sstate
@@ -50,7 +50,7 @@ def check(args):
env['TMPDIR:forcevariable'] = tmpdir
try:
-cmd = ['bitbake', '--dry-run'] + args.target
+cmd = ['bitbake', '--dry-run', '--runall=build'] + args.target
output = subprocess.check_output(cmd, stderr=subprocess.STDOUT,
env=env)
task_re = re.compile('NOTE: Running setscene task [0-9]+ of [0-9]+
\(([^)]+)\)')
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171982):
https://lists.openembedded.org/g/openembedded-core/message/171982
Mute This Topic: https://lists.openembedded.org/mt/94440451/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone][PATCH 2/2] tiff: backport fix for CVE-2022-2953
On 2022-10-19 15:32, Qiu, Zheng wrote: kirkstone now has tiff version 4.3.0. As described in https://nvd.nist.gov/vuln/detail/CVE-2022-2953, this issue is reported here: https://gitlab.com/libtiff/libtiff/-/issues/414 Tested with libtiff source code on version 4.3.0 by using " /libtiff$ git checkout v3.3.0", and follow the step listed in the bug report, cannot reproduce the bug. Use " /libtiff$ git checkout b51bb157", is able to reproduce the problem following step listed above. That confirms the issue occurred after v3.3.0, and the commit that brings the bug is not on kirkstone, which means the issue/fix is not applicable for kirkstone. Hold on... We also checked, because I'm paranoid, by doing: $ cd .../poky-contrib.git $ git checkout stable/kirkstone-nut $ git pull $ cd ... $ . ../poky-contrib.git/tiff-patches $ bitbake -c patch tiff $ mkdir cp-tiff-patch-by-bb-kirkstone-nut $ cp -a tmp/work/core2-64-poky-linux/tiff/4.3.0-r0 cp-tiff-patch-by-bb-kirkstone-nut/ $ cd cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0 $ ./autogen.sh $ CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" ./configure --prefix=$PWD/build_asan --disable-shared $ make -j; make install; make clean $ wget https://gitlab.com/libtiff/libtiff/uploads/54e5139c4d9d6b740f537c691aad2b03/poc $ ./build_asan/bin/tiffcrop -Z 1:4,3:3 -R 90 -H 300 -S 2:2 -i poc /tmp/foo and a very similar issue still occurs. See log below. We'll investigate more and send a patch as needed. We will enable the address sanitizer and check if the issue is reproducible in qemux86-64. ../Randy ... loadImage: Image lacks Photometric interpretation tag. TIFFFillStrip: Read error on strip 0; got 672 bytes, expected 1142418. = ==269609==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd1864ff695 at pc 0x55de6ca63f9a bp 0x7ffe727049a0 sp 0x7ffe72704990 READ of size 1 at 0x7fd1864ff695 thread T0 #0 0x55de6ca63f99 in extractImageSection /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:6897 #1 0x55de6ca6515a in writeImageSections /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:7085 #2 0x55de6ca4abe9 in main /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:2453 #3 0x7fd189b39d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #4 0x7fd189b39e3f in __libc_start_main_impl ../csu/libc-start.c:392 #5 0x55de6ca413a4 in _start (/media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/build_asan/bin/tiffcrop+0x2a3a4) 0x7fd1864ff695 is located 0 bytes to the right of 1142421-byte region [0x7fd1863e8800,0x7fd1864ff695) allocated by thread T0 here: #0 0x7fd18a0a1867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x55de6cadcd83 in _TIFFmalloc /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/libtiff/tif_unix.c:314 #2 0x55de6ca41543 in limitMalloc /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:627 #3 0x55de6ca61299 in loadImage /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:6212 #4 0x55de6ca4a4a1 in main /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:2376 #5 0x7fd189b39d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-buffer-overflow /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:6897 in extractImageSection Shadow bytes around the buggy address: 0x0ffab0c97e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffab0c97e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffab0c97ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffab0c97eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffab0c97ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ffab0c97ed0: 00 00[05]fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ffab0c97ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ffab0c97ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ffab0c97f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ffab0c97f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ffab0c97f20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 applicat
Re: [OE-core] [PATCH 2/3] create-spdx: Fix "licenseDeclared" shows weird value
On Wed, Oct 19, 2022 at 6:08 AM Keiya Nobuta wrote:
>
> Fixed an issue that "licenseDeclared" shows weird value, for example
> `busybox.spdx.json` shows like:
>
> "GPL-2.0-only AND DocumentRef-recipe-busybox:LicenseRef-bzip2-1.0.4"
> ^^^
>unwanted value
I don't believe this is unwanted: the license text lives in another
document (ecipe-busybox.spdx.json) so we need to indicate that here
>
> Signed-off-by: Keiya Nobuta
> ---
> meta/classes/create-spdx.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/create-spdx.bbclass
> b/meta/classes/create-spdx.bbclass
> index c190ad3889..1661c7d2f0 100644
> --- a/meta/classes/create-spdx.bbclass
> +++ b/meta/classes/create-spdx.bbclass
> @@ -534,7 +534,7 @@ python do_create_spdx() {
> recipe_ref.checksum.checksumValue = doc_sha1
>
> sources = collect_dep_sources(d, dep_recipes)
> -found_licenses = {license.name:recipe_ref.externalDocumentId + ":" +
> license.licenseId for license in doc.hasExtractedLicensingInfos}
> +found_licenses = {license.name: license.licenseId for license in
> doc.hasExtractedLicensingInfos}
>
> if not recipe_spdx_is_native(d, recipe):
> bb.build.exec_func("read_subpackage_metadata", d)
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171984):
https://lists.openembedded.org/g/openembedded-core/message/171984
Mute This Topic: https://lists.openembedded.org/mt/94428131/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][kirkstone][PATCH 2/2] tiff: backport fix for CVE-2022-2953
On Wed, Oct 19, 2022 at 11:07 AM Randy MacLeod wrote: > > On 2022-10-19 15:32, Qiu, Zheng wrote: > > kirkstone now has tiff version 4.3.0. > > > > As described in https://nvd.nist.gov/vuln/detail/CVE-2022-2953, this issue > > is reported here: https://gitlab.com/libtiff/libtiff/-/issues/414 > > > > Tested with libtiff source code on version 4.3.0 by using " /libtiff$ git > > checkout v3.3.0", and follow the step listed in the bug report, cannot > > reproduce the bug. > > > > Use " /libtiff$ git checkout b51bb157", is able to reproduce the problem > > following step listed above. That confirms the issue occurred after v3.3.0, > > and the commit that brings the bug is not on kirkstone, which means the > > issue/fix is not applicable for kirkstone. > > Hold on... > > We also checked, because I'm paranoid, by doing: > > $ cd .../poky-contrib.git > $ git checkout stable/kirkstone-nut > $ git pull > $ cd ... > $ . ../poky-contrib.git/tiff-patches > $ bitbake -c patch tiff > > $ mkdir cp-tiff-patch-by-bb-kirkstone-nut > $ cp -a tmp/work/core2-64-poky-linux/tiff/4.3.0-r0 > cp-tiff-patch-by-bb-kirkstone-nut/ > $ cd cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0 > $ ./autogen.sh > $ CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="-g > -fsanitize=address -fno-omit-frame-pointer" ./configure > --prefix=$PWD/build_asan --disable-shared > $ make -j; make install; make clean > $ wget > https://gitlab.com/libtiff/libtiff/uploads/54e5139c4d9d6b740f537c691aad2b03/poc > $ ./build_asan/bin/tiffcrop -Z 1:4,3:3 -R 90 -H 300 -S 2:2 -i poc /tmp/foo > > and a very similar issue still occurs. > > See log below. We'll investigate more and send a patch as needed. Thanks Randy. I'm pretty sure I didn't take the referenced patch because it was for a version of tiff not in kirkstone. But I don't see an email from me explaining why, so my bad :-( I usually try to give feedback when a patch isn't taken. Steve > > We will enable the address sanitizer and check if the issue > is reproducible in qemux86-64. > > ../Randy > > > ... > > loadImage: Image lacks Photometric interpretation tag. > TIFFFillStrip: Read error on strip 0; got 672 bytes, expected 1142418. > = > ==269609==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x7fd1864ff695 at pc 0x55de6ca63f9a bp 0x7ffe727049a0 sp 0x7ffe72704990 > READ of size 1 at 0x7fd1864ff695 thread T0 > #0 0x55de6ca63f99 in extractImageSection > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:6897 > #1 0x55de6ca6515a in writeImageSections > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:7085 > #2 0x55de6ca4abe9 in main > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:2453 > #3 0x7fd189b39d8f in __libc_start_call_main > ../sysdeps/nptl/libc_start_call_main.h:58 > #4 0x7fd189b39e3f in __libc_start_main_impl ../csu/libc-start.c:392 > #5 0x55de6ca413a4 in _start > (/media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/build_asan/bin/tiffcrop+0x2a3a4) > > 0x7fd1864ff695 is located 0 bytes to the right of 1142421-byte region > [0x7fd1863e8800,0x7fd1864ff695) > allocated by thread T0 here: > #0 0x7fd18a0a1867 in __interceptor_malloc > ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x55de6cadcd83 in _TIFFmalloc > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/libtiff/tif_unix.c:314 > #2 0x55de6ca41543 in limitMalloc > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:627 > #3 0x55de6ca61299 in loadImage > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:6212 > #4 0x55de6ca4a4a1 in main > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:2376 > #5 0x7fd189b39d8f in __libc_start_call_main > ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: heap-buffer-overflow > /media/rmacleod/gitter/rmacleod/src/distro/yocto/b/tiff-patches/cp-tiff-patch-by-bb-kirkstone-nut/4.3.0-r0/tiff-4.3.0/tools/tiffcrop.c:6897 > in extractImageSection > Shadow bytes around the buggy address: >0x0ffab0c97e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >0x0ffab0c97e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >0x0ffab0c97ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >0x0ffab0c97eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >0x0ffab0c97ec0: 00 00 0
Re: [OE-core] [PATCH] kbd: package some fonts as restricted
On 2022-10-18 06:25, Ross Burton wrote: On 18 Oct 2022, at 01:14, Randy MacLeod via lists.openembedded.org wrote: The distribution terms of the Agafari fonts as described in data/consolefonts/README.Ethiopic is: Agafari: Donated by the Ethiopian Science and Technology Commission or and may be redistributed for non-commercial use under Unix environments only. so package them seperately to make it easier for affected users to avoid installing the fonts. Looks like you need special per-package LICENSE variables set to people can identify this programatically. Indeed. v2 will show up at some point, maybe even this week. ../Randy Ross -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171986): https://lists.openembedded.org/g/openembedded-core/message/171986 Mute This Topic: https://lists.openembedded.org/mt/94398712/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 2/3] create-spdx: Fix "licenseDeclared" shows weird value
On Thu, Oct 20, 2022 at 06:17 AM, Joshua Watt wrote:
>
> On Wed, Oct 19, 2022 at 6:08 AM Keiya Nobuta
> wrote:
>
>> Fixed an issue that "licenseDeclared" shows weird value, for example
>> `busybox.spdx.json` shows like:
>>
>> "GPL-2.0-only AND DocumentRef-recipe-busybox:LicenseRef-bzip2-1.0.4"
>> ^^^
>> unwanted value
>
> I don't believe this is unwanted: the license text lives in another
> document (ecipe-busybox.spdx.json) so we need to indicate that here
Thanks for your comment.
I was misunderstanding, so I'm withdrawing this patch.
The reason I got it wrong was because the SPDX validation tool[1]
gave me the following message:
```
The following warning(s) were raised: [Invalid package
declared license:Incompatible type for property member: class
org.spdx.library.model.license.AnyLicenseInfo]
```
But this is probably due to a flaw in the validation tool. So I checked the
SPDX specification[2], and understood that it complies with the user defined
license reference.
[1] https://tools.spdx.org/app/validate/
[2] https://spdx.github.io/spdx-spec/SPDX-license-expressions/
>
>
>> Signed-off-by: Keiya Nobuta
>> ---
>> meta/classes/create-spdx.bbclass | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/create-spdx.bbclass
>> b/meta/classes/create-spdx.bbclass
>> index c190ad3889..1661c7d2f0 100644
>> --- a/meta/classes/create-spdx.bbclass
>> +++ b/meta/classes/create-spdx.bbclass
>> @@ -534,7 +534,7 @@ python do_create_spdx() {
>> recipe_ref.checksum.checksumValue = doc_sha1
>>
>> sources = collect_dep_sources(d, dep_recipes)
>> - found_licenses = {license.name:recipe_ref.externalDocumentId + ":" +
>> license.licenseId for license in doc.hasExtractedLicensingInfos}
>> + found_licenses = {license.name: license.licenseId for license in
>> doc.hasExtractedLicensingInfos}
>>
>> if not recipe_spdx_is_native(d, recipe):
>> bb.build.exec_func("read_subpackage_metadata", d)
>> --
>> 2.25.1
>>
>>
>>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171987):
https://lists.openembedded.org/g/openembedded-core/message/171987
Mute This Topic: https://lists.openembedded.org/mt/94428131/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][langdale][kirkstone][PATCH] openssl: CVE-2022-3358 Using a Custom Cipher with NID_undef may lead to NULL encryption
Upstream-Status: Backport from
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5485c56679d7c49b96e8fc8ca708b0b7e7c03c4b]
Description:
CVE-2022-3358 openssl: Using a Custom Cipher with NID_undef may lead to
NULL encryption.
Affects "openssl < 3.0.6"
Signed-off-by: Hitendra Prajapati
---
.../openssl/openssl/CVE-2022-3358.patch | 55 +++
.../openssl/openssl_3.0.5.bb | 1 +
2 files changed, 56 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl/CVE-2022-3358.patch
diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2022-3358.patch
b/meta/recipes-connectivity/openssl/openssl/CVE-2022-3358.patch
new file mode 100644
index 00..18b2a5a6b2
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/CVE-2022-3358.patch
@@ -0,0 +1,55 @@
+From 56e1d693f0ec5550a8e3dd52d30e57a02f0287af Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Wed, 19 Oct 2022 11:08:23 +0530
+Subject: [PATCH] CVE-2022-3358
+
+Upstream-Status: Backport
[https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5485c56679d7c49b96e8fc8ca708b0b7e7c03c4b]
+CVE : CVE-2022-3358
+Signed-off-by: Hitendra Prajapati
+---
+ crypto/evp/digest.c | 4 +++-
+ crypto/evp/evp_enc.c | 6 --
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/crypto/evp/digest.c b/crypto/evp/digest.c
+index de9a1dc..e6e03ea 100644
+--- a/crypto/evp/digest.c
b/crypto/evp/digest.c
+@@ -225,7 +225,9 @@ static int evp_md_init_internal(EVP_MD_CTX *ctx, const
EVP_MD *type,
+ || tmpimpl != NULL
+ #endif
+ || (ctx->flags & EVP_MD_CTX_FLAG_NO_INIT) != 0
+-|| type->origin == EVP_ORIG_METH) {
++|| (type != NULL && type->origin == EVP_ORIG_METH)
++|| (type == NULL && ctx->digest != NULL
++ && ctx->digest->origin == EVP_ORIG_METH)) {
+ if (ctx->digest == ctx->fetched_digest)
+ ctx->digest = NULL;
+ EVP_MD_free(ctx->fetched_digest);
+diff --git a/crypto/evp/evp_enc.c b/crypto/evp/evp_enc.c
+index 19a07de..5df08bd 100644
+--- a/crypto/evp/evp_enc.c
b/crypto/evp/evp_enc.c
+@@ -131,7 +131,10 @@ static int evp_cipher_init_internal(EVP_CIPHER_CTX *ctx,
+ #if !defined(OPENSSL_NO_ENGINE) && !defined(FIPS_MODULE)
+ || tmpimpl != NULL
+ #endif
+-|| impl != NULL) {
++|| impl != NULL
++|| (cipher != NULL && cipher->origin == EVP_ORIG_METH)
++|| (cipher == NULL && ctx->cipher != NULL
++ && ctx->cipher->origin == EVP_ORIG_METH)) {
+ if (ctx->cipher == ctx->fetched_cipher)
+ ctx->cipher = NULL;
+ EVP_CIPHER_free(ctx->fetched_cipher);
+@@ -147,7 +150,6 @@ static int evp_cipher_init_internal(EVP_CIPHER_CTX *ctx,
+ ctx->cipher_data = NULL;
+ }
+
+-
+ /* Start of non-legacy code below */
+
+ /* Ensure a context left lying around from last time is cleared */
+--
+2.25.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
b/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
index e50ff7f8c5..ee051ee7d4 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
@@ -12,6 +12,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz
\
file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://afalg.patch \
file://0001-Configure-do-not-tweak-mips-cflags.patch \
+ file://CVE-2022-3358.patch \
"
SRC_URI:append:class-nativesdk = " \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171988):
https://lists.openembedded.org/g/openembedded-core/message/171988
Mute This Topic: https://lists.openembedded.org/mt/94447529/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
