Re: [OE-core] How to properly enable PAM integration - docs no longer valid?

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Carlos Rafael Giani via
> lists.openembedded.org
> Sent: den 29 januari 2022 05:19
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] How to properly enable PAM integration - docs no longer
> valid?
> 
> According to this document:
> 
>    https://wiki.yoctoproject.org/wiki/PAM_Integration
> 
> PAM can be enabled by adding this line to local.conf:
> 
>    DISTRO_FEATURES_append += " pam"
> 
> In newer Yocto versions, this would be:
> 
>    DISTRO_FEATURES:append += " pam"
> 
> and this works. I *had* to use "+=" instead of "=" here, otherwise pam
> would not be added correctly.
> 
> But, then I get this warning:
> 
>    WARNING: DISTRO_FEATURES:append += is not a recommended operator
> combination, please replace it
> 
> So, how am I supposed to enable PAM in local.conf if I need to enable it
> quickly for a test by using poky and can't set up my own distro right now?

The correct form is:

DISTRO_FEATURES:append = " pam"

There should be no reason to use += above (which is also why it now 
generates a warning if you do).

You can always check the value of a variable and how it got defined by 
using `bitbake -e`, or the new bitbake-getvar, e.g., `bitbake-getvar 
DISTRO_FEATURES`.

//Peter


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

[OE-core] How to properly enable PAM integration - docs no longer valid?

[Carlos Rafael Giani via lists.openembedded.org]

According to this document:

  https://wiki.yoctoproject.org/wiki/PAM_Integration

PAM can be enabled by adding this line to local.conf:

  DISTRO_FEATURES_append += " pam"

In newer Yocto versions, this would be:

  DISTRO_FEATURES:append += " pam"

and this works. I *had* to use "+=" instead of "=" here, otherwise pam 
would not be added correctly.


But, then I get this warning:

  WARNING: DISTRO_FEATURES:append += is not a recommended operator 
combination, please replace it


So, how am I supposed to enable PAM in local.conf if I need to enable it 
quickly for a test by using poky and can't set up my own distro right now?



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161097): 
https://lists.openembedded.org/g/openembedded-core/message/161097
Mute This Topic: https://lists.openembedded.org/mt/88761315/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] [oe] Inclusive Language Proposal for YP/OE

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-de...@lists.openembedded.org  de...@lists.openembedded.org> On Behalf Of Jon Mason
> Sent: den 24 januari 2022 17:18
> To: yo...@lists.yoctoproject.org; Patches and discussions about the oe-
> core layer ; OpenEmbedded Devel
> List 
> Subject: [oe] Inclusive Language Proposal for YP/OE

[cut]

> For license handling, we’d use the opportunity to clean up the
> WHITELIST_(ANY LICENSE) syntax and replace it with a
> INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of 
> recipes which are of a blocked the INCOMPATIBLE_LICENSE list.

I am not so sure about this name. Not only is it extremely long, 
but at least I would like to revise the entire system of how 
licenses are handled. The major reason for this is that our 
legal department requires us to have a list of allowed licenses 
rather than a list of disallowed licenses. Thus we have a 
COMPATIBLE_LICENSES variable. We then set INCOMPATIBLE_LICENSE 
to AVAILABLE_LICENSES - COMPATIBLE_LICENSES. However, after the 
introduction of all official SPDX licenses into OE-Core a while 
ago this became problematic as the current implementation will 
go through all licenses specified in INCOMPATIBLE_LICENSE many, 
many times during recipe parsing, which caused the time to parse 
all recipes to increase three times for us. Thus I would like to 
implement proper support for COMPATIBLE_LICENSES in addition to 
the INCOMPATIABLE_LICENSE variable to allow choosing the option 
that suits the situation best.

However, in either case there would still need to be a way to 
specify exceptions to the incompatible licenses, which is why I 
would prefer that the name is not locked to the 
INCOMPATIBLE_LICENSE variable. Here are a couple of alternatives:

* LICENSE_EXCEPTIONS
* ALLOWED_RECIPES
* LICENSE_ALLOWED_RECIPES

It is also that the WHITELIST variables have two use cases today, 
one is to allow a _recipe_ to be built and the other is to allow 
a _package_ to be added to an image even if it has an incompatible 
license. The first use case can just as easily be achieved by 
setting INCOMPATIBLE_LICENSE:pn-foo = "" for a recipe foo that 
shall be allowed to be built even if it has an incompatible 
license. With this in mind, maybe the variable should actually be 
an image variable and specify a list of allowed packages instead, 
e.g., IMAGE_ALLOWED_PACKAGES. Whether the variable with a list of 
allowed recipes is then still needed or if it is enough to 
manipulate INCOMPATIBLE_LICENSE as per above can be discussed.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161096): 
https://lists.openembedded.org/g/openembedded-core/message/161096
Mute This Topic: https://lists.openembedded.org/mt/88760881/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] [hardknott][PATCH] pigz: fix one failure of command "unpigz -l"

[Changqing Li]

Hi, Richard

Could you help to merge this also to hardknott branch? Thanks.

On 1/17/22 4:11 PM, Changqing Li wrote:

From: Changqing Li 

Refer [1], "unpigz -l" failed with error:
$ ./unpigz -l test.txt.gz
compressed original reduced name
228799 209715200 99.9% test.txt
unpigz: can't destroy locked resource (pigz.c:2622:mutex_destroy)
unpigz: abort: internal threads error

or

$ ./unpigz -l test.txt.gz
unpigz: skipping: test.txt.gz unrecognized format
unpigz: can't destroy locked resource (pigz.c:2622:mutex_destroy)
unpigz: abort: internal threads error

[1] https://github.com/madler/pigz/issues/96

Signed-off-by: Changqing Li 
---
  ...0001-Fix-bug-when-combining-l-with-d.patch | 50 +++
  meta/recipes-extended/pigz/pigz_2.6.bb|  3 +-
  2 files changed, 52 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/pigz/files/0001-Fix-bug-when-combining-l-with-d.patch

diff --git 
a/meta/recipes-extended/pigz/files/0001-Fix-bug-when-combining-l-with-d.patch 
b/meta/recipes-extended/pigz/files/0001-Fix-bug-when-combining-l-with-d.patch
new file mode 100644
index 00..9c301f2054
--- /dev/null
+++ 
b/meta/recipes-extended/pigz/files/0001-Fix-bug-when-combining-l-with-d.patch
@@ -0,0 +1,50 @@
+From 65986f3d12d434b9bc428ceb6fcb1f6eeeb2c47d Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Mon, 17 Jan 2022 15:36:56 +0800
+Subject: [PATCH] Fix bug when combining -l with -d.
+
+Though it makes no sense to do pigz -ld, that is implicit when
+doing unpigz -l. This commit fixes a bug for that combination.
+
+Upstream-Status: Backport 
[https://github.com/madler/pigz/commit/326bba44aa102c707dd6ebcd2fc3f413b3119db0]
+
+Signed-off-by: Changqing Li 
+---
+ pigz.c | 14 +++---
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/pigz.c b/pigz.c
+index f90157f..d648216 100644
+--- a/pigz.c
 b/pigz.c
+@@ -4007,6 +4007,13 @@ local void process(char *path) {
+ }
+ SET_BINARY_MODE(g.ind);
+
++// if requested, just list information about the input file
++if (g.list && g.decode != 2) {
++list_info();
++load_end();
++return;
++}
++
+ // if decoding or testing, try to read gzip header
+ if (g.decode) {
+ in_init();
+@@ -4048,13 +4055,6 @@ local void process(char *path) {
+ }
+ }
+
+-// if requested, just list information about input file
+-if (g.list) {
+-list_info();
+-load_end();
+-return;
+-}
+-
+ // create output file out, descriptor outd
+ if (path == NULL || g.pipeout) {
+ // write to stdout
+--
+2.17.1
+
diff --git a/meta/recipes-extended/pigz/pigz_2.6.bb 
b/meta/recipes-extended/pigz/pigz_2.6.bb
index 05be9b733f..5c0aab55a7 100644
--- a/meta/recipes-extended/pigz/pigz_2.6.bb
+++ b/meta/recipes-extended/pigz/pigz_2.6.bb
@@ -8,7 +8,8 @@ SECTION = "console/utils"
  LICENSE = "Zlib & Apache-2.0"
  LIC_FILES_CHKSUM = 
"file://pigz.c;md5=9ae6dee8ceba9610596ed0ada493d142;beginline=7;endline=21"
  
-SRC_URI = "http://zlib.net/${BPN}/fossils/${BP}.tar.gz;

+SRC_URI = "http://zlib.net/${BPN}/fossils/${BP}.tar.gz \
+   file://0001-Fix-bug-when-combining-l-with-d.patch"
  SRC_URI[sha256sum] = 
"2eed7b0d7449d1d70903f2a62cd6005d262eb3a8c9e98687bc8cbb5809db2a7d"
  PROVIDES_class-native += "gzip-native"
  





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

Re: [OE-core] [PATCH] Revert "featimage: refactor style"

[Marek Vasut]

On 1/29/22 03:01, Peter Kjellerstedt wrote:

Hi,

[...]


Personally I do not see it as inconsistent, it is just the way
shell handles variables. It is just something to get used to (I
also had a colleague who would review any shell code changes we
made and comment on every single unnecessary character so one
quickly learned to use $foo everywhere possible rather than
${foo}...)


On the other hand, once you get burnt ${foo}bar / $foobar , you might 
quickly start putting the {} everywhere. That's my case.


(we should likely stop this ^ discussion thread before it turns into a 
flamewar)



That said, I have never looked at this code so I
have no real idea of how bad it is or isn't.


This patch lists pretty much all the vars, so you can get a pretty 
decent idea from just looking at that.



third alternative ? I mean, besides rewriting the fitimage
generation into python, which might make it more flexible too.


Replacing shell code that has grown beyond a couple of hundred
(tens?) lines with something written in a better language is
almost always a good idea.


It's grown to almost 800 LoC, so maybe it is time to reevaluate the 
python conversion then.

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

[OE-core] [PATCH 2/2] sstatetests: Correct a typo in a comment

[Peter Kjellerstedt]

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oeqa/selftest/cases/sstatetests.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 96b2d115ed..3038b40021 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -177,7 +177,7 @@ class SStateTests(SStateBase):
 # QA checks for this test. It may report errors otherwise.
 self.append_config('ERROR_QA:remove = "version-going-backwards"')
 
-# For not this only checks if random sstate tasks are handled 
correctly as a group.
+# For now this only checks if random sstate tasks are handled 
correctly as a group.
 # In the future we should add control over what tasks we check for.
 
 sstate_archs_list = []

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161093): 
https://lists.openembedded.org/g/openembedded-core/message/161093
Mute This Topic: https://lists.openembedded.org/mt/88760241/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] devtool: sdk-update: Remove an unnecessary \n from SSTATE_MIRRORS

[Peter Kjellerstedt]

Since commit 044fb04d in bitbake (fetch2: Allow whitespace only mirror
entries) there is no need to separate the entries in SSTATE_MIRRORS
with "\n".

Signed-off-by: Peter Kjellerstedt 
---
 scripts/lib/devtool/sdk.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index ae3fc4caf9..d717b6c2b8 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -207,7 +207,7 @@ def sdk_update(args, config, basepath, workspace):
 if not sstate_mirrors:
 with open(os.path.join(conf_dir, 'site.conf'), 'a') as f:
 f.write('SCONF_VERSION = "%s"\n' % site_conf_version)
-f.write('SSTATE_MIRRORS:append = " file://.* 
%s/sstate-cache/PATH \\n "\n' % updateserver)
+f.write('SSTATE_MIRRORS:append = " file://.* 
%s/sstate-cache/PATH"\n' % updateserver)
 finally:
 shutil.rmtree(tmpsdk_dir)
 

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

Re: [OE-core] [PATCH] Revert "featimage: refactor style"

[Peter Kjellerstedt]

> -Original Message-
> From: Marek Vasut 
> Sent: den 29 januari 2022 02:39
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Cc: Andrej Valek ; Richard Purdie
> 
> Subject: Re: [OE-core] [PATCH] Revert "featimage: refactor style"
> 
> On 1/29/22 02:06, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core@lists.openembedded.org  >> c...@lists.openembedded.org> On Behalf Of Marek Vasut
> >> Sent: den 29 januari 2022 01:29
> >> To: openembedded-core@lists.openembedded.org
> >> Cc: Marek Vasut ; Andrej Valek
> ;
> >> Richard Purdie 
> >> Subject: [OE-core] [PATCH] Revert "featimage: refactor style"
> >>
> >> This reverts commit f44bb458884da64356ee188917094b5515d3b159.
> >>
> >> The reverted patch attempted to perform some sort of clean up, however
> >> it only brought in style inconsistencies like this:
> >>
> >> ```
> >> conf_desc="$conf_desc${sep}setup"
> >> ```
> >>
> >> The curly brackets around variables were placed in the kernel-fitimage
> >> bbclass deliberately, since when assembling the fitimage ITS there are
> >> multiple variables where it is difficult to identify where the variable
> >> ends and some sort of follow up string starts.
> >
> > There is actually a technical reason to not use ${foo} for shell
> > variables unless necessary in bitbake files and it is because
> > bitbake will treat them all as potential bitbake variables. This
> > means they are unnecessarily included in the taskhashes that
> > bitbake calculates.
> 
> Yikes. (it would be good to include this gem in the commit message)

Well there was:

- use bash variable notation without {} where possible
  - just to make sure it looks like bash variable not bitbake variable one

though I guess my explanation has a bit more technical merit 
than that it improves the looks. ;)

> So are we stuck with this inconsistent coding style change 
> or is there a

Personally I do not see it as inconsistent, it is just the way 
shell handles variables. It is just something to get used to (I 
also had a colleague who would review any shell code changes we 
made and comment on every single unnecessary character so one 
quickly learned to use $foo everywhere possible rather than 
${foo}...) That said, I have never looked at this code so I 
have no real idea of how bad it is or isn't.

> third alternative ? I mean, besides rewriting the fitimage 
> generation into python, which might make it more flexible too.

Replacing shell code that has grown beyond a couple of hundred 
(tens?) lines with something written in a better language is 
almost always a good idea.

//Peter


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

Re: [OE-core] [PATCH] Revert "featimage: refactor style"

[Marek Vasut]

On 1/29/22 02:06, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core@lists.openembedded.org  On Behalf Of Marek Vasut
Sent: den 29 januari 2022 01:29
To: openembedded-core@lists.openembedded.org
Cc: Marek Vasut ; Andrej Valek ;
Richard Purdie 
Subject: [OE-core] [PATCH] Revert "featimage: refactor style"

This reverts commit f44bb458884da64356ee188917094b5515d3b159.

The reverted patch attempted to perform some sort of clean up, however
it only brought in style inconsistencies like this:

```
conf_desc="$conf_desc${sep}setup"
```

The curly brackets around variables were placed in the kernel-fitimage
bbclass deliberately, since when assembling the fitimage ITS there are
multiple variables where it is difficult to identify where the variable
ends and some sort of follow up string starts.


There is actually a technical reason to not use ${foo} for shell
variables unless necessary in bitbake files and it is because
bitbake will treat them all as potential bitbake variables. This
means they are unnecessarily included in the taskhashes that
bitbake calculates.


Yikes. (it would be good to include this gem in the commit message)

So are we stuck with this inconsistent coding style change or is there a 
third alternative ? I mean, besides rewriting the fitimage generation 
into python, which might make it more flexible too.

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

Re: [OE-core] [PATCH] Revert "featimage: refactor style"

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Marek Vasut
> Sent: den 29 januari 2022 01:29
> To: openembedded-core@lists.openembedded.org
> Cc: Marek Vasut ; Andrej Valek ;
> Richard Purdie 
> Subject: [OE-core] [PATCH] Revert "featimage: refactor style"
> 
> This reverts commit f44bb458884da64356ee188917094b5515d3b159.
> 
> The reverted patch attempted to perform some sort of clean up, however
> it only brought in style inconsistencies like this:
> 
> ```
> conf_desc="$conf_desc${sep}setup"
> ```
> 
> The curly brackets around variables were placed in the kernel-fitimage
> bbclass deliberately, since when assembling the fitimage ITS there are
> multiple variables where it is difficult to identify where the variable
> ends and some sort of follow up string starts.

There is actually a technical reason to not use ${foo} for shell 
variables unless necessary in bitbake files and it is because 
bitbake will treat them all as potential bitbake variables. This 
means they are unnecessarily included in the taskhashes that 
bitbake calculates.

//Peter

> 
> Signed-off-by: Marek Vasut 
> Cc: Andrej Valek 
> Cc: Richard Purdie 
> ---
>  meta/classes/kernel-fitimage.bbclass | 289 +--
>  meta/classes/uboot-sign.bbclass  |  56 +++---
>  2 files changed, 171 insertions(+), 174 deletions(-)
> 
> diff --git a/meta/classes/kernel-fitimage.bbclass b/meta/classes/kernel-
> fitimage.bbclass
> index b0c971b0eb..1e3bc21f1f 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
>  #
>  # $1 ... .its filename
>  fitimage_emit_fit_header() {
> - cat << EOF >> $1
> + cat << EOF >> ${1}
>  /dts-v1/;
> 
>  / {
> @@ -94,24 +94,24 @@ EOF
>  fitimage_emit_section_maint() {
>   case $2 in
>   imagestart)
> - cat << EOF >> $1
> + cat << EOF >> ${1}
> 
>  images {
>  EOF
>   ;;
>   confstart)
> - cat << EOF >> $1
> + cat << EOF >> ${1}
> 
>  configurations {
>  EOF
>   ;;
>   sectend)
> - cat << EOF >> $1
> + cat << EOF >> ${1}
>   };
>  EOF
>   ;;
>   fitend)
> - cat << EOF >> $1
> + cat << EOF >> ${1}
>  };
>  EOF
>   ;;
> @@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
>   awk '$3=="${UBOOT_ENTRYSYMBOL}" {print
> "0x"$1;exit}'`
>   fi
> 
> - cat << EOF >> $1
> -kernel-$2 {
> + cat << EOF >> ${1}
> +kernel-${2} {
>  description = "Linux kernel";
> -data = /incbin/("$3");
> +data = /incbin/("${3}");
>  type = "kernel";
>  arch = "${UBOOT_ARCH}";
>  os = "linux";
> -compression = "$4";
> +compression = "${4}";
>  load = <${UBOOT_LOADADDRESS}>;
> -entry = <$ENTRYPOINT>;
> +entry = <${ENTRYPOINT}>;
>  hash-1 {
> -algo = "$kernel_csum";
> +algo = "${kernel_csum}";
>  };
>  };
>  EOF
> 
> - if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" =
> "1" -a -n "$kernel_sign_keyname" ] ; then
> - sed -i '$ d' $1
> - cat << EOF >> $1
> + if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" =
> "1" -a -n "${kernel_sign_keyname}" ] ; then
> + sed -i '$ d' ${1}
> + cat << EOF >> ${1}
>  signature-1 {
> -algo = "$kernel_csum,$kernel_sign_algo";
> -key-name-hint = "$kernel_sign_keyname";
> +algo =
> "${kernel_csum},${kernel_sign_algo}";
> +key-name-hint = "${kernel_sign_keyname}";
>  };
>  };
>  EOF
> @@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
>   elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
>   dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
>   fi
> - cat << EOF >> $1
> -fdt-$2 {
> + cat << EOF >> ${1}
> +fdt-${2} {
>  description = "Flattened Device Tree blob";
> -data = /incbin/("$3");
> +data = /incbin/("${3}");
>  type = "flat_dt";
>  arch = "${UBOOT_ARCH}";
>  compression = "none";
> -$dtb_loadline
> +${dtb_loadline}
>  hash-1 {
> -algo = "$dtb_csum";
> + 

[OE-core] [PATCH] kernel-fitimage: Add missing dependency for UBOOT_ENV

[Marek Vasut]

For $UBOOT_ENV file to appear in sysroot, virtual/bootloader
must populate sysroot first. Add the missing dependency.

Signed-off-by: Marek Vasut 
Cc: Richard Purdie 
---
 meta/classes/kernel-fitimage.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 1e3bc21f1f..507e0a2213 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -36,6 +36,10 @@ python __anonymous () {
 if image:
 d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
 
+ubootenv = d.getVar('UBOOT_ENV')
+if ubootenv:
+d.appendVarFlag('do_assemble_fitimage', 'depends', ' 
virtual/bootloader:do_populate_sysroot')
+
 #check if there are any dtb providers
 providerdtb = d.getVar("PREFERRED_PROVIDER_virtual/dtb")
 if providerdtb:
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161088): 
https://lists.openembedded.org/g/openembedded-core/message/161088
Mute This Topic: https://lists.openembedded.org/mt/88758951/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] Revert "featimage: refactor style"

[Marek Vasut]

This reverts commit f44bb458884da64356ee188917094b5515d3b159.

The reverted patch attempted to perform some sort of clean up, however
it only brought in style inconsistencies like this:

```
conf_desc="$conf_desc${sep}setup"
```

The curly brackets around variables were placed in the kernel-fitimage
bbclass deliberately, since when assembling the fitimage ITS there are
multiple variables where it is difficult to identify where the variable
ends and some sort of follow up string starts.

Signed-off-by: Marek Vasut 
Cc: Andrej Valek 
Cc: Richard Purdie 
---
 meta/classes/kernel-fitimage.bbclass | 289 +--
 meta/classes/uboot-sign.bbclass  |  56 +++---
 2 files changed, 171 insertions(+), 174 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index b0c971b0eb..1e3bc21f1f 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
 #
 # $1 ... .its filename
 fitimage_emit_fit_header() {
-   cat << EOF >> $1
+   cat << EOF >> ${1}
 /dts-v1/;
 
 / {
@@ -94,24 +94,24 @@ EOF
 fitimage_emit_section_maint() {
case $2 in
imagestart)
-   cat << EOF >> $1
+   cat << EOF >> ${1}
 
 images {
 EOF
;;
confstart)
-   cat << EOF >> $1
+   cat << EOF >> ${1}
 
 configurations {
 EOF
;;
sectend)
-   cat << EOF >> $1
+   cat << EOF >> ${1}
};
 EOF
;;
fitend)
-   cat << EOF >> $1
+   cat << EOF >> ${1}
 };
 EOF
;;
@@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print "0x"$1;exit}'`
fi
 
-   cat << EOF >> $1
-kernel-$2 {
+   cat << EOF >> ${1}
+kernel-${2} {
 description = "Linux kernel";
-data = /incbin/("$3");
+data = /incbin/("${3}");
 type = "kernel";
 arch = "${UBOOT_ARCH}";
 os = "linux";
-compression = "$4";
+compression = "${4}";
 load = <${UBOOT_LOADADDRESS}>;
-entry = <$ENTRYPOINT>;
+entry = <${ENTRYPOINT}>;
 hash-1 {
-algo = "$kernel_csum";
+algo = "${kernel_csum}";
 };
 };
 EOF
 
-   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "$kernel_sign_keyname" ] ; then
-   sed -i '$ d' $1
-   cat << EOF >> $1
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "${kernel_sign_keyname}" ] ; then
+   sed -i '$ d' ${1}
+   cat << EOF >> ${1}
 signature-1 {
-algo = "$kernel_csum,$kernel_sign_algo";
-key-name-hint = "$kernel_sign_keyname";
+algo = "${kernel_csum},${kernel_sign_algo}";
+key-name-hint = "${kernel_sign_keyname}";
 };
 };
 EOF
@@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
fi
-   cat << EOF >> $1
-fdt-$2 {
+   cat << EOF >> ${1}
+fdt-${2} {
 description = "Flattened Device Tree blob";
-data = /incbin/("$3");
+data = /incbin/("${3}");
 type = "flat_dt";
 arch = "${UBOOT_ARCH}";
 compression = "none";
-$dtb_loadline
+${dtb_loadline}
 hash-1 {
-algo = "$dtb_csum";
+algo = "${dtb_csum}";
 };
 };
 EOF
 
-   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "$dtb_sign_keyname" ] ; then
-   sed -i '$ d' $1
-   cat << EOF >> $1
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "${dtb_sign_keyname}" ] ; then
+   sed -i '$ d' ${1}
+   cat << EOF >> ${1}
 signature-1 {
-algo = "$dtb_csum,$dtb_sign_algo";
-key-name-hint = "$dtb_sign_keyname";
+algo = "${dtb_csum},${dtb_sign_algo}";
+key-name-hint = "${dtb_sign_keyname}";
 };

[OE-core] [PATCH] wayland-protocols: upgrade 1.24 -> 1.25

[Denys Dmytriyenko]

https://lists.freedesktop.org/archives/wayland-devel/2022-January/042102.html

wayland-protocols 1.25 is now available.

Apart from minor fixes and clarifications, this release also adds a new staging
protocol for session locking, as well as a 'bounds' event to the xdg_toplevel
interface. See the individual commits and protocol specifications for
details.

Signed-off-by: Denys Dmytriyenko 
---
 .../{wayland-protocols_1.24.bb => wayland-protocols_1.25.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/wayland/{wayland-protocols_1.24.bb => 
wayland-protocols_1.25.bb} (91%)

diff --git a/meta/recipes-graphics/wayland/wayland-protocols_1.24.bb 
b/meta/recipes-graphics/wayland/wayland-protocols_1.25.bb
similarity index 91%
rename from meta/recipes-graphics/wayland/wayland-protocols_1.24.bb
rename to meta/recipes-graphics/wayland/wayland-protocols_1.25.bb
index 0cfdb90b68..074801b22d 100644
--- a/meta/recipes-graphics/wayland/wayland-protocols_1.24.bb
+++ b/meta/recipes-graphics/wayland/wayland-protocols_1.25.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=c7b12b6702da38ca028ace54aae3d484 \
 
 SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
"
-SRC_URI[sha256sum] = 
"bff0d8cffeeceb35159d6f4aa6bab18c807b80642c9d50f66cba52ecf7338bc2"
+SRC_URI[sha256sum] = 
"f1ff0f7199d0a0da337217dd8c99979967808dc37731a1e759e822b75b571460"
 
 UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html;
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161086): 
https://lists.openembedded.org/g/openembedded-core/message/161086
Mute This Topic: https://lists.openembedded.org/mt/88757474/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] [WIP/RFC] create-spdx: Get SPDX-License-Identifier from source

[Joshua Watt]

On 1/28/22 4:03 PM, Saul Wold wrote:

This patch will read the begining of source files and try to find
the SPDX-License-Identifier to populate the licenseInfoInFiles
field for each source file. This does not populate licenseConculed
at this time, nor rolls it up to package level.

Signed-off-by: Saul Wold 
---
  classes/create-spdx.bbclass | 25 +
  lib/oe/spdx.py  |  2 +-
  2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/classes/create-spdx.bbclass b/classes/create-spdx.bbclass
index 180d667..9c11945 100644
--- a/classes/create-spdx.bbclass
+++ b/classes/create-spdx.bbclass
@@ -30,6 +30,21 @@ SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
  
  do_image_complete[depends] = "virtual/kernel:do_create_spdx"
  
+def extract_licenses(filename):

+import re
+lic_regex = re.compile('SPDX-License-Identifier:\s+([-A-Za-z\d. ]+)[ 
|\n|\r\n]*?')
+
+try:
+with open(filename, 'r') as f:
+size = min(15000, os.stat(filename).st_size)
+txt = f.read(size)
+licenses = re.findall(lic_regex, txt)
+if licenses:
+return licenses
+except Exception as e:
+bb.warn(f"Exception on {filename}: {e}")
+return None
+
  def get_doc_namespace(d, doc):
  import uuid
  namespace_uuid = uuid.uuid5(uuid.NAMESPACE_DNS, 
d.getVar("SPDX_UUID_NAMESPACE"))
@@ -232,6 +247,16 @@ def add_package_files(d, doc, spdx_pkg, topdir, 
get_spdxid, get_types, *, archiv
  checksumValue=bb.utils.sha256_file(filepath),
  ))
  
+if "SOURCES" in spdx_file.fileTypes:

+licenses = extract_licenses(filepath)
+if licenses is not None:
+for lic in licenses:
+spdx_file.licenseInfoInFiles.append(lic.strip())
+else:
+spdx_file.licenseInfoInFiles.append("NOASSERTATION")


"NOASSERTION"



+else:
+spdx_file.licenseInfoInFiles.append("NOASSERTATION")


"NOASSERTION"


+
  doc.files.append(spdx_file)
  doc.add_relationship(spdx_pkg, "CONTAINS", spdx_file)
  spdx_pkg.hasFiles.append(spdx_file.SPDXID)
diff --git a/lib/oe/spdx.py b/lib/oe/spdx.py
index 9e7ced5..71e7c1c 100644
--- a/lib/oe/spdx.py
+++ b/lib/oe/spdx.py
@@ -236,7 +236,7 @@ class SPDXFile(SPDXObject):
  fileName = _String()
  licenseConcluded = _String(default="NOASSERTION")
  copyrightText = _String(default="NOASSERTION")
-licenseInfoInFiles = _StringList(default=["NOASSERTION"])
+licenseInfoInFiles = _StringList()


It's required to have "NOASSERTION" as the default if you don't do 
anything, so we shouldn't change the default here (by and large, this 
file should capture the spec over our use of it).


It's on my TODO list to make the "default" lists behave like default 
scalars, where appending replaces the default instead of appending to 
it, but I haven't gotten there yet; it hasn't come up as a problem before.



Probably need to do something like:


 license_info_from_file = []
 # scan files here
 if license_info_from_files:

    spdx_file.licenseInfoInFiles = license_info_from_files



  checksums = _ObjectList(SPDXChecksum)
  fileTypes = _StringList()
  

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

[OE-core] [WIP/RFC] create-spdx: Get SPDX-License-Identifier from source

[Saul Wold]

This patch will read the begining of source files and try to find
the SPDX-License-Identifier to populate the licenseInfoInFiles
field for each source file. This does not populate licenseConculed
at this time, nor rolls it up to package level.

Signed-off-by: Saul Wold 
---
 classes/create-spdx.bbclass | 25 +
 lib/oe/spdx.py  |  2 +-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/classes/create-spdx.bbclass b/classes/create-spdx.bbclass
index 180d667..9c11945 100644
--- a/classes/create-spdx.bbclass
+++ b/classes/create-spdx.bbclass
@@ -30,6 +30,21 @@ SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
 
 do_image_complete[depends] = "virtual/kernel:do_create_spdx"
 
+def extract_licenses(filename):
+import re
+lic_regex = re.compile('SPDX-License-Identifier:\s+([-A-Za-z\d. ]+)[ 
|\n|\r\n]*?')
+
+try:
+with open(filename, 'r') as f:
+size = min(15000, os.stat(filename).st_size)
+txt = f.read(size)
+licenses = re.findall(lic_regex, txt)
+if licenses:
+return licenses
+except Exception as e:
+bb.warn(f"Exception on {filename}: {e}")
+return None
+
 def get_doc_namespace(d, doc):
 import uuid
 namespace_uuid = uuid.uuid5(uuid.NAMESPACE_DNS, 
d.getVar("SPDX_UUID_NAMESPACE"))
@@ -232,6 +247,16 @@ def add_package_files(d, doc, spdx_pkg, topdir, 
get_spdxid, get_types, *, archiv
 checksumValue=bb.utils.sha256_file(filepath),
 ))
 
+if "SOURCES" in spdx_file.fileTypes:
+licenses = extract_licenses(filepath)
+if licenses is not None:
+for lic in licenses:
+spdx_file.licenseInfoInFiles.append(lic.strip())
+else:
+spdx_file.licenseInfoInFiles.append("NOASSERTATION")
+else:
+spdx_file.licenseInfoInFiles.append("NOASSERTATION")
+
 doc.files.append(spdx_file)
 doc.add_relationship(spdx_pkg, "CONTAINS", spdx_file)
 spdx_pkg.hasFiles.append(spdx_file.SPDXID)
diff --git a/lib/oe/spdx.py b/lib/oe/spdx.py
index 9e7ced5..71e7c1c 100644
--- a/lib/oe/spdx.py
+++ b/lib/oe/spdx.py
@@ -236,7 +236,7 @@ class SPDXFile(SPDXObject):
 fileName = _String()
 licenseConcluded = _String(default="NOASSERTION")
 copyrightText = _String(default="NOASSERTION")
-licenseInfoInFiles = _StringList(default=["NOASSERTION"])
+licenseInfoInFiles = _StringList()
 checksums = _ObjectList(SPDXChecksum)
 fileTypes = _StringList()
 
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161084): 
https://lists.openembedded.org/g/openembedded-core/message/161084
Mute This Topic: https://lists.openembedded.org/mt/88756042/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] [meta][dunfell][PATCH] util-linux: Fix for CVE-2021-3995 and CVE-2021-3996

[Steve Sakoman]

On Fri, Jan 28, 2022 at 6:53 AM Ranjitsinh Rathod <
ranjitsinh.rat...@kpit.com> wrote:

> Steve,
>
> Can you try this attached file instead which was the output of git
> format-patch -1 only?
>

Sadly this has the same issue.

Do you have a public git repo with the correct commit that I can pull from?

Steve


>
> Thanks,
>
> Best Regards,
>
> *Ranjitsinh Rathod*
> Technical Leader |  | KPIT Technologies Ltd.
> Cellphone: +91-84606 92403
>
> *__ *KPIT  |
>  Follow us on LinkedIn 
>
> 
> --
> *From:* openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org> on behalf of Ranjitsinh Rathod
> via lists.openembedded.org  gmail@lists.openembedded.org>
> *Sent:* Friday, January 28, 2022 10:15 PM
> *To:* Steve Sakoman 
> *Cc:* Patches and discussions about the oe-core layer <
> openembedded-core@lists.openembedded.org>; Akash Hadke <
> akash.ha...@kpit.com>; Purushottam Choudhary <
> purushottam.choudh...@kpit.com>; Ranjitsinh Rathod <
> ranjitsinh.rat...@kpit.com>
> *Subject:* Re: [OE-core] [meta][dunfell][PATCH] util-linux: Fix for
> CVE-2021-3995 and CVE-2021-3996
>
> Caution: This email originated from outside of the KPIT. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> Hi Steve,
>
> I have also faced this problem during the patch test. Actually, this is
> due to the code itself has next line character between 'foo' and 'bar'.
>
> This is maybe because of the below change
>
> https://github.com/util-linux/util-linux/commit/5b13d6a1c905e1e425e6b7ca340a410c580f0f75
> 
>
> Then I have manually added '^M' character as line break between 'foo' and
> 'bar' and it worked.
>
> Do you know anything else to avoid these errors?
>
> Thanks,
> Ranjitsinh
>
> On Fri, 28 Jan, 2022, 8:44 pm Steve Sakoman,  wrote:
>
> On Fri, Jan 28, 2022 at 3:46 AM Ranjitsinh Rathod
>  wrote:
> >
> > From: Ranjitsinh Rathod 
> >
> > Add patches to fix CVE-2021-3995 and CVE-2021-3996
> > Also, add support include-strutils-cleanup-strto-functions.patch to
> > solve compilation error where `ul_strtou64` function not found which is
> > used in CVE-2021-3995.patch
> >
> > Signed-off-by: Ranjitsinh Rathod 
> > Signed-off-by: Ranjitsinh Rathod 
> > ---
> >  .../util-linux/util-linux/CVE-2021-3995.patch | 139 +
> >  .../util-linux/util-linux/CVE-2021-3996.patch | 226 +++
> >  ...ude-strutils-cleanup-strto-functions.patch | 270 ++
> >  .../util-linux/util-linux_2.35.1.bb
> 
>  |   3 +
> >  4 files changed, 638 insertions(+)
> >  create mode 100644
> meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> >  create mode 100644
> meta/recipes-core/util-linux/util-linux/CVE-2021-3996.patch
> >  create mode 100644
> meta/recipes-core/util-linux/util-linux/include-strutils-cleanup-strto-functions.patch
> >
> > diff --git a/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> > new file mode 100644
> > index 00..1dcb66ad1d
> > --- /dev/null
> > +++ b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> > @@ -0,0 +1,139 @@
> > +From f3db9bd609494099f0c1b95231c5dfe383346929 Mon Sep 17 00:00:00 2001
> > +From: Karel Zak 
> > +Date: Wed, 24 Nov 2021 13:53:25 +0100
> > +Subject: [PATCH] libmount: fix UID check for FUSE umount [CVE-2021-3995]
> > +
> > +Improper UID check allows an unprivileged user to unmount FUSE
> > +filesystems of users with similar UID.
> > +
> > +Signed-off-by: Karel Zak 
> > +
> > +CVE: CVE-2021-3995
> > +Upstream-Status: Backport [
> https://github.com/util-linux/util-linux/commit/f3db9bd609494099f0c1b95231c5dfe383346929
> 

Re: [OE-core] [meta][dunfell][PATCH] util-linux: Fix for CVE-2021-3995 and CVE-2021-3996

[Ranjitsinh Rathod]

Hi Steve,

I have also faced this problem during the patch test. Actually, this is due
to the code itself has next line character between 'foo' and 'bar'.

This is maybe because of the below change
https://github.com/util-linux/util-linux/commit/5b13d6a1c905e1e425e6b7ca340a410c580f0f75

Then I have manually added '^M' character as line break between 'foo' and
'bar' and it worked.

Do you know anything else to avoid these errors?

Thanks,
Ranjitsinh

On Fri, 28 Jan, 2022, 8:44 pm Steve Sakoman,  wrote:

> On Fri, Jan 28, 2022 at 3:46 AM Ranjitsinh Rathod
>  wrote:
> >
> > From: Ranjitsinh Rathod 
> >
> > Add patches to fix CVE-2021-3995 and CVE-2021-3996
> > Also, add support include-strutils-cleanup-strto-functions.patch to
> > solve compilation error where `ul_strtou64` function not found which is
> > used in CVE-2021-3995.patch
> >
> > Signed-off-by: Ranjitsinh Rathod 
> > Signed-off-by: Ranjitsinh Rathod 
> > ---
> >  .../util-linux/util-linux/CVE-2021-3995.patch | 139 +
> >  .../util-linux/util-linux/CVE-2021-3996.patch | 226 +++
> >  ...ude-strutils-cleanup-strto-functions.patch | 270 ++
> >  .../util-linux/util-linux_2.35.1.bb   |   3 +
> >  4 files changed, 638 insertions(+)
> >  create mode 100644
> meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> >  create mode 100644
> meta/recipes-core/util-linux/util-linux/CVE-2021-3996.patch
> >  create mode 100644
> meta/recipes-core/util-linux/util-linux/include-strutils-cleanup-strto-functions.patch
> >
> > diff --git a/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> > new file mode 100644
> > index 00..1dcb66ad1d
> > --- /dev/null
> > +++ b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> > @@ -0,0 +1,139 @@
> > +From f3db9bd609494099f0c1b95231c5dfe383346929 Mon Sep 17 00:00:00 2001
> > +From: Karel Zak 
> > +Date: Wed, 24 Nov 2021 13:53:25 +0100
> > +Subject: [PATCH] libmount: fix UID check for FUSE umount [CVE-2021-3995]
> > +
> > +Improper UID check allows an unprivileged user to unmount FUSE
> > +filesystems of users with similar UID.
> > +
> > +Signed-off-by: Karel Zak 
> > +
> > +CVE: CVE-2021-3995
> > +Upstream-Status: Backport [
> https://github.com/util-linux/util-linux/commit/f3db9bd609494099f0c1b95231c5dfe383346929
> ]
> > +Signed-off-by: Ranjitsinh Rathod 
> > +
> > +---
> > + include/strutils.h|  2 +-
> > + libmount/src/context_umount.c | 14 +++-
> > + libmount/src/mountP.h |  1 +
> > + libmount/src/optstr.c | 42 +++
> > + 4 files changed, 47 insertions(+), 12 deletions(-)
> > +
> > +diff --git a/include/strutils.h b/include/strutils.h
> > +index 6e95707ea9..a84d29594d 100644
> > +--- a/include/strutils.h
> >  b/include/strutils.h
> > +@@ -91,8 +91,8 @@ static inline char *mem2strcpy(char *dest, const void
> *src, size_t n, size_t nma
> > +   if (n + 1 > nmax)
> > +   n = nmax - 1;
> > +
> > ++  memset(dest, '\0', nmax);
> > +   memcpy(dest, src, n);
> > +-  dest[nmax-1] = '\0';
> > +   return dest;
> > + }
> > +
> > +diff --git a/libmount/src/context_umount.c
> b/libmount/src/context_umount.c
> > +index 173637a15a..8773c65ffa 100644
> > +--- a/libmount/src/context_umount.c
> >  b/libmount/src/context_umount.c
> > +@@ -393,10 +393,7 @@ static int is_fuse_usermount(struct libmnt_context
> *cxt, int *errsv)
> > +   struct libmnt_ns *ns_old;
> > +   const char *type = mnt_fs_get_fstype(cxt->fs);
> > +   const char *optstr;
> > +-  char *user_id = NULL;
> > +-  size_t sz;
> > +-  uid_t uid;
> > +-  char uidstr[sizeof(stringify_value(ULONG_MAX))];
> > ++  uid_t uid, entry_uid;
> > +
> > +   *errsv = 0;
> > +
> > +@@ -413,11 +410,7 @@ static int is_fuse_usermount(struct libmnt_context
> *cxt, int *errsv)
> > +   optstr = mnt_fs_get_fs_options(cxt->fs);
> > +   if (!optstr)
> > +   return 0;
> > +-
> > +-  if (mnt_optstr_get_option(optstr, "user_id", _id, ) != 0)
> > +-  return 0;
> > +-
> > +-  if (sz == 0 || user_id == NULL)
> > ++  if (mnt_optstr_get_uid(optstr, "user_id", _uid) != 0)
> > +   return 0;
> > +
> > +   /* get current user */
> > +@@ -434,8 +427,7 @@ static int is_fuse_usermount(struct libmnt_context
> *cxt, int *errsv)
> > +   return 0;
> > +   }
> > +
> > +-  snprintf(uidstr, sizeof(uidstr), "%lu", (unsigned long) uid);
> > +-  return strncmp(user_id, uidstr, sz) == 0;
> > ++  return uid == entry_uid;
> > + }
> > +
> > + /*
> > +diff --git a/libmount/src/mountP.h b/libmount/src/mountP.h
> > +index d43a835418..22442ec55e 100644
> > +--- a/libmount/src/mountP.h
> >  b/libmount/src/mountP.h
> > +@@ -400,6 +400,7 @@ extern const struct libmnt_optmap
> *mnt_optmap_get_entry(
> > +const struct libmnt_optmap **mapent);
> > +
> 

Re: [OE-core] [meta][dunfell][PATCH] util-linux: Fix for CVE-2021-3995 and CVE-2021-3996

[Steve Sakoman]

On Fri, Jan 28, 2022 at 3:46 AM Ranjitsinh Rathod
 wrote:
>
> From: Ranjitsinh Rathod 
>
> Add patches to fix CVE-2021-3995 and CVE-2021-3996
> Also, add support include-strutils-cleanup-strto-functions.patch to
> solve compilation error where `ul_strtou64` function not found which is
> used in CVE-2021-3995.patch
>
> Signed-off-by: Ranjitsinh Rathod 
> Signed-off-by: Ranjitsinh Rathod 
> ---
>  .../util-linux/util-linux/CVE-2021-3995.patch | 139 +
>  .../util-linux/util-linux/CVE-2021-3996.patch | 226 +++
>  ...ude-strutils-cleanup-strto-functions.patch | 270 ++
>  .../util-linux/util-linux_2.35.1.bb   |   3 +
>  4 files changed, 638 insertions(+)
>  create mode 100644 
> meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
>  create mode 100644 
> meta/recipes-core/util-linux/util-linux/CVE-2021-3996.patch
>  create mode 100644 
> meta/recipes-core/util-linux/util-linux/include-strutils-cleanup-strto-functions.patch
>
> diff --git a/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch 
> b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> new file mode 100644
> index 00..1dcb66ad1d
> --- /dev/null
> +++ b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
> @@ -0,0 +1,139 @@
> +From f3db9bd609494099f0c1b95231c5dfe383346929 Mon Sep 17 00:00:00 2001
> +From: Karel Zak 
> +Date: Wed, 24 Nov 2021 13:53:25 +0100
> +Subject: [PATCH] libmount: fix UID check for FUSE umount [CVE-2021-3995]
> +
> +Improper UID check allows an unprivileged user to unmount FUSE
> +filesystems of users with similar UID.
> +
> +Signed-off-by: Karel Zak 
> +
> +CVE: CVE-2021-3995
> +Upstream-Status: Backport 
> [https://github.com/util-linux/util-linux/commit/f3db9bd609494099f0c1b95231c5dfe383346929]
> +Signed-off-by: Ranjitsinh Rathod 
> +
> +---
> + include/strutils.h|  2 +-
> + libmount/src/context_umount.c | 14 +++-
> + libmount/src/mountP.h |  1 +
> + libmount/src/optstr.c | 42 +++
> + 4 files changed, 47 insertions(+), 12 deletions(-)
> +
> +diff --git a/include/strutils.h b/include/strutils.h
> +index 6e95707ea9..a84d29594d 100644
> +--- a/include/strutils.h
>  b/include/strutils.h
> +@@ -91,8 +91,8 @@ static inline char *mem2strcpy(char *dest, const void 
> *src, size_t n, size_t nma
> +   if (n + 1 > nmax)
> +   n = nmax - 1;
> +
> ++  memset(dest, '\0', nmax);
> +   memcpy(dest, src, n);
> +-  dest[nmax-1] = '\0';
> +   return dest;
> + }
> +
> +diff --git a/libmount/src/context_umount.c b/libmount/src/context_umount.c
> +index 173637a15a..8773c65ffa 100644
> +--- a/libmount/src/context_umount.c
>  b/libmount/src/context_umount.c
> +@@ -393,10 +393,7 @@ static int is_fuse_usermount(struct libmnt_context 
> *cxt, int *errsv)
> +   struct libmnt_ns *ns_old;
> +   const char *type = mnt_fs_get_fstype(cxt->fs);
> +   const char *optstr;
> +-  char *user_id = NULL;
> +-  size_t sz;
> +-  uid_t uid;
> +-  char uidstr[sizeof(stringify_value(ULONG_MAX))];
> ++  uid_t uid, entry_uid;
> +
> +   *errsv = 0;
> +
> +@@ -413,11 +410,7 @@ static int is_fuse_usermount(struct libmnt_context 
> *cxt, int *errsv)
> +   optstr = mnt_fs_get_fs_options(cxt->fs);
> +   if (!optstr)
> +   return 0;
> +-
> +-  if (mnt_optstr_get_option(optstr, "user_id", _id, ) != 0)
> +-  return 0;
> +-
> +-  if (sz == 0 || user_id == NULL)
> ++  if (mnt_optstr_get_uid(optstr, "user_id", _uid) != 0)
> +   return 0;
> +
> +   /* get current user */
> +@@ -434,8 +427,7 @@ static int is_fuse_usermount(struct libmnt_context *cxt, 
> int *errsv)
> +   return 0;
> +   }
> +
> +-  snprintf(uidstr, sizeof(uidstr), "%lu", (unsigned long) uid);
> +-  return strncmp(user_id, uidstr, sz) == 0;
> ++  return uid == entry_uid;
> + }
> +
> + /*
> +diff --git a/libmount/src/mountP.h b/libmount/src/mountP.h
> +index d43a835418..22442ec55e 100644
> +--- a/libmount/src/mountP.h
>  b/libmount/src/mountP.h
> +@@ -400,6 +400,7 @@ extern const struct libmnt_optmap *mnt_optmap_get_entry(
> +const struct libmnt_optmap **mapent);
> +
> + /* optstr.c */
> ++extern int mnt_optstr_get_uid(const char *optstr, const char *name, uid_t 
> *uid);
> + extern int mnt_optstr_remove_option_at(char **optstr, char *begin, char 
> *end);
> + extern int mnt_optstr_fix_gid(char **optstr, char *value, size_t valsz, 
> char **next);
> + extern int mnt_optstr_fix_uid(char **optstr, char *value, size_t valsz, 
> char **next);
> +diff --git a/libmount/src/optstr.c b/libmount/src/optstr.c
> +index 921b9318e7..16800f571c 100644
> +--- a/libmount/src/optstr.c
>  b/libmount/src/optstr.c
> +@@ -1090,6 +1090,48 @@ int mnt_optstr_fix_user(char **optstr)
> +   return rc;
> + }
> +
> ++/*
> ++ * Converts value from @optstr addressed by @name to uid.
> ++ *
> ++ * 

[OE-core] [meta][dunfell][PATCH] util-linux: Fix for CVE-2021-3995 and CVE-2021-3996

[Ranjitsinh Rathod]

From: Ranjitsinh Rathod 

Add patches to fix CVE-2021-3995 and CVE-2021-3996
Also, add support include-strutils-cleanup-strto-functions.patch to
solve compilation error where `ul_strtou64` function not found which is
used in CVE-2021-3995.patch

Signed-off-by: Ranjitsinh Rathod 
Signed-off-by: Ranjitsinh Rathod 
---
 .../util-linux/util-linux/CVE-2021-3995.patch | 139 +
 .../util-linux/util-linux/CVE-2021-3996.patch | 226 +++
 ...ude-strutils-cleanup-strto-functions.patch | 270 ++
 .../util-linux/util-linux_2.35.1.bb   |   3 +
 4 files changed, 638 insertions(+)
 create mode 100644 meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
 create mode 100644 meta/recipes-core/util-linux/util-linux/CVE-2021-3996.patch
 create mode 100644 
meta/recipes-core/util-linux/util-linux/include-strutils-cleanup-strto-functions.patch

diff --git a/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch 
b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
new file mode 100644
index 00..1dcb66ad1d
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux/CVE-2021-3995.patch
@@ -0,0 +1,139 @@
+From f3db9bd609494099f0c1b95231c5dfe383346929 Mon Sep 17 00:00:00 2001
+From: Karel Zak 
+Date: Wed, 24 Nov 2021 13:53:25 +0100
+Subject: [PATCH] libmount: fix UID check for FUSE umount [CVE-2021-3995]
+
+Improper UID check allows an unprivileged user to unmount FUSE
+filesystems of users with similar UID.
+
+Signed-off-by: Karel Zak 
+
+CVE: CVE-2021-3995
+Upstream-Status: Backport 
[https://github.com/util-linux/util-linux/commit/f3db9bd609494099f0c1b95231c5dfe383346929]
+Signed-off-by: Ranjitsinh Rathod 
+
+---
+ include/strutils.h|  2 +-
+ libmount/src/context_umount.c | 14 +++-
+ libmount/src/mountP.h |  1 +
+ libmount/src/optstr.c | 42 +++
+ 4 files changed, 47 insertions(+), 12 deletions(-)
+
+diff --git a/include/strutils.h b/include/strutils.h
+index 6e95707ea9..a84d29594d 100644
+--- a/include/strutils.h
 b/include/strutils.h
+@@ -91,8 +91,8 @@ static inline char *mem2strcpy(char *dest, const void *src, 
size_t n, size_t nma
+   if (n + 1 > nmax)
+   n = nmax - 1;
+ 
++  memset(dest, '\0', nmax);
+   memcpy(dest, src, n);
+-  dest[nmax-1] = '\0';
+   return dest;
+ }
+ 
+diff --git a/libmount/src/context_umount.c b/libmount/src/context_umount.c
+index 173637a15a..8773c65ffa 100644
+--- a/libmount/src/context_umount.c
 b/libmount/src/context_umount.c
+@@ -393,10 +393,7 @@ static int is_fuse_usermount(struct libmnt_context *cxt, 
int *errsv)
+   struct libmnt_ns *ns_old;
+   const char *type = mnt_fs_get_fstype(cxt->fs);
+   const char *optstr;
+-  char *user_id = NULL;
+-  size_t sz;
+-  uid_t uid;
+-  char uidstr[sizeof(stringify_value(ULONG_MAX))];
++  uid_t uid, entry_uid;
+ 
+   *errsv = 0;
+ 
+@@ -413,11 +410,7 @@ static int is_fuse_usermount(struct libmnt_context *cxt, 
int *errsv)
+   optstr = mnt_fs_get_fs_options(cxt->fs);
+   if (!optstr)
+   return 0;
+-
+-  if (mnt_optstr_get_option(optstr, "user_id", _id, ) != 0)
+-  return 0;
+-
+-  if (sz == 0 || user_id == NULL)
++  if (mnt_optstr_get_uid(optstr, "user_id", _uid) != 0)
+   return 0;
+ 
+   /* get current user */
+@@ -434,8 +427,7 @@ static int is_fuse_usermount(struct libmnt_context *cxt, 
int *errsv)
+   return 0;
+   }
+ 
+-  snprintf(uidstr, sizeof(uidstr), "%lu", (unsigned long) uid);
+-  return strncmp(user_id, uidstr, sz) == 0;
++  return uid == entry_uid;
+ }
+ 
+ /*
+diff --git a/libmount/src/mountP.h b/libmount/src/mountP.h
+index d43a835418..22442ec55e 100644
+--- a/libmount/src/mountP.h
 b/libmount/src/mountP.h
+@@ -400,6 +400,7 @@ extern const struct libmnt_optmap *mnt_optmap_get_entry(
+const struct libmnt_optmap **mapent);
+ 
+ /* optstr.c */
++extern int mnt_optstr_get_uid(const char *optstr, const char *name, uid_t 
*uid);
+ extern int mnt_optstr_remove_option_at(char **optstr, char *begin, char *end);
+ extern int mnt_optstr_fix_gid(char **optstr, char *value, size_t valsz, char 
**next);
+ extern int mnt_optstr_fix_uid(char **optstr, char *value, size_t valsz, char 
**next);
+diff --git a/libmount/src/optstr.c b/libmount/src/optstr.c
+index 921b9318e7..16800f571c 100644
+--- a/libmount/src/optstr.c
 b/libmount/src/optstr.c
+@@ -1090,6 +1090,48 @@ int mnt_optstr_fix_user(char **optstr)
+   return rc;
+ }
+ 
++/*
++ * Converts value from @optstr addressed by @name to uid.
++ *
++ * Returns: 0 on success, 1 if not found, <0 on error
++ */
++int mnt_optstr_get_uid(const char *optstr, const char *name, uid_t *uid)
++{
++  char *value = NULL;
++  size_t valsz = 0;
++  char buf[sizeof(stringify_value(UINT64_MAX))];
++  int rc;
++  uint64_t num;
++
++  assert(optstr);
++  

Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install

[Bryan Evenson]

Andrej,

> -Original Message-
> From: Valek, Andrej 
> Sent: Friday, January 28, 2022 6:39 AM
> To: openembedded-core@lists.openembedded.org; Bryan Evenson
> 
> Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox
> links during install
> 
> Hello Bryan,
> 
> So looks like, there is some kind of problem.
> 
> Was you able to run the busybox command after upgrade like, "busybox ls /"
> ?

In this particular case, after upgrade both "busybox ls" and "ls" worked.  
However, that was partly because for this particular case the packages were 
identical but I just forced a version number change.  None of the files were 
actually different after the upgrade.  Failure to replace files didn't affect 
operation.  When I was upgrading my image from the morty release to the dunfell 
release, there was a change in util-linux that conflicted with busybox if they 
both didn't upgrade cleanly and the update-alternatives installation step would 
fail for both.  In that case "busybox ls" would still work but "ls" would not.  
Repeated upgrade attempts didn't fix it.  I had to manually delete certain 
files that were not deleted during the initial upgrade attempt and then upgrade 
packages manually in a particular order to get the system fully operational 
again.

>  - If yes, there is a problem, that update alternatives hasn't been processed
> correctly. Try direct command after reboot, if possible
>  - If no, lets continue with patch creation based on the master branch

I will continue work on a patch based on master.  I'm going to try testing a 
few other cases so I don't anticipate having a patch ready until early next 
week.

Thanks,
Bryan

> 
> Cheers,
> Andrej
> 
> On Thu, 2022-01-27 at 14:39 +, Bryan Evenson wrote:
> > Andrej,
> >
> > > -Original Message-
> > > From: Valek, Andrej 
> > > Sent: Saturday, January 22, 2022 2:26 AM
> > > To: openembedded-core@lists.openembedded.org; Bryan Evenson
> > > 
> > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary
> > > busybox links during install
> > >
> > > Hello again,
> > >
> > > Maybe a general question. Is it working in current master? I do not
> > > want to brake dunfell, just applying something, which will create a
> > > lot of divergence.
> > >
> >
> > I wasn't able to build an image based on the latest master as of
> > Monday.  From the error messages I think it had something to do with
> > the addition of setuptools3-base that wasn't complete yet.  I was able
> > to build and run an image based on the latest honister branch.
> > The master branch has four commits for busybox that honsiter does not
> > have.  In those four commits, I see no changes to any of the
> > installation steps.  Based on this information, I'd say its safe to
> > say that testing on the latest honister branch should confirm whether
> > the problem is still present or not.
> >
> > To test, I first built my image and directly programmed it on my
> > hardware.  My image is based upon core-image-minimal, uses sysvinit
> > for an init system and opkg for a package manager.  I have also added
> > bash, cronie, dhcpcd and util-linux to my image; I've added others but
> > these seem to produce the most obvious errors.
> >
> > After programming the image on my hardware, I added PR="r1" to the gcc
> > recipe.  This forced all the packages to get rebuilt and increment the
> > version number (if anyone knows a simpler way to accomplish this, let
> > me know).  I then created a package feed with this update and
> > attempted an upgrade.
> >
> > To upgrade, I did:
> > opkg update
> > opkg --download-only upgrade
> > opkg upgrade > full_upgrade.txt 2>&1 &
> >
> > I download all the packages to be upgraded first.  I then sent the
> > upgrade process to the background so I could check other things during
> > the upgrade process.
> >
> > During the upgrade, I would occasionally execute "ls -l" to verify
> > that the file full_upgrade.txt existed and was still growing.  About a
> > minute into the upgrade process when I executed "ls -l" I got the
> > error message:
> >
> > ls: not found
> >
> > From that point on until upgrade was complete I had to execute
> > "busybox ls -l" to see the current directory file list.  After upgrade
> > was complete, I checked full_upgrade.txt for error messages.
> > I saw the following:
> >
> > /usr/bin/update-alternatives: line 1: sed: not found  (occurred 102
> > times)
> > /usr/sbin/update-rc.d: line 54: rm: not found (occurred 36 times)
> > Stopping crond: /etc/init.d/crond: line 37: start-stop-daemon: not
> > found
> > /tmp/opkg-yBH1Ta/cronie-zHpym4/preinst: line 1: tr: not found
> > /etc/init.d/udev: line 74: start-stop-daemon: not found
> > /tmp/opkg-yBH1Ta/dhcpcd-c86ca9/preinst: line 1: tr: not found
> >
> > In this case, a lot of alternatives and init scripts may not be setup
> > correctly because either the old ones were not removed or the new ones
> > were not installed.  Prior to my patch below, I saw similar 

[OE-core] [RFC] support for multi project toolchain-cmake

[Tobias Neumann]

Hello everybody,

regarding my bug report
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14703 I was
forwarded to here to discuss requirements for a proper fix.

In the report, I already mentioned a non-generic workaround for that.
By extending the CMAKE_FIND_ROOT_PATH with CMAKE_INSTALL_PREFIX.
However this probably doesn't cover all ways a toolchain can be used.

Another solution could be to respect the user provided path and
instead of overwriting the CMAKE_FIND_ROOT_PATH variable, to only
extent it by the toolchains location.
This however would make it quite easy for a toolchain build to break
isolation, when wrong user input is set. I don't know how strong your
requirements regarding that would be.

So feedback how a fix should look like and what requirements it needs
to fulfill would be appreciated.

best regards
Tobias

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

Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install

[Andrej Valek]

Hello Bryan,

So looks like, there is some kind of problem.

Was you able to run the busybox command after upgrade like, "busybox ls
/" ?
 - If yes, there is a problem, that update alternatives hasn't been
processed correctly. Try direct command after reboot, if possible
 - If no, lets continue with patch creation based on the master branch

Cheers,
Andrej

On Thu, 2022-01-27 at 14:39 +, Bryan Evenson wrote:
> Andrej,
> 
> > -Original Message-
> > From: Valek, Andrej 
> > Sent: Saturday, January 22, 2022 2:26 AM
> > To: openembedded-core@lists.openembedded.org; Bryan Evenson
> > 
> > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary
> > busybox
> > links during install
> > 
> > Hello again,
> > 
> > Maybe a general question. Is it working in current master? I do not
> > want to
> > brake dunfell, just applying something, which will create a lot of
> > divergence.
> > 
> 
> I wasn't able to build an image based on the latest master as of
> Monday.  From the error messages I think it had something to do with
> the addition of setuptools3-base that wasn't complete yet.  I was
> able to build and run an image based on the latest honister branch. 
> The master branch has four commits for busybox that honsiter does not
> have.  In those four commits, I see no changes to any of the
> installation steps.  Based on this information, I'd say its safe to
> say that testing on the latest honister branch should confirm whether
> the problem is still present or not.
> 
> To test, I first built my image and directly programmed it on my
> hardware.  My image is based upon core-image-minimal, uses sysvinit
> for an init system and opkg for a package manager.  I have also added
> bash, cronie, dhcpcd and util-linux to my image; I've added others
> but these seem to produce the most obvious errors.
> 
> After programming the image on my hardware, I added PR="r1" to the
> gcc recipe.  This forced all the packages to get rebuilt and
> increment the version number (if anyone knows a simpler way to
> accomplish this, let me know).  I then created a package feed with
> this update and attempted an upgrade.
> 
> To upgrade, I did:
> opkg update
> opkg --download-only upgrade
> opkg upgrade > full_upgrade.txt 2>&1 &
> 
> I download all the packages to be upgraded first.  I then sent the
> upgrade process to the background so I could check other things
> during the upgrade process.
> 
> During the upgrade, I would occasionally execute "ls -l" to verify
> that the file full_upgrade.txt existed and was still growing.  About
> a minute into the upgrade process when I executed "ls -l" I got the
> error message:
> 
> ls: not found
> 
> From that point on until upgrade was complete I had to execute
> "busybox ls -l" to see the current directory file list.  After
> upgrade was complete, I checked full_upgrade.txt for error messages. 
> I saw the following:
> 
> /usr/bin/update-alternatives: line 1: sed: not found  (occurred 102
> times)
> /usr/sbin/update-rc.d: line 54: rm: not found (occurred 36 times)
> Stopping crond: /etc/init.d/crond: line 37: start-stop-daemon: not
> found
> /tmp/opkg-yBH1Ta/cronie-zHpym4/preinst: line 1: tr: not found
> /etc/init.d/udev: line 74: start-stop-daemon: not found
> /tmp/opkg-yBH1Ta/dhcpcd-c86ca9/preinst: line 1: tr: not found
> 
> In this case, a lot of alternatives and init scripts may not be setup
> correctly because either the old ones were not removed or the new
> ones were not installed.  Prior to my patch below, I saw similar
> errors when upgrading my image from a build based off the morty
> branch to one based off dunfell (and my system was not operational
> after the upgrade).  After my patch, I performed the same upgrade
> with no errors and my system was fully operational.
> 
> I'm up for any thoughts on a different approach that accomplishes the
> same goal.  Otherwise, I'm going to work with what I have and update
> my changes so they patch cleanly on master.
> 
> Thanks,
> Bryan
> 
> > Cheers,
> > Andrej
> > 
> > On Fri, 2022-01-21 at 15:02 +, Bryan Evenson wrote:
> > > Andrej,
> > > 
> > > Thanks for the response.  This is an attempt to fix a problem I
> > > am
> > > having with automated firmware upgrades for my system.  I am
> > > using
> > > opkg for a package manager; not sure if the same problem exists
> > > with
> > > other package managers.  I run into problems whenever busybox is
> > > one
> > > of the packages that needs to get updated.  I enact my
> > > distribution
> > > firmware upgrade by calling "opkg --download-only upgrade; opkg
> > > upgrade".  What I see happen is:
> > > 
> > > 1. In the busybox pkg_prerm stage sets up some soft links for
> > > some
> > > common applets in a temporary directory and exports a path to
> > > that
> > > directory.  It might also setup a temporary alternative to
> > > /bin/sh if
> > > it is the last shell.
> > > 2. After the remove stage, the busybox binary is gone.  The
> > > softlinks
> > > created in the prerm 

Re: [OE-core] About the sstate cache directory hierarchy

[Alexander Kanavin]

I do like the idea; not everyone has a pcie gen4/5 ssd for builds, or
rigorously trims sstate on a schedule. But there may be consequences or
regressions, maybe RP will immediately shoot it down :)

I would however still place a single level of hash[:2] *under* the
pn/task/, to avoid too many files piling up in a single directory.

Can you send this as an RFC patch?

Alex

On Fri, 28 Jan 2022 at 08:06, Chen Qi  wrote:

> Hi All,
>
> I'm sending out this email because I'm wondering if we can change the
> sstate cache directory to use ${PN} and taskname as subditories. Hope to
> hear your opinions.
>
> Below is the long story.
>
> Recently I noticed that running `bitbake xxx -c cleansstate' usually
> takes more than 10 minutes.
>
> After some investigation, I can see that most of the time is spent on
> file searching. This is because we have:
>
> SSTATE_PATHSPEC   =
>
> "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}${PN}/${SSTATE_PATH_CURRTASK}/${SSTATE_PKGSPEC}*_${SSTATE_PATH_CURRTASK}.tar.zst*"
>
> And our sstate cache directory's hierarchy uses hash[:2]/hash[2:4]/ as
> sub-directories.
>
> This essentially means that all sub-directories are searched. This would
> take a long time, especially when run for the first time. I made some
> changes to  output the time and the logs are as below.
>
> $ bitbake glibc -c cleansstate
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_deploy_source_date_epoch.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 611.8865714073181 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_package.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.3219327926635742 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_package_qa.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.470815658569336 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_package_write_rpm.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.251939058303833 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_packagedata.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.2369801998138428 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc::2.34:r0::7:*_populate_lic.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.1668426990509033 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_populate_sysroot.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.385568380355835 seconds
> WARNING: glibc-2.34-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/*/*/sstate:glibc:core2-64-poky-linux:2.34:r0:core2-64:7:*_stash_locale.tar.zst*
> WARNING: glibc-2.34-r0 do_cleansstate: Took 1.4884181022644043 seconds
>
> I figured that unlike git, we do have knowledge on our sstate objects.
> It does not seem necessary to use hash value as sub directory. So I
> changed the sstate directory hierarchy to use ${PN}/taskname/ as sub
> directories, and here's the result.
>
> $ bitbake libgcc -c cleansstate
>
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/libgcc/deploy_source_date_epoch/sstate:libgcc:core2-64-poky-linux:11.2.0:r0:core2-64:7:*_deploy_source_date_epoch.tar.zst*
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Took 0.020630598068237305 seconds
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/libgcc/package/sstate:libgcc:core2-64-poky-linux:11.2.0:r0:core2-64:7:*_package.tar.zst*
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Took 0.0011608600616455078
> seconds
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/libgcc/package_qa/sstate:libgcc:core2-64-poky-linux:11.2.0:r0:core2-64:7:*_package_qa.tar.zst*
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Took 0.0007557868957519531
> seconds
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Removing
>
> /ala-lpggp72/qichen/LAT/builds/share/sstate-cache/libgcc/package_write_rpm/sstate:libgcc:core2-64-poky-linux:11.2.0:r0:core2-64:7:*_package_write_rpm.tar.zst*
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Took 0.0013995170593261719
> seconds
> WARNING: libgcc-11.2.0-r0 do_cleansstate: Removing
>
> 

[OE-core][PATCH] oeqa: qemu: create missing directory for _write_dump

[Andrej Valek]

| Failed to dump QMP CMD: query-status with
| Exception: [Errno 2] No such file or directory: 
'.../tmp/log/runtime-hostdump/qmp_00_query-status'
| Failed to dump QMP CMD: query-block with
| Exception: [Errno 2] No such file or directory: 
'.../tmp/log/runtime-hostdump/qmp_00_query-block'
| Failed to dump QMP CMD: dump-guest-memory with
| Exception: [Errno 2] No such file or directory: 
'.../tmp/log/runtime-hostdump/qmp_00_dump-guest-memory'

The qmp dump commands could fail, because of missing root directory.
So create it before any log writing.

Signed-off-by: Andrej Valek 
---
 meta/lib/oeqa/utils/dump.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/utils/dump.py b/meta/lib/oeqa/utils/dump.py
index dc8757807e..95a79a571c 100644
--- a/meta/lib/oeqa/utils/dump.py
+++ b/meta/lib/oeqa/utils/dump.py
@@ -66,6 +66,7 @@ class BaseDumper(object):
 
 def _write_dump(self, command, output):
 fullname = self._construct_filename(command)
+os.makedirs(os.path.dirname(fullname), exist_ok=True)
 if isinstance(self, MonitorDumper):
 with open(fullname, 'w') as json_file:
 json.dump(output, json_file, indent=4)
-- 
2.34.1


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

[OE-core] [PATCH] mdadm: fix testcase 00multipath failure

[Changqing Li]

From: Changqing Li 

After upgrade to 4.2, mdadm's testcase 00multipath failed,
because a bug in 4.2 makes "-r" not work in manage mode.

Signed-off-by: Changqing Li 
---
 ...parsing-of-r-in-monitor-manager-mode.patch | 74 +++
 meta/recipes-extended/mdadm/mdadm_4.2.bb  |  1 +
 2 files changed, 75 insertions(+)
 create mode 100644 
meta/recipes-extended/mdadm/files/0001-Fix-parsing-of-r-in-monitor-manager-mode.patch

diff --git 
a/meta/recipes-extended/mdadm/files/0001-Fix-parsing-of-r-in-monitor-manager-mode.patch
 
b/meta/recipes-extended/mdadm/files/0001-Fix-parsing-of-r-in-monitor-manager-mode.patch
new file mode 100644
index 00..3fb46cc60a
--- /dev/null
+++ 
b/meta/recipes-extended/mdadm/files/0001-Fix-parsing-of-r-in-monitor-manager-mode.patch
@@ -0,0 +1,74 @@
+From 969fbb35e40100f599d4a9781911251f21792698 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Thu, 27 Jan 2022 17:53:01 +0800
+Subject: [PATCH] Fix parsing of "-r" in monitor/manager mode
+
+This revert commit 546047688e1 [mdadm: fix coredump of mdadm --monitor
+-r], and fix the coredump issue of 'mdadm --monitor -r'.
+
+commit 546047688e1 make -r not work in manager mode, and testcase
+00multipath failed.
+
+Upstream-Status: Submitted [send to maintainer jsoren...@fb.com]
+
+Signed-off-by: Changqing Li 
+
+---
+ ReadMe.c | 8 +---
+ mdadm.c  | 2 ++
+ mdadm.h  | 1 +
+ 3 files changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/ReadMe.c b/ReadMe.c
+index 8139976..070eea5 100644
+--- a/ReadMe.c
 b/ReadMe.c
+@@ -81,11 +81,13 @@ char Version[] = "mdadm - v" VERSION " - " VERS_DATE 
EXTRAVERSION "\n";
+  * found, it is started.
+  */
+ 
+-char 
short_options[]="-ABCDEFGIQhVXYWZ:vqbc:i:l:p:m:r:n:x:u:c:d:z:U:N:safRSow1tye:k";
++char 
short_options[]="-ABCDEFGIQhVXYWZ:vqbc:i:l:p:m:n:x:u:c:d:z:U:N:sarfRSow1tye:k:";
+ char short_bitmap_options[]=
+-  
"-ABCDEFGIQhVXYWZ:vqb:c:i:l:p:m:r:n:x:u:c:d:z:U:N:sarfRSow1tye:k:";
++  
"-ABCDEFGIQhVXYWZ:vqb:c:i:l:p:m:n:x:u:c:d:z:U:N:sarfRSow1tye:k:";
+ char short_bitmap_auto_options[]=
+-  
"-ABCDEFGIQhVXYWZ:vqb:c:i:l:p:m:r:n:x:u:c:d:z:U:N:sa:rfRSow1tye:k:";
++  
"-ABCDEFGIQhVXYWZ:vqb:c:i:l:p:m:n:x:u:c:d:z:U:N:sa:rfRSow1tye:k:";
++char short_increment_options[]=
++  
"-ABCDEFGIQhVXYWZ:vqbc:i:l:r:p:m:n:x:u:c:d:z:U:N:safRSow1tye:k:";
+ 
+ struct option long_options[] = {
+ {"manage",0, 0, ManageOpt},
+diff --git a/mdadm.c b/mdadm.c
+index 26299b2..2a3b2ee 100644
+--- a/mdadm.c
 b/mdadm.c
+@@ -227,6 +227,7 @@ int main(int argc, char *argv[])
+   shortopt = short_bitmap_auto_options;
+   break;
+   case 'F': newmode = MONITOR;
++  shortopt = short_increment_options;
+   break;
+   case 'G': newmode = GROW;
+   shortopt = short_bitmap_options;
+@@ -268,6 +269,7 @@ int main(int argc, char *argv[])
+ 
+   case NoSharing:
+   newmode = MONITOR;
++  shortopt = short_increment_options;
+   break;
+   }
+   if (mode && newmode == mode) {
+diff --git a/mdadm.h b/mdadm.h
+index ecfc137..42148dd 100644
+--- a/mdadm.h
 b/mdadm.h
+@@ -421,6 +421,7 @@ enum mode {
+ extern char short_options[];
+ extern char short_bitmap_options[];
+ extern char short_bitmap_auto_options[];
++extern char short_increment_options[];
+ extern struct option long_options[];
+ extern char Version[], Usage[], Help[], OptionHelp[],
+   *mode_help[],
diff --git a/meta/recipes-extended/mdadm/mdadm_4.2.bb 
b/meta/recipes-extended/mdadm/mdadm_4.2.bb
index fa51364283..e3bbb4cf33 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.2.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.2.bb
@@ -22,6 +22,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \

file://0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch \
file://include_sysmacros.patch \
file://0001-mdadm-skip-test-11spare-migration.patch \
+   file://0001-Fix-parsing-of-r-in-monitor-manager-mode.patch \
"
 
 SRC_URI[sha256sum] = 
"461c215670864bb74a4d1a3620684aa2b2f8296dffa06743f26dda5557acf01d"
-- 
2.17.1


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

[OE-core] [dunfell][PATCH v4] ghostscript: fix CVE-2021-45949

[Minjae Kim]

Ghostscript GhostPDL 9.50 through 9.54.0 has a heap-based buffer overflow in 
sampled_data_finish
(called from sampled_data_continue and interp).

To apply this CVE-2021-45959 patch,
the check-stack-limits-after-function-evalution.patch should be applied first.

References:
https://nvd.nist.gov/vuln/detail/CVE-2021-45949

Signed-off-by: Minjae Kim 
---
 .../ghostscript/CVE-2021-45949.patch  | 65 +++
 ...tack-limits-after-function-evalution.patch | 51 +++
 .../ghostscript/ghostscript_9.52.bb   |  2 +
 3 files changed, 118 insertions(+)
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/check-stack-limits-after-function-evalution.patch

diff --git a/meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch
new file mode 100644
index 00..f312f89e04
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch
@@ -0,0 +1,65 @@
+From 6643ff0cb837db3eade48921e3e92eee2ae0 Mon Sep 17 00:00:00 2001
+From: Chris Liddell 
+Date: Fri, 28 Jan 2022 08:21:19 +
+Subject: [PATCH] [PATCH] Bug 703902: Fix op stack management in
+ sampled_data_continue()
+
+Replace pop() (which does no checking, and doesn't handle stack extension
+blocks) with ref_stack_pop() which does do all that.
+
+We still use pop() in one case (it's faster), but we have to later use
+ref_stack_pop() before calling sampled_data_sample() which also accesses the
+op stack.
+
+Fixes:
+https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34675
+
+Upstream-Status: Backported 
[https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=2a3129365d3bc0d4a41f107ef175920d1505d1f7]
+CVE: CVE-2021-45949
+Signed-off-by: Minjae Kim 
+---
+ psi/zfsample.c | 13 -
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/psi/zfsample.c b/psi/zfsample.c
+index 0023fa4..f84671f 100644
+--- a/psi/zfsample.c
 b/psi/zfsample.c
+@@ -534,14 +534,17 @@ sampled_data_continue(i_ctx_t *i_ctx_p)
+ data_ptr[bps * i + j] = (byte)(cv >> ((bps - 1 - j) * 8));
/* MSB first */
+ }
+ pop(num_out); /* Move op to base of result values */
+-
++/* From here on, we have to use ref_stack_pop() rather than pop()
++   so that it handles stack extension blocks properly, before calling
++   sampled_data_sample() which also uses the op stack.
++*/
+ /* Check if we are done collecting data. */
+ 
+ if (increment_cube_indexes(params, penum->indexes)) {
+ if (stack_depth_adjust == 0)
+-pop(O_STACK_PAD); /* Remove spare stack space */
++  ref_stack_pop(_stack, O_STACK_PAD); /* Remove spare stack 
space */
+ else
+-pop(stack_depth_adjust - num_out);
++ref_stack_pop(_stack, stack_depth_adjust - num_out);
+ /* Execute the closing procedure, if given */
+ code = 0;
+ if (esp_finish_proc != 0)
+@@ -554,11 +557,11 @@ sampled_data_continue(i_ctx_t *i_ctx_p)
+ if ((O_STACK_PAD - stack_depth_adjust) < 0) {
+ stack_depth_adjust = -(O_STACK_PAD - stack_depth_adjust);
+ check_op(stack_depth_adjust);
+-pop(stack_depth_adjust);
++  ref_stack_pop(_stack, stack_depth_adjust);
+ }
+ else {
+ check_ostack(O_STACK_PAD - stack_depth_adjust);
+-push(O_STACK_PAD - stack_depth_adjust);
++  ref_stack_push(_stack, O_STACK_PAD - stack_depth_adjust);
+ for (i=0;i
+Date: Fri, 12 Feb 2021 10:34:23 +
+Subject: [PATCH] oss-fuzz 30715: Check stack limits after function evaluation.
+
+During function result sampling, after the callout to the Postscript
+interpreter, make sure there is enough stack space available before pushing
+or popping entries.
+
+In thise case, the Postscript procedure for the "function" is totally invalid
+(as a function), and leaves the op stack in an unrecoverable state (as far as
+function evaluation is concerned). We end up popping more entries off the
+stack than are available.
+
+To cope, add in stack limit checking to throw an appropriate error when this
+happens.
+
+Upstream-Status: Backported 
[https://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=7861fcad13c497728189feafb41cd57b5b50ea25]
+Signed-off-by: Minjae Kim 
+---
+ psi/zfsample.c | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/psi/zfsample.c b/psi/zfsample.c
+index 290809405..652ae02c6 100644
+--- a/psi/zfsample.c
 b/psi/zfsample.c
+@@ -551,9 +551,17 @@ sampled_data_continue(i_ctx_t *i_ctx_p)
+ } else {
+ if (stack_depth_adjust) {
+ stack_depth_adjust -= num_out;
+-push(O_STACK_PAD - stack_depth_adjust);
+-for 

[OE-core] [dunfell][PATCH v3] ghostscript: fix CVE-2021-45949

[Minjae Kim]

From: Minjae Kim 

Ghostscript GhostPDL 9.50 through 9.54.0 has a heap-based buffer overflow in 
sampled_data_finish
(called from sampled_data_continue and interp).

To apply this CVE-2021-45959 patch,
the check-stack-limits-after-function-evalution.patch should be applied first.

References:
https://nvd.nist.gov/vuln/detail/CVE-2021-45949

Signed-off-by: Minjae Kim 
---
 .../ghostscript/CVE-2021-45949.patch  | 65 +++
 ...tack-limits-after-function-evalution.patch | 51 +++
 .../ghostscript/ghostscript_9.52.bb   |  2 +
 3 files changed, 118 insertions(+)
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/check-stack-limits-after-function-evalution.patch

diff --git a/meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch
new file mode 100644
index 00..f312f89e04
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2021-45949.patch
@@ -0,0 +1,65 @@
+From 6643ff0cb837db3eade48921e3e92eee2ae0 Mon Sep 17 00:00:00 2001
+From: Chris Liddell 
+Date: Fri, 28 Jan 2022 08:21:19 +
+Subject: [PATCH] [PATCH] Bug 703902: Fix op stack management in
+ sampled_data_continue()
+
+Replace pop() (which does no checking, and doesn't handle stack extension
+blocks) with ref_stack_pop() which does do all that.
+
+We still use pop() in one case (it's faster), but we have to later use
+ref_stack_pop() before calling sampled_data_sample() which also accesses the
+op stack.
+
+Fixes:
+https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34675
+
+Upstream-Status: Backported 
[https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=2a3129365d3bc0d4a41f107ef175920d1505d1f7]
+CVE: CVE-2021-45949
+Signed-off-by: Minjae Kim 
+---
+ psi/zfsample.c | 13 -
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/psi/zfsample.c b/psi/zfsample.c
+index 0023fa4..f84671f 100644
+--- a/psi/zfsample.c
 b/psi/zfsample.c
+@@ -534,14 +534,17 @@ sampled_data_continue(i_ctx_t *i_ctx_p)
+ data_ptr[bps * i + j] = (byte)(cv >> ((bps - 1 - j) * 8));
/* MSB first */
+ }
+ pop(num_out); /* Move op to base of result values */
+-
++/* From here on, we have to use ref_stack_pop() rather than pop()
++   so that it handles stack extension blocks properly, before calling
++   sampled_data_sample() which also uses the op stack.
++*/
+ /* Check if we are done collecting data. */
+ 
+ if (increment_cube_indexes(params, penum->indexes)) {
+ if (stack_depth_adjust == 0)
+-pop(O_STACK_PAD); /* Remove spare stack space */
++  ref_stack_pop(_stack, O_STACK_PAD); /* Remove spare stack 
space */
+ else
+-pop(stack_depth_adjust - num_out);
++ref_stack_pop(_stack, stack_depth_adjust - num_out);
+ /* Execute the closing procedure, if given */
+ code = 0;
+ if (esp_finish_proc != 0)
+@@ -554,11 +557,11 @@ sampled_data_continue(i_ctx_t *i_ctx_p)
+ if ((O_STACK_PAD - stack_depth_adjust) < 0) {
+ stack_depth_adjust = -(O_STACK_PAD - stack_depth_adjust);
+ check_op(stack_depth_adjust);
+-pop(stack_depth_adjust);
++  ref_stack_pop(_stack, stack_depth_adjust);
+ }
+ else {
+ check_ostack(O_STACK_PAD - stack_depth_adjust);
+-push(O_STACK_PAD - stack_depth_adjust);
++  ref_stack_push(_stack, O_STACK_PAD - stack_depth_adjust);
+ for (i=0;i
+Date: Fri, 12 Feb 2021 10:34:23 +
+Subject: [PATCH] oss-fuzz 30715: Check stack limits after function evaluation.
+
+During function result sampling, after the callout to the Postscript
+interpreter, make sure there is enough stack space available before pushing
+or popping entries.
+
+In thise case, the Postscript procedure for the "function" is totally invalid
+(as a function), and leaves the op stack in an unrecoverable state (as far as
+function evaluation is concerned). We end up popping more entries off the
+stack than are available.
+
+To cope, add in stack limit checking to throw an appropriate error when this
+happens.
+
+Upstream-Status: Backported 
[https://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=7861fcad13c497728189feafb41cd57b5b50ea25]
+Signed-off-by: Minjae Kim 
+---
+ psi/zfsample.c | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/psi/zfsample.c b/psi/zfsample.c
+index 290809405..652ae02c6 100644
+--- a/psi/zfsample.c
 b/psi/zfsample.c
+@@ -551,9 +551,17 @@ sampled_data_continue(i_ctx_t *i_ctx_p)
+ } else {
+ if (stack_depth_adjust) {
+ stack_depth_adjust -= num_out;
+-push(O_STACK_PAD - stack_depth_adjust);
+-for 

Re: [OE-core] [poky][dunfell][PATCH] libcap: Use specific BSD license variant

[Nisha Parrakat]

hi can this be taken to dunfell branch ?

regards
Nisha

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161070): 
https://lists.openembedded.org/g/openembedded-core/message/161070
Mute This Topic: https://lists.openembedded.org/mt/88657933/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] bitbake.conf: support persistent /var/tmp

[Changqing Li]

On 9/13/21 7:00 PM, Richard Purdie wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Mon, 2021-09-13 at 11:42 +0800, Changqing Li wrote:

ping
On 8/30/21 4:11 PM, Changqing Li wrote:


On 8/6/21 9:21 AM, Changqing Li wrote:


From: Changqing Li 

Steps:
1. build out rootfs core-image-minimal-qemux86-64.tar.bz2
2. docker import core-image-minimal-qemux86-64.tar.bz2 poky:latest
3. docker run -it --rm poky:latest /bin/sh
4.
/var # ls -al
drwxr-xr-x8 root root  4096 Mar  9  2018 .
drwxr-xr-x1 root root  4096 Aug  5 06:59 ..
drwxr-xr-x2 root root  4096 Mar  9  2018 backups
drwxr-xr-x2 root root  4096 Mar  9  2018 cache
drwxr-xr-x5 root root  4096 Mar  9  2018 lib
drwxr-xr-x2 root root  4096 Mar  9  2018 local
lrwxrwxrwx1 root root11 Mar  9  2018 lock ->
../run/lock
lrwxrwxrwx1 root root12 Mar  9  2018 log ->
volatile/log
lrwxrwxrwx1 root root 6 Mar  9  2018 run -> ../run
drwxr-xr-x3 root root  4096 Mar  9  2018 spool
lrwxrwxrwx1 root root12 Mar  9  2018 tmp ->
volatile/tmp
drwxr-xr-x2 root root  4096 Mar  9  2018 volatile
/var # cd log
/bin/sh: cd: can't cd to log: No such file or directory
/var # cd tmp
/bin/sh: cd: can't cd to tmp: No such file or directory
/var # cd volatile/
/var/volatile # ls -al
drwxr-xr-x2 root root  4096 Mar  9  2018 .

Sorry, I appreciate this change hasn't had feedback. Unfortunately I'm finding
this one hard to review. I'm also worried because it changes a number of key
areas of the system init process in a way which looks very tailored to a
specific use case.

I suspect we do need to have some kind of better configuration of this area of
the system but I'm not convinced this patchset does that, it looks more likely
to adversely affect other use cases in favour of a specialist one.

I am unlikely to want to make changes in this area until the next release now,
sorry :/.
This is one of the problems with not having enough people with specialist
knowledge to help review, too much falls to me and I just don't have the time to
dive into each different thing and stand a chance of making the correct
decisions. This is frustrating for everyone.


Hi, Richard

I understand what you said.  And since there are still have 3 months before

3.5 release,  how about consider this patch?  if you have any suggestion, I

can refactor this patch and rebase it to least  master and resend it. 
Thanks.



I rebase this patch to latest master locally and test following scenario:

1.   default VOLATILE_DIR='yes'  + systemd

   /var/log  /var/tmp  link to  /var/volatile correctly

2.  default VOLATILE_DIR='yes'  + sysVinit

      /var/log  /var/tmp  link to  /var/volatile correctly

3.  VOLATILE_DIR='no'  + systemd + image_install:append = " cups"

    /var/log /var/tmp are persistent storage, not link, cups create 
/var/log/cups correctly


4. VOLATILE_DIR='no'  + sysVinit  + image_install:append = " cups"

    /var/log /var/tmp are persistent storage, not lin, cups create 
/var/log/cups correctly


Thanks

Changqing Li



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