Re: [OE-core] [PATCH] externalsrc: Detect code changes in submodules

[Scott Branden via lists.openembedded.org]

This patch, now integrated in master branch of poky, appears to also fix 
this yocto bug:


"Bug 13748 - bitbake doesn't detect changes in code to run do_compile 
when using devtool modify on recipe with destsuffix"

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13748

On 2021-01-27 12:33 a.m., Tomasz Dziendzielski wrote:

The srctree_hash was calculated only from main source directory ignoring
changes in submodules.

[YOCTO #13748]

Use submodule--helper to determine all submodules, and calculate hash
from all git tree objects names combined.

Signed-off-by: Tomasz Dziendzielski 
---
  meta/classes/externalsrc.bbclass | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 7a7d31e311..64e94e3301 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -190,6 +190,7 @@ def srctree_hash_files(d, srcdir=None):
  import shutil
  import subprocess
  import tempfile
+import hashlib
  
  s_dir = srcdir or d.getVar('EXTERNALSRC')

  git_dir = None
@@ -214,7 +215,16 @@ def srctree_hash_files(d, srcdir=None):
  env = os.environ.copy()
  env['GIT_INDEX_FILE'] = tmp_index.name
  subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
-sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir, 
env=env).decode("utf-8")
+git_sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir, 
env=env).decode("utf-8")
+submodule_helper = subprocess.check_output(['git', 'submodule--helper', 
'list'], cwd=s_dir, env=env).decode("utf-8")
+for line in submodule_helper.splitlines():
+module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
+proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir, 
env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")
+sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
  with open(oe_hash_file, 'w') as fobj:
  fobj.write(sha1)
  ret = oe_hash_file + ':True'









smime.p7s
Description: S/MIME Cryptographic Signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147719): 
https://lists.openembedded.org/g/openembedded-core/message/147719
Mute This Topic: https://lists.openembedded.org/mt/80152944/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] libcroco: CVE-2020-12825 Security Advisory

[Khem Raj]

I am also seeing

ERROR: libcroco-native-0.6.13-r0 do_patch: Fuzz detected:

Applying patch CVE-2020-12825.patch
patching file src/cr-parser.c
Hunk #4 succeeded at 799 with fuzz 1.


The context lines in the patches can be updated with devtool:

devtool modify libcroco-native
devtool finish --force-patch-refresh libcroco-native 

On Thu, Jan 21, 2021 at 3:53 AM Ross Burton  wrote:
>
> And a CVE: CVE-2020-12825 tag alongside that too would be good.
>
> Ross
>
> On Thu, 21 Jan 2021 at 10:50, Richard Purdie
>  wrote:
> >
> > On Thu, 2021-01-21 at 14:59 +0800, Wang Mingyu wrote:
> > > References
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12825
> > >
> > > Signed-off-by: Wang Mingyu 
> > > ---
> > >  .../libcroco/libcroco/CVE-2020-12825.patch| 170 ++
> > >  .../libcroco/libcroco_0.6.13.bb   |   2 +
> > >  2 files changed, 172 insertions(+)
> > >  create mode 100644 
> > > meta/recipes-support/libcroco/libcroco/CVE-2020-12825.patch
> > >
> > > diff --git a/meta/recipes-support/libcroco/libcroco/CVE-2020-12825.patch 
> > > b/meta/recipes-support/libcroco/libcroco/CVE-2020-12825.patch
> > > new file mode 100644
> > > index 00..cde0abd676
> > > --- /dev/null
> > > +++ b/meta/recipes-support/libcroco/libcroco/CVE-2020-12825.patch
> > > @@ -0,0 +1,170 @@
> > > +Subject: [PATCH] libcroco: Limit recursion in block and any productions
> > > +
> > > +Signed-off-by:Michael Catanzaro @mcatanzaro
> >
> > Thanks for this, the patch has no Upstream-Status set though? Could you
> > resend with one please?
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147718): 
https://lists.openembedded.org/g/openembedded-core/message/147718
Mute This Topic: https://lists.openembedded.org/mt/79998594/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] security_flags.inc: Use -O with -D_FORTIFY_SOURCE

[Khem Raj]

compiler can only use fortify options when some level of optimization is
on, otherwise it ends up sending some warnings.

warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]

this is usually OK, since -O would be added via CFLAGS to
compiler cmdline in normal compile stages, however during configure
there are problems when CC,CPP,CXX are probed alone in configure tests
which results in above warning, which confuses the configure results and
autotools 2.70+ detects it as error e.g.

configure:17292: error: C preprocessor "riscv32-yoe-linux-clang -target 
riscv32-yoe-linux  -mlittle-endian -mno-relax -Qunused-arguments 
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=format-security 
--sysroot=/mnt/b/yoe/master/build/tmp/work/riscv32-yoe-linux/ndpi/3.4-r0/recipe-sysroot
 -E" fails sanity check
See `config.log' for more details

therefore adding a -O ( which actually is -O1 ) to lcl_maybe_fortify
means we can properly test these configure tests and real -O will
still override -O added here, so overrall behavior improves

Signed-off-by: Khem Raj 
---
 meta/conf/distro/include/security_flags.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index 4e64eb99f9..05253b2df9 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -10,7 +10,7 @@ GCCPIE ?= "--enable-default-pie"
 
 # _FORTIFY_SOURCE requires -O1 or higher, so disable in debug builds as they 
use
 # -O0 which then results in a compiler warning.
-lcl_maybe_fortify ?= 
"${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=2',d)}"
+lcl_maybe_fortify ?= "${@oe.utils.conditional('DEBUG_BUILD','1','','-O 
-D_FORTIFY_SOURCE=2',d)}"
 
 # Error on use of format strings that represent possible security problems
 SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
-- 
2.30.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147717): 
https://lists.openembedded.org/g/openembedded-core/message/147717
Mute This Topic: https://lists.openembedded.org/mt/80425803/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] manifest.py: Add tests to empty image

[Milan Shah]

Hi All,

This is a Gentle reminder to review this patch.

Thanks & Regards,
Milan Shah

On Fri, Jan 22, 2021 at 11:28 AM Milan Shah 
wrote:

> An oe-selftest test is added to ensure
> meta-selftest/recipes-test/images/test-empty-image.bb builds and is empty.
>
> It is just a test that ensures that an empty image has no packages in it
> (i.e. nothing in the manifest)
>
> See [YOCTO #8455] for details.
>
> Signed-off-by: Milan Shah 
> ---
>  meta/lib/oeqa/selftest/cases/manifest.py | 45 
>  1 file changed, 45 insertions(+)
>
> diff --git a/meta/lib/oeqa/selftest/cases/manifest.py
> b/meta/lib/oeqa/selftest/cases/manifest.py
> index 5d13f35468..d9b8612628 100644
> --- a/meta/lib/oeqa/selftest/cases/manifest.py
> +++ b/meta/lib/oeqa/selftest/cases/manifest.py
> @@ -162,3 +162,48 @@ class VerifyManifest(OESelftestTestCase):
>  self.logger.debug(logmsg)
>  self.logger.info(msg)
>  self.fail(logmsg)
> +
> +class VerifyEmptyManifest(OESelftestTestCase):
> +'''Tests for the manifest files of an empty image'''
> +
> +@classmethod
> +def setUpClass(self):
> +
> +# the setup should bitbake test-empty-image
> +super(VerifyEmptyManifest, self).setUpClass()
> +self.buildtarget = 'test-empty-image'
> +self.classname = 'VerifyEmptyManifest'
> +
> +self.logger.info("{}: doing bitbake {} as a prerequisite of the
> test"\
> +.format(self.classname, self.buildtarget))
> +if bitbake(self.buildtarget).status:
> +self.logger.debug("{} Failed to setup {}"\
> +.format(self.classname, self.buildtarget))
> +self.skipTest("{}: Cannot setup testing scenario"\
> +.format(self.classname))
> +
> +
> +@classmethod
> +def test_image_manifest_empty(self):
> +'''Verifying the image manifest file is empty, this may take a
> build'''
> +
> +# get manifest location based on target to query about
> +try:
> +mdir = VerifyManifest.get_dir_from_bb_var('DEPLOY_DIR_IMAGE',
> +self.buildtarget)
> +mfilename = get_bb_var("IMAGE_LINK_NAME", self.buildtarget)\
> ++ ".manifest"
> +mpath = os.path.join(mdir, mfilename)
> +self.logger.info("Manifest file path is: {}" .format(mpath))
> +
> +if not os.path.isfile(mpath): raise IOError
> +if not os.path.getsize(mpath) == 0: raise OSError
> +
> +except OSError:
> +raise self.skipTest("{}: manifest file is not empty"\
> +.format(self.classname))
> +
> +except IOError:
> +msg = "{}: Error cannot find manifests in dir:\n{}"\
> +.format(self.classname, mdir)
> +self.fail(msg)
> --
> 2.25.1
>
>

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

[OE-core] [PATCH] yocto-uninative.inc: version 2.11 updates glibc to 2.33

[Michael Halstead]

Support glibc 2.33.

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

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 69b6edee5f..bc47083978 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -6,9 +6,9 @@
 # to the distro running on the build machine.
 #
 
-UNINATIVE_MAXGLIBCVERSION = "2.32"
+UNINATIVE_MAXGLIBCVERSION = "2.33"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.9/;
-UNINATIVE_CHECKSUM[aarch64] ?= 
"9f25a667aee225b1dd65c4aea73e01983e825b1cb9b56937932a1ee328b45f81"
-UNINATIVE_CHECKSUM[i686] ?= 
"cae5d73245d95b07cf133b780ba3f6c8d0adca3ffc4e7e7fab61d5e24d36"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"d07916b95c419c81541a19c8ef0ed8cbd78ae18437ff28a4c8a60ef40518e423"
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.11/;
+UNINATIVE_CHECKSUM[aarch64] ?= 
"fa703e25c26eaebb1afd895337b92a24cc5077818e093af74912e53846a117fe"
+UNINATIVE_CHECKSUM[i686] ?= 
"638901c990ffbe716a34400134a2ad49a1c3104e3b48cdafd6fcd28e9b133294"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"047ddd78d6b5cabd2a102120e27755a9eaa1d5724c6a8f4007daa3f10ecb6871"
-- 
2.29.2


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

[Michael Halstead]

Final glibc 2.32 based uninative.

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

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 69b6edee5f..85336014b1 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -8,7 +8,7 @@
 
 UNINATIVE_MAXGLIBCVERSION = "2.32"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.9/;
-UNINATIVE_CHECKSUM[aarch64] ?= 
"9f25a667aee225b1dd65c4aea73e01983e825b1cb9b56937932a1ee328b45f81"
-UNINATIVE_CHECKSUM[i686] ?= 
"cae5d73245d95b07cf133b780ba3f6c8d0adca3ffc4e7e7fab61d5e24d36"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"d07916b95c419c81541a19c8ef0ed8cbd78ae18437ff28a4c8a60ef40518e423"
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.10/;
+UNINATIVE_CHECKSUM[aarch64] ?= 
"645e5c50b2b48aabb8b10f783a9f94b4b7c5ddc7cfceb5386d43b86d30253202"
+UNINATIVE_CHECKSUM[i686] ?= 
"233e09b5ff30e15341232a0c16fa8448ff31dccb8f3f3e2ad3948cdac8c4a598"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"04333677f81990ce2cf55c3bc256cd84a66085d18fc95ccddfab8581e4aec014"
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147714): 
https://lists.openembedded.org/g/openembedded-core/message/147714
Mute This Topic: https://lists.openembedded.org/mt/80423223/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] externalsrc: Detect code changes in submodules

[Jon Mason]

On Thu, Feb 4, 2021 at 10:43 PM Douglas via lists.openembedded.org
 wrote:
>
> Further to 50ff9afb39, only detect code changes in submodules that are
> subdirectories of the EXTERNALSRC directory.
>
> Signed-off-by: Douglas Royds 
> ---

I believe this patch is causing errors in the autobuilder.  See
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1801/steps/14/logs/stdio

>  meta/classes/externalsrc.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/externalsrc.bbclass 
> b/meta/classes/externalsrc.bbclass
> index 64e94e3301..27496bb2db 100644
> --- a/meta/classes/externalsrc.bbclass
> +++ b/meta/classes/externalsrc.bbclass
> @@ -216,7 +216,7 @@ def srctree_hash_files(d, srcdir=None):
>  env['GIT_INDEX_FILE'] = tmp_index.name
>  subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
> env=env)
>  git_sha1 = subprocess.check_output(['git', 'write-tree'], 
> cwd=s_dir, env=env).decode("utf-8")
> -submodule_helper = subprocess.check_output(['git', 
> 'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
> +submodule_helper = subprocess.check_output(['git', 
> 'submodule--helper', 'list', s_dir], cwd=s_dir, env=env).decode("utf-8")
>  for line in submodule_helper.splitlines():
>  module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
>  proc = subprocess.Popen(['git', 'add', '-A', '.'], 
> cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147713): 
https://lists.openembedded.org/g/openembedded-core/message/147713
Mute This Topic: https://lists.openembedded.org/mt/80398669/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] [gatesgarth][PATCH 00/25] pull request

[Richard Purdie]

On Fri, 2021-02-05 at 09:33 +0800, Anuj Mittal wrote:
> Richard Purdie (3):
>   gobject-introspection: Fix variable override order
>   pseudo: Update to include passwd and file renaming fixes
>   image_types: Ensure tar archives are reproducible

I merged this apart from the image_types one from me above since there
is a fix for it in master which probably needs to go with it. Could you
include the fix along with it in the next pull request please?

Thanks,

Richard


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

[OE-core] Sudo CVE-2021-3156 -- was Re: [yocto-security] OE-core CVE metrics for master on Sun 31 Jan 2021 07:15:01 AM HST

[Mark Hatle]

I didn't see Sudo issue CVE-2021-3156 in any of the unpatched lists.

>From a quick look, it appears to be that Master is patched (package is new
enough), but Gatesgarth and older are not.

So with the next set, we should check if it shows up in the unpatched set.

--Mark

On 1/31/21 11:18 AM, Steve Sakoman wrote:
> Branch: master
> 
> New this week:
> 
> Removed this week:
> 
> Full list:  Found 59 unpatched CVEs

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147711): 
https://lists.openembedded.org/g/openembedded-core/message/147711
Mute This Topic: https://lists.openembedded.org/mt/80414861/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] image_types.bbclass: tar: use posix format instead of gnu

[Martin Jansa]

* gnu isn't compatible with  --xattrs used e.g. here:
https://github.com/advancedtelematic/meta-updater/blob/d3a832f66e8802cb45536ff278d5c77f946d341d/classes/image_types_ostree.bbclass#L16
causing do_image_tar failing with:

| tar: --xattrs can be used only on POSIX archives
| Try 'tar --help' or 'tar --usage' for more information.

* https://www.gnu.org/software/tar/manual/html_chapter/tar_8.html
  says about posix format:

  This is the most flexible and feature-rich format.
  It does not impose any restrictions on file sizes or file name lengths.
  This format is quite recent, so not all tar implementations are able to 
handle it properly.
  However, this format is designed in such a way that any tar implementation 
able to read `ustar'
  archives will be able to read most `posix' archives as well, with the only 
exception that any
  additional information (such as long file names etc.) will in such case be 
extracted as plain
  text files along with the files it refers to.

  This archive format will be the default format for future versions of GNU tar.

  and:

  The default format for GNU tar is defined at compilation time.
  You may check it by running tar --help, and examining the last lines of its 
output.
  Usually, GNU tar is configured to create archives in `gnu' format, however, 
future version will switch to `posix'.

* I've compared tar on centos7 and ubuntu-18.04:

bash-4.2$ cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)

bash-4.2$ tar --version
tar (GNU tar) 1.26
...

bash-4.2$ tar --help | tail -n 5
*This* tar defaults to:
--format=gnu -f- -b20 --quoting-style=escape --rmt-command=/etc/rmt
--rsh-command=/usr/bin/ssh
...

bitbake@e0ee76f81c2f:/$ grep VERSION /etc/os-release
VERSION="18.04.5 LTS (Bionic Beaver)"
VERSION_ID="18.04"
VERSION_CODENAME=bionic

bitbake@e0ee76f81c2f:/$ tar --version
tar (GNU tar) 1.29
...

bitbake@e0ee76f81c2f:/$ tar --help | tail -n 5
...
*This* tar defaults to:
--format=gnu -f- -b20 --quoting-style=escape --rmt-command=/usr/lib/tar/rmt
--rsh-command=/usr/bin/rsh

Both support posix format (as pax POSIX 1003.1-2001). But centos7 version is
already too old anyway, because it doesn't support --sort=name used since:
https://git.openembedded.org/openembedded-core/commit/?id=4fa68626bbcfd9795577e1426c27d00f4d9d1c17
and
https://git.openembedded.org/openembedded-core/commit/?id=f19e43dec63a86c200e04ba14393583588550380
says that 1.28 is the minium version now and
https://git.openembedded.org/openembedded-core/commit/?id=7a66434cf11b7f051699b774e4fccd6738351368
recommends to use install-buildtools for hosts with tar < 1.28

On the other side latest tumbleweed from:
https://hub.docker.com/r/opensuse/tumbleweed
with tar-1.33 alredy defaults to posix format:

b99dbb3d86dd:/ # head -n 3 /etc/os-release
NAME="openSUSE Tumbleweed"
ID="opensuse-tumbleweed"

b99dbb3d86dd:/ # tar --version
tar (GNU tar) 1.33
...

b99dbb3d86dd:/ # tar --help | tail -n 3
*This* tar defaults to:
--format=posix -f- -b20 --quoting-style=escape --rmt-command=/usr/bin/rmt
--rsh-command=/usr/bin/ssh

I've packaged some sample rootfs directory with both tars and the result is
identical (with --format=gnu as well as --format=posix).

with ubuntu:
tar --sort=name --format=gnu --numeric-owner -cf rootfs.ubuntu.gnu.tar -C 
rootfs .
tar --xattrs --xattrs-include=* --sort=name --format=posix --numeric-owner -cf 
rootfs.ubuntu.posix.tar -C rootfs .
tumbleweed:
tar --sort=name --format=gnu --numeric-owner -cf rootfs.tumbleweed.gnu.tar -C 
rootfs .
tar --xattrs --xattrs-include=* --sort=name --format=posix --numeric-owner -cf 
rootfs.tumbleweed.posix.tar -C rootfs .
centos7 (without --sort=name):
tar --format=gnu --numeric-owner -cf rootfs.centos7.gnu.tar -C rootfs .
tar --xattrs --xattrs-include=* --format=posix --numeric-owner -cf 
rootfs.centos7.posix.tar -C rootfs .

size is identical:
-rw-r--r-- 1 mjansa mjansa 2487480320 Feb  5 09:19 rootfs.ubuntu.gnu.tar
-rw-r--r-- 1 mjansa mjansa 2487480320 Feb  5 10:17 rootfs.centos7.gnu.tar
-rw-r--r-- 1 mjansa mjansa 2487480320 Feb  5 10:26 rootfs.tumbleweed.gnu.tar
-rw-r--r-- 1 mjansa mjansa 2579875840 Feb  5 10:15 rootfs.ubuntu.posix.tar
-rw-r--r-- 1 mjansa mjansa 2579875840 Feb  5 10:16 rootfs.centos7.posix.tar
-rw-r--r-- 1 mjansa mjansa 2579875840 Feb  5 10:26 rootfs.tumbleweed.posix.tar

but md5s aren't:
5e3880283379dd773ac054e20562fdea  rootfs.centos7.gnu.tar
abeaf992c780aa780a27be01365d26f5  rootfs.centos7.posix.tar
0c6ee59d87ab56583293262de110bca4  rootfs.tumbleweed.gnu.tar
1555bc7276eaba924bf82a13a010fd6d  rootfs.tumbleweed.posix.tar
553d802bba351e273191bd5b2a621b66  rootfs.ubuntu.gnu.tar
b6d7b43b30174686f6625ba3c7aefdc6  rootfs.ubuntu.posix.tar

diffoscope shows some differences when using gnu format:

$ diffoscope rootfs.tumbleweed.gnu.tar rootfs.ubuntu.gnu.tar
...
-00239890: 3030 3000 3030 3737 3637 0020 4b00   000.007767. K...
+00239890: 3030 3000 3031 3135 3737 0020 4b00   000.011577. K...
...
-00239900: 0075 7374 6172 2020   

[OE-core] [poky][master][dunfell][gatesgarth][PATCH v2] libcroco: Added CVE

[saloni]

Added below CVE:
CVE-2020-12825
Link: CVE-2020-12825 
[https://gitlab.gnome.org/Archive/libcroco/-/commit/6eb257e5c731c691eb137fca94e916ca73941a5a]
Link: https://gitlab.gnome.org/Archive/libcroco/-/issues/8

Signed-off-by: Saloni Jain 
---
 .../libcroco/files/CVE-2020-12825.patch| 193 +
 meta/recipes-support/libcroco/libcroco_0.6.13.bb   |   3 +
 2 files changed, 196 insertions(+)
 create mode 100644 meta/recipes-support/libcroco/files/CVE-2020-12825.patch

diff --git a/meta/recipes-support/libcroco/files/CVE-2020-12825.patch 
b/meta/recipes-support/libcroco/files/CVE-2020-12825.patch
new file mode 100644
index 000..add6f84
--- /dev/null
+++ b/meta/recipes-support/libcroco/files/CVE-2020-12825.patch
@@ -0,0 +1,193 @@
+From 6eb257e5c731c691eb137fca94e916ca73941a5a Mon Sep 17 00:00:00 2001
+From: Michael Catanzaro 
+Date: Fri, 31 Jul 2020 15:21:53 -0500
+Subject: [PATCH] libcroco: Limit recursion in block and any productions
+ (CVE-2020-12825)
+
+If we don't have any limits, we can recurse forever and overflow the
+stack.
+
+Fixes #8
+This is per https://gitlab.gnome.org/Archive/libcroco/-/issues/8
+
+https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1404
+
+CVE: CVE-2020-12825
+Upstream-Status: Backport 
[https://gitlab.gnome.org/Archive/libcroco/-/commit/6eb257e5c731c691eb137fca94e916ca73941a5a]
+Comment: No refreshing changes done.
+Signed-off-by: Saloni Jain 
+---
+ src/cr-parser.c | 44 +---
+ 1 file changed, 29 insertions(+), 15 deletions(-)
+
+diff --git a/src/cr-parser.c b/src/cr-parser.c
+index 18c9a01..f4a62e3 100644
+--- a/src/cr-parser.c
 b/src/cr-parser.c
+@@ -136,6 +136,8 @@ struct _CRParserPriv {
+
+ #define CHARS_TAB_SIZE 12
+
++#define RECURSIVE_CALLERS_LIMIT 100
++
+ /**
+  * IS_NUM:
+  *@a_char: the char to test.
+@@ -344,9 +346,11 @@ static enum CRStatus cr_parser_parse_selector_core 
(CRParser * a_this);
+
+ static enum CRStatus cr_parser_parse_declaration_core (CRParser * a_this);
+
+-static enum CRStatus cr_parser_parse_any_core (CRParser * a_this);
++static enum CRStatus cr_parser_parse_any_core (CRParser * a_this,
++   guint  n_calls);
+
+-static enum CRStatus cr_parser_parse_block_core (CRParser * a_this);
++static enum CRStatus cr_parser_parse_block_core (CRParser * a_this,
++ guint  n_calls);
+
+ static enum CRStatus cr_parser_parse_value_core (CRParser * a_this);
+
+@@ -784,7 +788,7 @@ cr_parser_parse_atrule_core (CRParser * a_this)
+ cr_parser_try_to_skip_spaces_and_comments (a_this);
+
+ do {
+-status = cr_parser_parse_any_core (a_this);
++status = cr_parser_parse_any_core (a_this, 0);
+ } while (status == CR_OK);
+
+ status = cr_tknzr_get_next_token (PRIVATE (a_this)->tknzr,
+@@ -795,7 +799,7 @@ cr_parser_parse_atrule_core (CRParser * a_this)
+ cr_tknzr_unget_token (PRIVATE (a_this)->tknzr,
+   token);
+ token = NULL;
+-status = cr_parser_parse_block_core (a_this);
++status = cr_parser_parse_block_core (a_this, 0);
+ CHECK_PARSING_STATUS (status,
+   FALSE);
+ goto done;
+@@ -930,11 +934,11 @@ cr_parser_parse_selector_core (CRParser * a_this)
+
+ RECORD_INITIAL_POS (a_this, _pos);
+
+-status = cr_parser_parse_any_core (a_this);
++status = cr_parser_parse_any_core (a_this, 0);
+ CHECK_PARSING_STATUS (status, FALSE);
+
+ do {
+-status = cr_parser_parse_any_core (a_this);
++status = cr_parser_parse_any_core (a_this, 0);
+
+ } while (status == CR_OK);
+
+@@ -956,10 +960,12 @@ cr_parser_parse_selector_core (CRParser * a_this)
+  *in chapter 4.1 of the css2 spec.
+  *block ::= '{' S* [ any | block | ATKEYWORD S* | ';' ]* '}' S*;
+  *@param a_this the current instance of #CRParser.
++ *@param n_calls used to limit recursion depth
+  *FIXME: code this function.
+  */
+ static enum CRStatus
+-cr_parser_parse_block_core (CRParser * a_this)
++cr_parser_parse_block_core (CRParser * a_this,
++guint  n_calls)
+ {
+ CRToken *token = NULL;
+ CRInputPos init_pos;
+@@ -967,6 +973,9 @@ cr_parser_parse_block_core (CRParser * a_this)
+
+ g_return_val_if_fail (a_this && PRIVATE (a_this), CR_BAD_PARAM_ERROR);
+
++if (n_calls > RECURSIVE_CALLERS_LIMIT)
++return CR_ERROR;
++
+ RECORD_INITIAL_POS (a_this, _pos);
+
+ status = cr_tknzr_get_next_token (PRIVATE (a_this)->tknzr, );
+@@ -996,13 +1005,13 @@ cr_parser_parse_block_core (CRParser * a_this)
+ } else if (token->type == CBO_TK) {
+ cr_tknzr_unget_token (PRIVATE (a_this)->tknzr, token);
+ token = NULL;
+-

[OE-core] [poky][master][dunfell][gatesgarth][PATCH v3] libgcrypt: Whitelisted CVEs

[saloni]

Whitelisted below CVEs:

1. CVE-2018-12433
Link: https://security-tracker.debian.org/tracker/CVE-2018-12433
Link: https://nvd.nist.gov/vuln/detail/CVE-2018-12433
CVE-2018-12433 is marked disputed and ignored by NVD as it does
not impact crypt libraries for any distros and hence, can be safely
marked whitelisted.

2. CVE-2018-12438
Link: https://security-tracker.debian.org/tracker/CVE-2018-12438
Link: https://ubuntu.com/security/CVE-2018-12438
CVE-2018-12438 was reported for affecting openjdk crypt libraries
but there are no details available on which openjdk versions are
affected and does not directly affect libgcrypt or any specific
yocto distributions, hence, can be whitelisted.

Signed-off-by: Saloni Jain 
---
 meta/recipes-support/libgcrypt/libgcrypt_1.8.7.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.7.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.7.bb
index 0cad41d..7db624a 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.7.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.7.bb
@@ -28,6 +28,9 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \
 "
 SRC_URI[sha256sum] = 
"03b70f028299561b7034b8966d7dd77ef16ed139c43440925fe8782561974748"

+# Below whitelisted CVEs are disputed and not affecting crypto libraries for 
any distro.
+CVE_CHECK_WHITELIST += "CVE-2018-12433 CVE-2018-12438"
+
 BINCONFIG = "${bindir}/libgcrypt-config"

 inherit autotools texinfo binconfig-disabled pkgconfig
--
2.7.4

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147708): 
https://lists.openembedded.org/g/openembedded-core/message/147708
Mute This Topic: https://lists.openembedded.org/mt/80408157/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] [poky][dunfell][PATCH v2] libgcrypt: Whitelisted CVEs

[Steve Sakoman]

On Fri, Feb 5, 2021 at 4:09 AM saloni  wrote:
>
> Whitelisted below CVEs:
>
> 1. CVE-2018-12433
> Link: https://security-tracker.debian.org/tracker/CVE-2018-12433
> Link: https://nvd.nist.gov/vuln/detail/CVE-2018-12433
> CVE-2018-12433 is marked disputed and ignored by NVD as it does
> not impact crypt libraries for any distros and hence, can be safely
> marked whitelisted.
>
> 2. CVE-2018-12438
> Link: https://security-tracker.debian.org/tracker/CVE-2018-12438
> Link: https://ubuntu.com/security/CVE-2018-12438
> CVE-2018-12438 was reported for affecting openjdk crypt libraries
> but there are no details available on which openjdk versions are
> affected and does not directly affect libgcrypt or any specific
> yocto distributions, hence, can be whitelisted.

Much better explanation.

I checked and master and gatesgarth are also flagging this issue. So
this will need to go into the master branch first and then backported
to gatesgarth and dunfell taking into account the different versions
of libgcrypt.

> Signed-off-by: Saloni Jain 
> ---
>  meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb 
> b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> index 4e0eb0a..ba3666f 100644
> --- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> +++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> @@ -29,6 +29,9 @@ SRC_URI = 
> "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \
>  SRC_URI[md5sum] = "348cc4601ca34307fc6cd6c945467743"
>  SRC_URI[sha256sum] = 
> "3b4a2a94cb637eff5bdebbcaf46f4d95c4f25206f459809339cdada0eb577ac3"
>
> +# Below whitelisted CVEs are disputed and not affecting Ubuntu and Debian 
> environments.

Could you revise the comment and then resubmit for the master branch
(with backports to gatesgarth and dunfell)?

Thanks,

Steve

> +CVE_CHECK_WHITELIST += "CVE-2018-12433 CVE-2018-12438"
> +
>  BINCONFIG = "${bindir}/libgcrypt-config"
>
>  inherit autotools texinfo binconfig-disabled pkgconfig
> --
> 2.7.4
>
> This message contains information that may be privileged or confidential and 
> is the property of the KPIT Technologies Ltd. It is intended only for the 
> person to whom it is addressed. If you are not the intended recipient, you 
> are not authorized to read, print, retain copy, disseminate, distribute, or 
> use this message or any part thereof. If you receive this message in error, 
> please notify the sender immediately and delete all copies of this message. 
> KPIT Technologies Ltd. does not accept any liability for virus infected mails.
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147707): 
https://lists.openembedded.org/g/openembedded-core/message/147707
Mute This Topic: https://lists.openembedded.org/mt/80405847/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] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-02-2021 15:51, Mike Looijmans via lists.openembedded.org wrote:

On 05-02-2021 15:44, Mittal, Anuj wrote:

On Fri, 2021-02-05 at 15:24 +0100, Mike Looijmans wrote:

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
   Exception: FileExistsError: [Errno 17] File exists: '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15' -> '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Is this not required in master branch? I can't see this change there.


Probably yes, too.

And half the commit message got lost somewhere. I'll try a resend...


Oh weird... Apparently the company mailserver that did that. The version 
on the list is okay, the one in my mailbox lacks the first half of the 
commit text. Same with the v2 mail.



--
Mike Looijmans


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

[OE-core] [PATCH v2] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
  Exception: FileExistsError: [Errno 17] File exists: 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15' -> 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Signed-off-by: Mike Looijmans 
---
v2: Resent, applies to master and gatesgarth

 meta/classes/license_image.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 119c8dfc86..6f478ce22c 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -210,7 +210,8 @@ def license_deployed_manifest(d):
 os.unlink(lic_manifest_symlink_dir)
 
 # create the image dir symlink
-os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
+if lic_manifest_dir != lic_manifest_symlink_dir:
+os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
 
 def get_deployed_dependencies(d):
 """
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147705): 
https://lists.openembedded.org/g/openembedded-core/message/147705
Mute This Topic: https://lists.openembedded.org/mt/80406913/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] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-02-2021 15:44, Mittal, Anuj wrote:

On Fri, 2021-02-05 at 15:24 +0100, Mike Looijmans wrote:

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
   Exception: FileExistsError: [Errno 17] File exists: '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15' -> '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Is this not required in master branch? I can't see this change there.


Probably yes, too.

And half the commit message got lost somewhere. I'll try a resend...


--
Mike Looijmans


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147704): 
https://lists.openembedded.org/g/openembedded-core/message/147704
Mute This Topic: https://lists.openembedded.org/mt/80406266/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] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Anuj Mittal]

On Fri, 2021-02-05 at 15:24 +0100, Mike Looijmans wrote:
> Sometimes (that is, in all my builds) the lic_manifest_dir and
> lic_manifest_symlink_dir end up pointing to the same file, resulting
> in an error like this:
>   Exception: FileExistsError: [Errno 17] File exists: '/.../tmp-
> glibc/deploy/licenses/my-image-tdkz15' -> '/.../tmp-
> glibc/deploy/licenses/my-image-tdkz15'
> 
> First check to see if this is the case before attempting to create
> the link.

Is this not required in master branch? I can't see this change there.

Thanks,

Anuj


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147703): 
https://lists.openembedded.org/g/openembedded-core/message/147703
Mute This Topic: https://lists.openembedded.org/mt/80406266/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] [poky][dunfell][PATCH] libcroco: Added CVE-2020-12825

[Steve Sakoman]

On Fri, Feb 5, 2021 at 3:01 AM saloni  wrote:
>
> Added below CVE:
> CVE-2020-12825
> Link: CVE-2020-12825 
> [https://gitlab.gnome.org/Archive/libcroco/-/commit/6eb257e5c731c691eb137fca94e916ca73941a5a]
> Link: https://gitlab.gnome.org/Archive/libcroco/-/issues/8
>
> Signed-off-by: Saloni Jain 
> ---
>  .../libcroco/files/CVE-2020-12825.patch| 193 
> +
>  meta/recipes-support/libcroco/libcroco_0.6.13.bb   |   3 +
>  2 files changed, 196 insertions(+)
>  create mode 100644 meta/recipes-support/libcroco/files/CVE-2020-12825.patch
>
> diff --git a/meta/recipes-support/libcroco/files/CVE-2020-12825.patch 
> b/meta/recipes-support/libcroco/files/CVE-2020-12825.patch
> new file mode 100644
> index 000..966b812
> --- /dev/null
> +++ b/meta/recipes-support/libcroco/files/CVE-2020-12825.patch
> @@ -0,0 +1,193 @@
> +From 6eb257e5c731c691eb137fca94e916ca73941a5a Mon Sep 17 00:00:00 2001
> +From: Michael Catanzaro 
> +Date: Fri, 31 Jul 2020 15:21:53 -0500
> +Subject: [PATCH] libcroco: Limit recursion in block and any productions
> + (CVE-2020-12825)
> +
> +If we don't have any limits, we can recurse forever and overflow the
> +stack.
> +
> +Fixes #8
> +This is per https://gitlab.gnome.org/Archive/libcroco/-/issues/8
> +
> +https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1404
> +
> +CVE: CVE-2020-12825
> +Upstream-Status: Backport 
> [https://gitlab.gnome.org/Archive/libcroco/-/commit/6eb257e5c731c691eb137fca94e916ca73941a5a]
> +Comment: No changes done.
> +Signed-off-by: Saloni Jain 
> +---
> + src/cr-parser.c | 44 +---
> + 1 file changed, 29 insertions(+), 15 deletions(-)
> +
> +diff --git a/src/cr-parser.c b/src/cr-parser.c
> +index 18c9a01..f4a62e3 100644
> +--- a/src/cr-parser.c
>  b/src/cr-parser.c
> +@@ -136,6 +136,8 @@ struct _CRParserPriv {
> +
> + #define CHARS_TAB_SIZE 12
> +
> ++#define RECURSIVE_CALLERS_LIMIT 100
> ++
> + /**
> +  * IS_NUM:
> +  *@a_char: the char to test.
> +@@ -344,9 +346,11 @@ static enum CRStatus cr_parser_parse_selector_core 
> (CRParser * a_this);
> +
> + static enum CRStatus cr_parser_parse_declaration_core (CRParser * a_this);
> +
> +-static enum CRStatus cr_parser_parse_any_core (CRParser * a_this);
> ++static enum CRStatus cr_parser_parse_any_core (CRParser * a_this,
> ++   guint  n_calls);
> +
> +-static enum CRStatus cr_parser_parse_block_core (CRParser * a_this);
> ++static enum CRStatus cr_parser_parse_block_core (CRParser * a_this,
> ++ guint  n_calls);
> +
> + static enum CRStatus cr_parser_parse_value_core (CRParser * a_this);
> +
> +@@ -784,7 +788,7 @@ cr_parser_parse_atrule_core (CRParser * a_this)
> + cr_parser_try_to_skip_spaces_and_comments (a_this);
> +
> + do {
> +-status = cr_parser_parse_any_core (a_this);
> ++status = cr_parser_parse_any_core (a_this, 0);
> + } while (status == CR_OK);
> +
> + status = cr_tknzr_get_next_token (PRIVATE (a_this)->tknzr,
> +@@ -795,7 +799,7 @@ cr_parser_parse_atrule_core (CRParser * a_this)
> + cr_tknzr_unget_token (PRIVATE (a_this)->tknzr,
> +   token);
> + token = NULL;
> +-status = cr_parser_parse_block_core (a_this);
> ++status = cr_parser_parse_block_core (a_this, 0);
> + CHECK_PARSING_STATUS (status,
> +   FALSE);
> + goto done;
> +@@ -930,11 +934,11 @@ cr_parser_parse_selector_core (CRParser * a_this)
> +
> + RECORD_INITIAL_POS (a_this, _pos);
> +
> +-status = cr_parser_parse_any_core (a_this);
> ++status = cr_parser_parse_any_core (a_this, 0);
> + CHECK_PARSING_STATUS (status, FALSE);
> +
> + do {
> +-status = cr_parser_parse_any_core (a_this);
> ++status = cr_parser_parse_any_core (a_this, 0);
> +
> + } while (status == CR_OK);
> +
> +@@ -956,10 +960,12 @@ cr_parser_parse_selector_core (CRParser * a_this)
> +  *in chapter 4.1 of the css2 spec.
> +  *block ::= '{' S* [ any | block | ATKEYWORD S* | ';' ]* '}' S*;
> +  *@param a_this the current instance of #CRParser.
> ++ *@param n_calls used to limit recursion depth
> +  *FIXME: code this function.
> +  */
> + static enum CRStatus
> +-cr_parser_parse_block_core (CRParser * a_this)
> ++cr_parser_parse_block_core (CRParser * a_this,
> ++guint  n_calls)
> + {
> + CRToken *token = NULL;
> + CRInputPos init_pos;
> +@@ -967,6 +973,9 @@ cr_parser_parse_block_core (CRParser * a_this)
> +
> + g_return_val_if_fail (a_this && PRIVATE (a_this), 
> CR_BAD_PARAM_ERROR);
> +
> ++if (n_calls > RECURSIVE_CALLERS_LIMIT)
> ++return CR_ERROR;
> ++
> + RECORD_INITIAL_POS (a_this, _pos);
> +
> + status = 

[OE-core] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
  Exception: FileExistsError: [Errno 17] File exists: 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15' -> 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Signed-off-by: Mike Looijmans 
---
 meta/classes/license_image.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 119c8dfc86..6f478ce22c 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -210,7 +210,8 @@ def license_deployed_manifest(d):
 os.unlink(lic_manifest_symlink_dir)
 
 # create the image dir symlink
-os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
+if lic_manifest_dir != lic_manifest_symlink_dir:
+os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
 
 def get_deployed_dependencies(d):
 """
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147701): 
https://lists.openembedded.org/g/openembedded-core/message/147701
Mute This Topic: https://lists.openembedded.org/mt/80406266/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] rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM

[Michael Ho]

Hi RP,

Thanks for the comments. Sounds good to me. I'll send another patchset.

I'll see if I can also set up a renaming patch for the other IPKG variables for
review comments.

Kind regards,
Michael

-- 
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael...@bmw-carit.de 
Web: http://www.bmw-carit.de 
-
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Michael Böttrich
Sitz und Registergericht: München HRB 134810
-
 

On 05.02.21, 13:33, "Richard Purdie"  
wrote:

On Fri, 2021-02-05 at 09:51 +0100, Michael Ho wrote:
> From: Michael Ho 
> 
> The OpkgPM class has several constructor options that allows for skipping
> the ipk repository set up and controlling the ipk repository directory. 
This
> commit exposes these option via the OpkgRootfs class so others can make 
use
> of them if they wish to.
> 
> Adds the bitbake variables "IPKGREPO_TARGET_PREPARED" and 
"IPKGREPO_TARGET"
> to act as the interfaces.
> 
> Signed-off-by: Michael Ho 
> ---
>  meta/lib/oe/package_manager/ipk/rootfs.py | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py 
b/meta/lib/oe/package_manager/ipk/rootfs.py
> index 26dbee6..6313b72 100644
> --- a/meta/lib/oe/package_manager/ipk/rootfs.py
> +++ b/meta/lib/oe/package_manager/ipk/rootfs.py
> @@ -129,6 +129,14 @@ class PkgRootfs(DpkgOpkgRootfs):
>  self.manifest = PkgManifest(d, manifest_dir)
>  self.opkg_conf = self.d.getVar("IPKGCONF_TARGET")
>  self.pkg_archs = self.d.getVar("ALL_MULTILIB_PACKAGE_ARCHS")
> +self.opkg_repo = self.d.getVar("IPKGREPO_TARGET")
> +self.opkg_repo_prepared = 
self.d.getVar("IPKGREPO_TARGET_PREPARED")
> +
> +kwargs = {}
> +if self.opkg_repo:
> +kwargs["ipk_repo_workdir"] = self.opkg_repo
> +if self.opkg_repo_prepared:
> +kwargs["prepare_index"] = False
>  
> 

It seems reasonable to expose them, I'd just suggest that we don't put
them in self here but do something like:

+if self.d.getVar("IPKGREPO_TARGET"):
+kwargs["ipk_repo_workdir"] = self.opkg_repo
+if self.d.getVar("IPKGREPO_TARGET_PREPARED"):
+kwargs["prepare_index"] = False

and my only other concern is the naming. Somehow we need to get from
the mess we're currently in to some kind of more consistent and
understandable naming of variables.

OPKG_ROOTFS_FEED_WORKDIR
OPKG_ROOTFS_REBUILDINDEX

maybe?

I'd also yes, we should document them.

Cheers,

Richard


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

[OE-core] [poky][dunfell][PATCH v2] libgcrypt: Whitelisted CVEs

[saloni]

Whitelisted below CVEs:

1. CVE-2018-12433
Link: https://security-tracker.debian.org/tracker/CVE-2018-12433
Link: https://nvd.nist.gov/vuln/detail/CVE-2018-12433
CVE-2018-12433 is marked disputed and ignored by NVD as it does
not impact crypt libraries for any distros and hence, can be safely
marked whitelisted.

2. CVE-2018-12438
Link: https://security-tracker.debian.org/tracker/CVE-2018-12438
Link: https://ubuntu.com/security/CVE-2018-12438
CVE-2018-12438 was reported for affecting openjdk crypt libraries
but there are no details available on which openjdk versions are
affected and does not directly affect libgcrypt or any specific
yocto distributions, hence, can be whitelisted.

Signed-off-by: Saloni Jain 
---
 meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
index 4e0eb0a..ba3666f 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
@@ -29,6 +29,9 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \
 SRC_URI[md5sum] = "348cc4601ca34307fc6cd6c945467743"
 SRC_URI[sha256sum] = 
"3b4a2a94cb637eff5bdebbcaf46f4d95c4f25206f459809339cdada0eb577ac3"

+# Below whitelisted CVEs are disputed and not affecting Ubuntu and Debian 
environments.
+CVE_CHECK_WHITELIST += "CVE-2018-12433 CVE-2018-12438"
+
 BINCONFIG = "${bindir}/libgcrypt-config"

 inherit autotools texinfo binconfig-disabled pkgconfig
--
2.7.4

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147699): 
https://lists.openembedded.org/g/openembedded-core/message/147699
Mute This Topic: https://lists.openembedded.org/mt/80405847/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] [poky][dunfell][PATCH] libgcrypt: Whitelisted CVEs

[saloni]

Hello Steve,

The patches are generic to all Yocto implementations and are not reported for 
any particular distros.

I have re-sent another patch version mentioning in detail why these CVEs can be 
safely whitelisted. Please review and let me know for any change.

Thanks & Regards,
Saloni

From: Steve Sakoman 
Sent: Wednesday, February 3, 2021 8:15 PM
To: Saloni Jain 
Cc: Patches and discussions about the oe-core layer 
; Khem Raj ; 
Nisha Parrakat ; Anuj Chougule 
Subject: Re: [OE-core] [poky][dunfell][PATCH] libgcrypt: Whitelisted CVEs

On Tue, Feb 2, 2021 at 8:09 AM saloni  wrote:
>
> Whitelisted below CVEs as their status is disputed
> and ignored and not affecting the Ubuntu and Debian
> environments. Hence, marked them whitelisted.

I'm not sure why you are referencing Ubuntu and Debian environments.
We care about whether it is affecting the Yocto implementation.

Could you explain your reasoning a bit more?  Are you saying that
Ubuntu and Debian maintainers don't consider these CVE's to be a
serious enough issue to mitigate and thus it is safe for us to do the
same?

Thanks!

Steve

> 1. CVE-2018-12433
> Link: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecurity-tracker.debian.org%2Ftracker%2FCVE-2018-12433data=04%7C01%7Csaloni.jain%40kpit.com%7C552396efe6014cdf8dbb08d8c8526011%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637479603466304421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NBbGFes6ahGsJLIXXcmqnQ%2Fi95ziKHMHnGzD%2F%2FPFEBM%3Dreserved=0
>
> 2. CVE-2018-12438
> Link: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecurity-tracker.debian.org%2Ftracker%2FCVE-2018-12438data=04%7C01%7Csaloni.jain%40kpit.com%7C552396efe6014cdf8dbb08d8c8526011%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637479603466304421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=uBYKEgLQ3vY8%2FH0QuBxS2znVtRPJANKv%2FWF0nOGpkI8%3Dreserved=0
>
> Signed-off-by: Saloni Jain 
> ---
>  meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb 
> b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> index 4e0eb0a..ba3666f 100644
> --- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> +++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> @@ -29,6 +29,9 @@ SRC_URI = 
> "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \
>  SRC_URI[md5sum] = "348cc4601ca34307fc6cd6c945467743"
>  SRC_URI[sha256sum] = 
> "3b4a2a94cb637eff5bdebbcaf46f4d95c4f25206f459809339cdada0eb577ac3"
>
> +# Below whitelisted CVEs are disputed and not affecting Ubuntu and Debian 
> environments.
> +CVE_CHECK_WHITELIST += "CVE-2018-12433 CVE-2018-12438"
> +
>  BINCONFIG = "${bindir}/libgcrypt-config"
>
>  inherit autotools texinfo binconfig-disabled pkgconfig
> --
> 2.7.4
>
> This message contains information that may be privileged or confidential and 
> is the property of the KPIT Technologies Ltd. It is intended only for the 
> person to whom it is addressed. If you are not the intended recipient, you 
> are not authorized to read, print, retain copy, disseminate, distribute, or 
> use this message or any part thereof. If you receive this message in error, 
> please notify the sender immediately and delete all copies of this message. 
> KPIT Technologies Ltd. does not accept any liability for virus infected mails.
>
> 
>
This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147698): 
https://lists.openembedded.org/g/openembedded-core/message/147698
Mute This Topic: https://lists.openembedded.org/mt/80321678/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][dunfell 3/3] wic/selftest: test_permissions also test bitbake image

[Lee Chee Yang]

From: Lee Chee Yang 

existing test case test_permissions use Wic command as standalone
tools to create wic image and check that wic image for permissions.

add extra steps to the test case to also check against image build
using bitbake do_image_wic.

Signed-off-by: Lee Chee Yang 
Signed-off-by: Richard Purdie 
(cherry picked from commit 551ce73a90757ba43501fe5cf9ac84a7b77de549)
Signed-off-by: Chee Yang Lee 
---
 meta/lib/oeqa/selftest/cases/wic.py | 16 
 1 file changed, 16 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index d4c0db8bda..0435aa29c9 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -516,6 +516,9 @@ part /part2 --source rootfs --ondisk mmcblk0 --fstype=ext4 
--include-path %s"""
 def test_permissions(self):
 """Test permissions are respected"""
 
+# prepare wicenv and rootfs
+bitbake('core-image-minimal core-image-minimal-mtdutils -c 
do_rootfs_wicenv')
+
 oldpath = os.environ['PATH']
 os.environ['PATH'] = get_bb_var("PATH", "wic-tools")
 
@@ -549,6 +552,19 @@ part /etc --source rootfs --fstype=ext4 
--change-directory=etc
 res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % (part))
 self.assertEqual(True, files_own_by_root(res.output))
 
+config = 'IMAGE_FSTYPES += "wic"\nWKS_FILE = "%s"\n' % wks_file
+self.append_config(config)
+bitbake('core-image-minimal')
+tmpdir = os.path.join(get_bb_var('WORKDIR', 
'core-image-minimal'),'build-wic')
+
+# check each partition for permission
+for part in glob(os.path.join(tmpdir, 'temp-*.direct.p*')):
+res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % (part))
+self.assertTrue(files_own_by_root(res.output)
+,msg='Files permission incorrect using wks set "%s"' % 
test)
+
+# clean config and result directory for next cases
+self.remove_config(config)
 rmtree(self.resultdir, ignore_errors=True)
 
 finally:
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147697): 
https://lists.openembedded.org/g/openembedded-core/message/147697
Mute This Topic: https://lists.openembedded.org/mt/80405642/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][dunfell 2/3] oeqa: wic: Add tests for permissions and change-directory

[Lee Chee Yang]

From: Ricardo Ribalda Delgado 

Make sure that the permissions and username are respected when using all
the rootfs modifiers.

Add tests for change-directory command

Cc: Paul Barker 
Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Richard Purdie 
(cherry picked from commit 4aad9531df44d1b0637bd559161702ad86861b46)
Signed-off-by: Chee Yang Lee 
---
 meta/lib/oeqa/selftest/cases/wic.py | 90 +
 1 file changed, 90 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index 13b6a0cc72..d4c0db8bda 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -62,6 +62,12 @@ def extract_files(debugfs_output):
 return [line.split('/')[5].strip() for line in \
 debugfs_output.strip().split('/\n')]
 
+def files_own_by_root(debugfs_output):
+for line in debugfs_output.strip().split('/\n'):
+if line.split('/')[3:5] != ['0', '0']:
+print(debugfs_output)
+return False
+return True
 
 class WicTestCase(OESelftestTestCase):
 """Wic test class."""
@@ -84,6 +90,7 @@ class WicTestCase(OESelftestTestCase):
 self.skipTest('wic-tools cannot be built due its 
(intltool|gettext)-native dependency and NLS disable')
 
 bitbake('core-image-minimal')
+bitbake('core-image-minimal-mtdutils')
 WicTestCase.image_is_ready = True
 
 rmtree(self.resultdir, ignore_errors=True)
@@ -506,6 +513,89 @@ part /part2 --source rootfs --ondisk mmcblk0 --fstype=ext4 
--include-path %s"""
   % (wks_file, self.resultdir), 
ignore_status=True).status)
 os.remove(wks_file)
 
+def test_permissions(self):
+"""Test permissions are respected"""
+
+oldpath = os.environ['PATH']
+os.environ['PATH'] = get_bb_var("PATH", "wic-tools")
+
+t_normal = """
+part / --source rootfs --fstype=ext4
+"""
+t_exclude = """
+part / --source rootfs --fstype=ext4 --exclude-path=home
+"""
+t_multi = """
+part / --source rootfs --ondisk sda --fstype=ext4
+part /export --source rootfs --rootfs=core-image-minimal-mtdutils --fstype=ext4
+"""
+t_change = """
+part / --source rootfs --ondisk sda --fstype=ext4 --exclude-path=etc/   
+part /etc --source rootfs --fstype=ext4 --change-directory=etc
+"""
+tests = [t_normal, t_exclude, t_multi, t_change]
+
+try:
+for test in tests:
+include_path = os.path.join(self.resultdir, 'test-include')
+os.makedirs(include_path)
+wks_file = os.path.join(include_path, 'temp.wks')
+with open(wks_file, 'w') as wks:
+wks.write(test)
+runCmd("wic create %s -e core-image-minimal -o %s" \
+   % (wks_file, self.resultdir))
+
+for part in glob(os.path.join(self.resultdir, 
'temp-*.direct.p*')):
+res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % (part))
+self.assertEqual(True, files_own_by_root(res.output))
+
+rmtree(self.resultdir, ignore_errors=True)
+
+finally:
+os.environ['PATH'] = oldpath
+
+def test_change_directory(self):
+"""Test --change-directory wks option."""
+
+oldpath = os.environ['PATH']
+os.environ['PATH'] = get_bb_var("PATH", "wic-tools")
+
+try:
+include_path = os.path.join(self.resultdir, 'test-include')
+os.makedirs(include_path)
+wks_file = os.path.join(include_path, 'temp.wks')
+with open(wks_file, 'w') as wks:
+wks.write("part /etc --source rootfs --fstype=ext4 
--change-directory=etc")
+runCmd("wic create %s -e core-image-minimal -o %s" \
+   % (wks_file, self.resultdir))
+
+part1 = glob(os.path.join(self.resultdir, 'temp-*.direct.p1'))[0]
+
+res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % (part1))
+files = extract_files(res.output)
+self.assertIn('passwd', files)
+
+finally:
+os.environ['PATH'] = oldpath
+
+def test_change_directory_errors(self):
+"""Test --change-directory wks option error handling."""
+wks_file = 'temp.wks'
+
+# Absolute argument.
+with open(wks_file, 'w') as wks:
+wks.write("part / --source rootfs --fstype=ext4 --change-directory 
/usr")
+self.assertNotEqual(0, runCmd("wic create %s -e core-image-minimal -o 
%s" \
+  % (wks_file, self.resultdir), 
ignore_status=True).status)
+os.remove(wks_file)
+
+# Argument pointing to parent directory.
+with open(wks_file, 'w') as wks:
+wks.write("part / --source rootfs --fstype=ext4 --change-directory 
././..")
+self.assertNotEqual(0, runCmd("wic 

[OE-core] [PATCH][dunfell 1/3] classes/image_types_wic: Reorder do_flush_pseudodb

[Lee Chee Yang]

From: Ricardo Ribalda 

When IMAGE_FSTYPES contains more types than wic, it can happen than the
pseudo database is not flushed properly.

This can be solved by changing the order of when do_flush_pseudodb is
launched.

Yocto Bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13898
Fixes: dde90a5dd2b2 ("wic: Fix multi images .wks with bitbake")
Signed-off-by: Ricardo Ribalda 
Signed-off-by: Richard Purdie 
(cherry picked from commit 445b0a9544b55735496bbb23dbff3399b3b9e9a4)
Signed-off-by: Chee Yang Lee 
---
 meta/classes/image_types_wic.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index f6c8d8995e..ae00acc5ea 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -151,7 +151,7 @@ python do_rootfs_wicenv () {
 depdir = d.getVar('IMGDEPLOYDIR')
 bb.utils.copyfile(os.path.join(outdir, basename) + '.env', 
os.path.join(depdir, basename) + '.env')
 }
-addtask do_flush_pseudodb after do_image before do_image_wic
+addtask do_flush_pseudodb after do_rootfs before do_image do_image_qa
 addtask do_rootfs_wicenv after do_image before do_image_wic
 do_rootfs_wicenv[vardeps] += "${WICVARS}"
 do_rootfs_wicenv[prefuncs] = 'set_image_size'
-- 
2.17.1


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

[OE-core] [poky][dunfell][PATCH] libcroco: Added CVE-2020-12825

[saloni]

Added below CVE:
CVE-2020-12825
Link: CVE-2020-12825 
[https://gitlab.gnome.org/Archive/libcroco/-/commit/6eb257e5c731c691eb137fca94e916ca73941a5a]
Link: https://gitlab.gnome.org/Archive/libcroco/-/issues/8

Signed-off-by: Saloni Jain 
---
 .../libcroco/files/CVE-2020-12825.patch| 193 +
 meta/recipes-support/libcroco/libcroco_0.6.13.bb   |   3 +
 2 files changed, 196 insertions(+)
 create mode 100644 meta/recipes-support/libcroco/files/CVE-2020-12825.patch

diff --git a/meta/recipes-support/libcroco/files/CVE-2020-12825.patch 
b/meta/recipes-support/libcroco/files/CVE-2020-12825.patch
new file mode 100644
index 000..966b812
--- /dev/null
+++ b/meta/recipes-support/libcroco/files/CVE-2020-12825.patch
@@ -0,0 +1,193 @@
+From 6eb257e5c731c691eb137fca94e916ca73941a5a Mon Sep 17 00:00:00 2001
+From: Michael Catanzaro 
+Date: Fri, 31 Jul 2020 15:21:53 -0500
+Subject: [PATCH] libcroco: Limit recursion in block and any productions
+ (CVE-2020-12825)
+
+If we don't have any limits, we can recurse forever and overflow the
+stack.
+
+Fixes #8
+This is per https://gitlab.gnome.org/Archive/libcroco/-/issues/8
+
+https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1404
+
+CVE: CVE-2020-12825
+Upstream-Status: Backport 
[https://gitlab.gnome.org/Archive/libcroco/-/commit/6eb257e5c731c691eb137fca94e916ca73941a5a]
+Comment: No changes done.
+Signed-off-by: Saloni Jain 
+---
+ src/cr-parser.c | 44 +---
+ 1 file changed, 29 insertions(+), 15 deletions(-)
+
+diff --git a/src/cr-parser.c b/src/cr-parser.c
+index 18c9a01..f4a62e3 100644
+--- a/src/cr-parser.c
 b/src/cr-parser.c
+@@ -136,6 +136,8 @@ struct _CRParserPriv {
+
+ #define CHARS_TAB_SIZE 12
+
++#define RECURSIVE_CALLERS_LIMIT 100
++
+ /**
+  * IS_NUM:
+  *@a_char: the char to test.
+@@ -344,9 +346,11 @@ static enum CRStatus cr_parser_parse_selector_core 
(CRParser * a_this);
+
+ static enum CRStatus cr_parser_parse_declaration_core (CRParser * a_this);
+
+-static enum CRStatus cr_parser_parse_any_core (CRParser * a_this);
++static enum CRStatus cr_parser_parse_any_core (CRParser * a_this,
++   guint  n_calls);
+
+-static enum CRStatus cr_parser_parse_block_core (CRParser * a_this);
++static enum CRStatus cr_parser_parse_block_core (CRParser * a_this,
++ guint  n_calls);
+
+ static enum CRStatus cr_parser_parse_value_core (CRParser * a_this);
+
+@@ -784,7 +788,7 @@ cr_parser_parse_atrule_core (CRParser * a_this)
+ cr_parser_try_to_skip_spaces_and_comments (a_this);
+
+ do {
+-status = cr_parser_parse_any_core (a_this);
++status = cr_parser_parse_any_core (a_this, 0);
+ } while (status == CR_OK);
+
+ status = cr_tknzr_get_next_token (PRIVATE (a_this)->tknzr,
+@@ -795,7 +799,7 @@ cr_parser_parse_atrule_core (CRParser * a_this)
+ cr_tknzr_unget_token (PRIVATE (a_this)->tknzr,
+   token);
+ token = NULL;
+-status = cr_parser_parse_block_core (a_this);
++status = cr_parser_parse_block_core (a_this, 0);
+ CHECK_PARSING_STATUS (status,
+   FALSE);
+ goto done;
+@@ -930,11 +934,11 @@ cr_parser_parse_selector_core (CRParser * a_this)
+
+ RECORD_INITIAL_POS (a_this, _pos);
+
+-status = cr_parser_parse_any_core (a_this);
++status = cr_parser_parse_any_core (a_this, 0);
+ CHECK_PARSING_STATUS (status, FALSE);
+
+ do {
+-status = cr_parser_parse_any_core (a_this);
++status = cr_parser_parse_any_core (a_this, 0);
+
+ } while (status == CR_OK);
+
+@@ -956,10 +960,12 @@ cr_parser_parse_selector_core (CRParser * a_this)
+  *in chapter 4.1 of the css2 spec.
+  *block ::= '{' S* [ any | block | ATKEYWORD S* | ';' ]* '}' S*;
+  *@param a_this the current instance of #CRParser.
++ *@param n_calls used to limit recursion depth
+  *FIXME: code this function.
+  */
+ static enum CRStatus
+-cr_parser_parse_block_core (CRParser * a_this)
++cr_parser_parse_block_core (CRParser * a_this,
++guint  n_calls)
+ {
+ CRToken *token = NULL;
+ CRInputPos init_pos;
+@@ -967,6 +973,9 @@ cr_parser_parse_block_core (CRParser * a_this)
+
+ g_return_val_if_fail (a_this && PRIVATE (a_this), CR_BAD_PARAM_ERROR);
+
++if (n_calls > RECURSIVE_CALLERS_LIMIT)
++return CR_ERROR;
++
+ RECORD_INITIAL_POS (a_this, _pos);
+
+ status = cr_tknzr_get_next_token (PRIVATE (a_this)->tknzr, );
+@@ -996,13 +1005,13 @@ cr_parser_parse_block_core (CRParser * a_this)
+ } else if (token->type == CBO_TK) {
+ cr_tknzr_unget_token (PRIVATE (a_this)->tknzr, token);
+ token = NULL;
+-status = 

Re: [OE-core] [PATCH 1/2] image_types: Ensure tar archives are reproducible

[Richard Purdie]

On Fri, 2021-02-05 at 13:14 +0100, Martin Jansa wrote:
> On Sat, Jan 30, 2021 at 7:02 PM Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > The tar output seems to vary depending on the version of tar used
> > and distro
> > configuration. Be explict about the output format to avoid this and
> > be
> > determinstic.
> > 
> 
> Is it the tar format selection which isn't deterministic or something
> else when the format isn't set to gnu?

Different versions of tar seemed to be picking different output
formats, I therefore picked one. I looked at which output format
reproducible builds were recommending.

> I'm asking because gnu format isn't compatible with --xattrs used
> e.g. here:
>  
> https://github.com/advancedtelematic/meta-updater/blob/d3a832f66e8802cb45536ff278d5c77f946d341d/classes/image_types_ostree.bbclass#L16
> causing do_image_tar failing with:
> 
> | tar: --xattrs can be used only on POSIX archives
> | Try 'tar --help' or 'tar --usage' for more information.
> 
> I've already tested that --format=posix here would fix meta-updater,
> but not sure if it's still as deterministic as --format=gnu. Do you
> remember which distros were producing different output?

I think it was centos7 differing to ubuntu 18.04

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147693): 
https://lists.openembedded.org/g/openembedded-core/message/147693
Mute This Topic: https://lists.openembedded.org/mt/80240566/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] rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM

[Richard Purdie]

On Fri, 2021-02-05 at 09:51 +0100, Michael Ho wrote:
> From: Michael Ho 
> 
> The OpkgPM class has several constructor options that allows for skipping
> the ipk repository set up and controlling the ipk repository directory. This
> commit exposes these option via the OpkgRootfs class so others can make use
> of them if they wish to.
> 
> Adds the bitbake variables "IPKGREPO_TARGET_PREPARED" and "IPKGREPO_TARGET"
> to act as the interfaces.
> 
> Signed-off-by: Michael Ho 
> ---
>  meta/lib/oe/package_manager/ipk/rootfs.py | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py 
> b/meta/lib/oe/package_manager/ipk/rootfs.py
> index 26dbee6..6313b72 100644
> --- a/meta/lib/oe/package_manager/ipk/rootfs.py
> +++ b/meta/lib/oe/package_manager/ipk/rootfs.py
> @@ -129,6 +129,14 @@ class PkgRootfs(DpkgOpkgRootfs):
>  self.manifest = PkgManifest(d, manifest_dir)
>  self.opkg_conf = self.d.getVar("IPKGCONF_TARGET")
>  self.pkg_archs = self.d.getVar("ALL_MULTILIB_PACKAGE_ARCHS")
> +self.opkg_repo = self.d.getVar("IPKGREPO_TARGET")
> +self.opkg_repo_prepared = self.d.getVar("IPKGREPO_TARGET_PREPARED")
> +
> +kwargs = {}
> +if self.opkg_repo:
> +kwargs["ipk_repo_workdir"] = self.opkg_repo
> +if self.opkg_repo_prepared:
> +kwargs["prepare_index"] = False
>  
> 

It seems reasonable to expose them, I'd just suggest that we don't put
them in self here but do something like:

+if self.d.getVar("IPKGREPO_TARGET"):
+kwargs["ipk_repo_workdir"] = self.opkg_repo
+if self.d.getVar("IPKGREPO_TARGET_PREPARED"):
+kwargs["prepare_index"] = False
 
and my only other concern is the naming. Somehow we need to get from
the mess we're currently in to some kind of more consistent and
understandable naming of variables.

OPKG_ROOTFS_FEED_WORKDIR
OPKG_ROOTFS_REBUILDINDEX

maybe?

I'd also yes, we should document them.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147692): 
https://lists.openembedded.org/g/openembedded-core/message/147692
Mute This Topic: https://lists.openembedded.org/mt/80401750/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] kernel.bbclass: fix deployment for initramfs images

[Richard Purdie]

On Thu, 2021-02-04 at 08:25 +, Awais Belal wrote:
> The do_bundle_initramfs() only processes kernel image
> types that are found in KERNEL_IMAGETYPE_FOR_MAKE whereas
> the build system can generate other types that are not
> directly supported by the kernel build system. In which
> case when we come to the deploy phase not all the images
> mentioned in KERNEL_IMAGETYPES would have a respective
> initramfs bundled image. An example is using vmlinux.gz
> in KERNEL_IMAGETYPES and enabling initramfs and then we
> see
> 
> install: cannot stat 'arch/arm64/boot/vmlinux.gz.initramfs': No such file or 
> directory
> 
> So we align the deploy phase with bundle initramfs phase
> and pick up relevant initramfs bundled images using
> KERNEL_IMAGETYPE_FOR_MAKE instead of KERNEL_IMAGETYPES.
> 
> Signed-off-by: Awais Belal 
> ---
>  meta/classes/kernel.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index ddff2ddcd2..8693ab86be 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -759,7 +759,7 @@ kernel_do_deploy() {
> fi
> 
> if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 
> ]; then
> -   for imageType in ${KERNEL_IMAGETYPES} ; do
> +   for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do
> if [ "$imageType" = "fitImage" ] ; then
> continue
> fi
> --
> 2.17.1
> 
> 
> Ping!

Merged six days ago?

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=44ecc935b2ba919ed5bf026c02cdb814e207d996

Cheers,

Richard


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

Re: [OE-core] [PATCH 1/2] image_types: Ensure tar archives are reproducible

[Martin Jansa]

On Sat, Jan 30, 2021 at 7:02 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> The tar output seems to vary depending on the version of tar used and
> distro
> configuration. Be explict about the output format to avoid this and be
> determinstic.
>

Is it the tar format selection which isn't deterministic or something else
when the format isn't set to gnu?

I'm asking because gnu format isn't compatible with --xattrs used e.g. here:
https://github.com/advancedtelematic/meta-updater/blob/d3a832f66e8802cb45536ff278d5c77f946d341d/classes/image_types_ostree.bbclass#L16
causing do_image_tar failing with:

| tar: --xattrs can be used only on POSIX archives
| Try 'tar --help' or 'tar --usage' for more information.

I've already tested that --format=posix here would fix meta-updater, but
not sure if it's still as deterministic as --format=gnu. Do you remember
which distros were producing different output?

Thanks


> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/image_types.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index c937ae45384..76949d1051d 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -110,7 +110,7 @@ IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS}
> ${IMGDEPLOYDIR}/${IMAGE_NAM
>
>  IMAGE_CMD_TAR ?= "tar"
>  # ignore return code 1 "file changed as we read it" as other tasks(e.g.
> do_image_wic) may be hardlinking rootfs
> -IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --sort=name --numeric-owner -cf
> ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} .
> || [ $? -eq 1 ]"
> +IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --sort=name --format=gnu
> --numeric-owner -cf ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar
> -C ${IMAGE_ROOTFS} . || [ $? -eq 1 ]"
>
>  do_image_cpio[cleandirs] += "${WORKDIR}/cpio_append"
>  IMAGE_CMD_cpio () {
> --
> 2.27.0
>
>
> 
>
>

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

[OE-core] [PATCH][V2] openssl: re-enable whirlpool

[Andreas Müller]

* it breaks KDE's qca and dependencies
* it is not deprecated. Openssl 3.0 (currently alpha) will deprecate whirlpool

[1] https://www.openssl.org/news/changelog.html#openssl-30

Signed-off-by: Andreas Müller 
---
V1 -> V2: Add comment for whirlpool
 meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
index 5617f337e0..99b1566740 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
@@ -65,7 +65,8 @@ CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin 
-DENGINESDIR=/not/bu
 # rc2 (mailx)
 # psk (qt5)
 # srp (libest)
-DEPRECATED_CRYPTO_FLAGS = "no-ssl no-idea no-rc5 no-md2 no-camellia no-mdc2 
no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
+# whirlpool (qca)
+DEPRECATED_CRYPTO_FLAGS = "no-ssl no-idea no-rc5 no-md2 no-camellia no-mdc2 
no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4"
 
 do_configure () {
os=${HOST_OS}
-- 
2.26.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147689): 
https://lists.openembedded.org/g/openembedded-core/message/147689
Mute This Topic: https://lists.openembedded.org/mt/80403318/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] openssl: re-enable whirlpool

[Konrad Weihmann]

On 05.02.21 12:14, Andreas Müller wrote:

* it breaks KDE's qca and dependencies
* it is not deprecated. Openssl 3.0 (currently alpha) will deprecate whirlpool

[1] https://www.openssl.org/news/changelog.html#openssl-30

Signed-off-by: Andreas Müller 
---
  meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
index ffa261a1be..774341c719 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
@@ -65,7 +65,7 @@ CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin 
-DENGINESDIR=/not/bu
  # rc2 (mailx)
  # psk (qt5)
  # srp (libest)


maybe worth adding a comment, like it was done for the other exceptions


-DEPRECATED_CRYPTO_FLAGS = "no-ssl no-idea no-rc5 no-md2 no-camellia no-mdc2 
no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
+DEPRECATED_CRYPTO_FLAGS = "no-ssl no-idea no-rc5 no-md2 no-camellia no-mdc2 
no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4"
  
  do_configure () {

os=${HOST_OS}






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

[OE-core] [PATCH] openssl: re-enable whirlpool

[Andreas Müller]

* it breaks KDE's qca and dependencies
* it is not deprecated. Openssl 3.0 (currently alpha) will deprecate whirlpool

[1] https://www.openssl.org/news/changelog.html#openssl-30

Signed-off-by: Andreas Müller 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
index ffa261a1be..774341c719 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
@@ -65,7 +65,7 @@ CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin 
-DENGINESDIR=/not/bu
 # rc2 (mailx)
 # psk (qt5)
 # srp (libest)
-DEPRECATED_CRYPTO_FLAGS = "no-ssl no-idea no-rc5 no-md2 no-camellia no-mdc2 
no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
+DEPRECATED_CRYPTO_FLAGS = "no-ssl no-idea no-rc5 no-md2 no-camellia no-mdc2 
no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4"
 
 do_configure () {
os=${HOST_OS}
-- 
2.26.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147687): 
https://lists.openembedded.org/g/openembedded-core/message/147687
Mute This Topic: https://lists.openembedded.org/mt/80403163/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] parted: upgrade 3.3 -> 3.4

[Alexander Kanavin]

Have you confirmed that ptests still pass?

Alex

On Fri, 5 Feb 2021 at 03:28, Wang Mingyu  wrote:

> 0001-Move-python-helper-scripts-used-only-in-tests-to-Pyt.patch
> 0001-libparted-fs-add-sourcedir-lib-to-include-paths.patch
> 0002-tests-use-skip_-rather-than-skip_test_-which-is-unde.patch
> removed since they are included in 3.4
>
> Signed-off-by: Wang Mingyu 
> ---
>  ...er-scripts-used-only-in-tests-to-Pyt.patch | 33 --
>  ...s-add-sourcedir-lib-to-include-paths.patch | 26 
>  ...rather-than-skip_test_-which-is-unde.patch | 66 ---
>  .../parted/{parted_3.3.bb => parted_3.4.bb}   |  7 +-
>  4 files changed, 2 insertions(+), 130 deletions(-)
>  delete mode 100644
> meta/recipes-extended/parted/files/0001-Move-python-helper-scripts-used-only-in-tests-to-Pyt.patch
>  delete mode 100644
> meta/recipes-extended/parted/files/0001-libparted-fs-add-sourcedir-lib-to-include-paths.patch
>  delete mode 100644
> meta/recipes-extended/parted/files/0002-tests-use-skip_-rather-than-skip_test_-which-is-unde.patch
>  rename meta/recipes-extended/parted/{parted_3.3.bb => parted_3.4.bb}
> (83%)
>
> diff --git
> a/meta/recipes-extended/parted/files/0001-Move-python-helper-scripts-used-only-in-tests-to-Pyt.patch
> b/meta/recipes-extended/parted/files/0001-Move-python-helper-scripts-used-only-in-tests-to-Pyt.patch
> deleted file mode 100644
> index 829c0c8b78..00
> ---
> a/meta/recipes-extended/parted/files/0001-Move-python-helper-scripts-used-only-in-tests-to-Pyt.patch
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -From ddbefd80d74c3baaae328332458db447e1666240 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Thu, 27 Apr 2017 16:37:24 +0300
> -Subject: [PATCH] Move python helper scripts (used only in tests) to
> Python 3
> -
> -Upstream-Status: Pending
> -Signed-off-by: Alexander Kanavin 
> -
> 
> - tests/gpt-header-move | 2 +-
> - tests/msdos-overlap   | 2 +-
> - 2 files changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/tests/gpt-header-move b/tests/gpt-header-move
> -index 3dda5cb..a2b9508 100755
>  a/tests/gpt-header-move
> -+++ b/tests/gpt-header-move
> -@@ -1,4 +1,4 @@
> --#!/usr/bin/python
> -+#!/usr/bin/env python3
> -
> - # open img file, subtract 33 from altlba address, and move the last 33
> sectors
> - # back by 33 sectors
> -diff --git a/tests/msdos-overlap b/tests/msdos-overlap
> -index d6ae8d6..2c6747b 100755
>  a/tests/msdos-overlap
> -+++ b/tests/msdos-overlap
> -@@ -1,4 +1,4 @@
> --#!/usr/bin/python
> -+#!/usr/bin/env python3
> - """
> - Write an overlapping partition to a msdos disk
> -
> diff --git
> a/meta/recipes-extended/parted/files/0001-libparted-fs-add-sourcedir-lib-to-include-paths.patch
> b/meta/recipes-extended/parted/files/0001-libparted-fs-add-sourcedir-lib-to-include-paths.patch
> deleted file mode 100644
> index 4dc2ab259d..00
> ---
> a/meta/recipes-extended/parted/files/0001-libparted-fs-add-sourcedir-lib-to-include-paths.patch
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -From d60a8a86f6593738b5324ccd8fe3e6d84a1fe7bc Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Wed, 11 Dec 2019 14:18:36 +0100
> -Subject: [PATCH] libparted/fs: add $sourcedir/lib to include paths
> -
> -Otherwise, getopt-pfx-core.h won't be found.
> -
> -Upstream-Status: Pending
> -Signed-off-by: Alexander Kanavin 
> 
> - libparted/fs/Makefile.am | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/libparted/fs/Makefile.am b/libparted/fs/Makefile.am
> -index 286bff6..65f45d3 100644
>  a/libparted/fs/Makefile.am
> -+++ b/libparted/fs/Makefile.am
> -@@ -3,7 +3,7 @@
> - #
> - # This file may be modified and/or distributed without restriction.
> -
> --partedincludedir = -I$(top_builddir)/include -I$(top_srcdir)/include
> -+partedincludedir = -I$(top_builddir)/include -I$(top_srcdir)/include
> -I$(top_srcdir)/lib
> -
> - AM_CFLAGS = $(WARN_CFLAGS)
> -
> diff --git
> a/meta/recipes-extended/parted/files/0002-tests-use-skip_-rather-than-skip_test_-which-is-unde.patch
> b/meta/recipes-extended/parted/files/0002-tests-use-skip_-rather-than-skip_test_-which-is-unde.patch
> deleted file mode 100644
> index 9524adf7b8..00
> ---
> a/meta/recipes-extended/parted/files/0002-tests-use-skip_-rather-than-skip_test_-which-is-unde.patch
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -From 9f844484cedb39e301b016e9da7852c1a0fb6eea Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Wed, 11 Dec 2019 16:27:48 +0100
> -Subject: [PATCH] tests: use skip_ rather than skip_test_ (which is
> undefined)
> -
> -Upstream-Status: Pending
> -Signed-off-by: Alexander Kanavin 
> 
> - tests/t6001-psep.sh   | 2 +-
> - tests/t6004-dm-many-partitions.sh | 2 +-
> - tests/t6005-dm-uuid.sh| 2 +-
> - tests/t6006-dm-512b-sectors.sh| 2 +-
> - 4 files changed, 4 insertions(+), 4 deletions(-)
> -
> -diff --git a/tests/t6001-psep.sh b/tests/t6001-psep.sh
> -index e350bd2..67014a0 100644
>  a/tests/t6001-psep.sh
> 

[OE-core] [PATCH] rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM

[Michael Ho]

From: Michael Ho 

The OpkgPM class has several constructor options that allows for skipping
the ipk repository set up and controlling the ipk repository directory. This
commit exposes these option via the OpkgRootfs class so others can make use
of them if they wish to.

Adds the bitbake variables "IPKGREPO_TARGET_PREPARED" and "IPKGREPO_TARGET"
to act as the interfaces.

Signed-off-by: Michael Ho 
---
 meta/lib/oe/package_manager/ipk/rootfs.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py 
b/meta/lib/oe/package_manager/ipk/rootfs.py
index 26dbee6..6313b72 100644
--- a/meta/lib/oe/package_manager/ipk/rootfs.py
+++ b/meta/lib/oe/package_manager/ipk/rootfs.py
@@ -129,6 +129,14 @@ class PkgRootfs(DpkgOpkgRootfs):
 self.manifest = PkgManifest(d, manifest_dir)
 self.opkg_conf = self.d.getVar("IPKGCONF_TARGET")
 self.pkg_archs = self.d.getVar("ALL_MULTILIB_PACKAGE_ARCHS")
+self.opkg_repo = self.d.getVar("IPKGREPO_TARGET")
+self.opkg_repo_prepared = self.d.getVar("IPKGREPO_TARGET_PREPARED")
+
+kwargs = {}
+if self.opkg_repo:
+kwargs["ipk_repo_workdir"] = self.opkg_repo
+if self.opkg_repo_prepared:
+kwargs["prepare_index"] = False
 
 self.inc_opkg_image_gen = self.d.getVar('INC_IPK_IMAGE_GEN') or ""
 if self._remove_old_rootfs():
@@ -136,12 +144,14 @@ class PkgRootfs(DpkgOpkgRootfs):
 self.pm = OpkgPM(d,
  self.image_rootfs,
  self.opkg_conf,
- self.pkg_archs)
+ self.pkg_archs,
+ **kwargs)
 else:
 self.pm = OpkgPM(d,
  self.image_rootfs,
  self.opkg_conf,
- self.pkg_archs)
+ self.pkg_archs,
+ **kwargs)
 self.pm.recover_packaging_data()
 
 bb.utils.remove(self.d.getVar('MULTILIB_TEMP_ROOTFS'), True)
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147685): 
https://lists.openembedded.org/g/openembedded-core/message/147685
Mute This Topic: https://lists.openembedded.org/mt/80401750/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] RFC: rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM

[Michael Ho]

From: Michael Ho 

Hi,

The OpkgPM class has two arguments for advanced control over the ipk
repository creation/use that I would like to make use of from outside of
OpkgRootfs (which wraps OpkgPM). This is for purposes beyond just standard
image generation so it's more of an advanced interface that is not intended
for normal use. In this commit, I've added the variables IPKGREPO_TARGET and
IPKGREPO_TARGET_PREPARED as interfaces to forward on to as ipk_repo_workdir
and prepare_index when calling the OpkgPM constructor.

Is this something that could be suitable for upstreaming or not likely? And
if so, should I send a patch to document these variables or leave them
undocumented like other IPKG variables (eg. IPKGCONF_TARGET).

Thanks!

Michael Ho (1):
  rootfs.py: expose prepared_index and ipk_repo_workdir for OpkgPM

 meta/lib/oe/package_manager/ipk/rootfs.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147684): 
https://lists.openembedded.org/g/openembedded-core/message/147684
Mute This Topic: https://lists.openembedded.org/mt/80401746/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] openssh: Backport a fix to fix with glibc 2.33 on some platforms

[Richard Purdie]

This fixes openssh failing to work on qemux86 with glibc 2.33 due to
seccomp and the fact new syscalls are used. Also likely fixes issues
on other platforms.

Signed-off-by: Richard Purdie 
---
 ...440ca70abab947acbd77795e9f130967956c.patch | 28 +++
 .../openssh/openssh_8.4p1.bb  |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch

diff --git 
a/meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
 
b/meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
new file mode 100644
index 000..b88bc18f120
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
@@ -0,0 +1,28 @@
+From 0f90440ca70abab947acbd77795e9f130967956c Mon Sep 17 00:00:00 2001
+From: Darren Tucker 
+Date: Fri, 20 Nov 2020 13:37:54 +1100
+Subject: [PATCH] Add new pselect6_time64 syscall on ARM.
+
+This is apparently needed on armhfp/armv7hl.  bz#3232, patch from
+jjelen at redhat.com.
+---
+ sandbox-seccomp-filter.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+Upstream-Status: Backport
+[fixes issues on 32bit IA and probably other 32 bit platforms too with glibc 
2.33]
+
+diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
+index e0768c063..5065ae7ef 100644
+--- a/sandbox-seccomp-filter.c
 b/sandbox-seccomp-filter.c
+@@ -267,6 +267,9 @@ static const struct sock_filter preauth_insns[] = {
+ #ifdef __NR_pselect6
+   SC_ALLOW(__NR_pselect6),
+ #endif
++#ifdef __NR_pselect6_time64
++  SC_ALLOW(__NR_pselect6_time64),
++#endif
+ #ifdef __NR_read
+   SC_ALLOW(__NR_read),
+ #endif
diff --git a/meta/recipes-connectivity/openssh/openssh_8.4p1.bb 
b/meta/recipes-connectivity/openssh/openssh_8.4p1.bb
index 688fc8a024e..128e2e318a3 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.4p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.4p1.bb
@@ -24,6 +24,7 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
file://sshd_check_keys \
file://add-test-support-for-busybox.patch \
+   file://0f90440ca70abab947acbd77795e9f130967956c.patch \
"
 SRC_URI[sha256sum] = 
"5a01d22e407eb1c05ba8a8f7c654d388a13e9f226e4ed33bd38748dafa1d2b24"
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147682): 
https://lists.openembedded.org/g/openembedded-core/message/147682
Mute This Topic: https://lists.openembedded.org/mt/80401570/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] pseudo: Update to work with glibc 2.33

[Richard Purdie]

Update to a pseudo version which contains some heqader fixes for
glibc 2.33.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 0ba7b503551..0072e0558b8 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -6,7 +6,7 @@ SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
file://fallback-group \
"
 
-SRCREV = "8317c0ab172db47dabcef909bae02cd77b1f1010"
+SRCREV = "f332f5633b5dd73fa2b6e5d605eb33e4a446d7ad"
 S = "${WORKDIR}/git"
 PV = "1.9.0+git${SRCPV}"
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147683): 
https://lists.openembedded.org/g/openembedded-core/message/147683
Mute This Topic: https://lists.openembedded.org/mt/80401571/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] linux/portdefs.h: Fix pseudo to work with glibc 2.33

[Richard Purdie]

In glibc 2.33, they've removed the _STAT_VER and _MKNOD_VER definitions
from public headers. They have no plans to add these back so pseudo needs
to attempt its own definitions. There is some protection as if they were
wrong and there was a mismatch, we'd get an error art runtime.

Signed-off-by: Richard Purdie 
---
 ports/linux/portdefs.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/ports/linux/portdefs.h b/ports/linux/portdefs.h
index a92e969..9545550 100644
--- a/ports/linux/portdefs.h
+++ b/ports/linux/portdefs.h
@@ -34,3 +34,22 @@ GLIBC_COMPAT_SYMBOL(memcpy,2.0);
 #include 
 #include 
 #include 
+
+#ifndef _STAT_VER
+#if defined (__aarch64__)
+#define _STAT_VER 0
+#elif defined (__x86_64__)
+#define _STAT_VER 1
+#else
+#define _STAT_VER 3
+#endif
+#endif
+#ifndef _MKNOD_VER
+#if defined (__aarch64__)
+#define _MKNOD_VER 0
+#elif defined (__x86_64__)
+#define _MKNOD_VER 0
+#else
+#define _MKNOD_VER 1
+#endif
+#endif
-- 
2.27.0


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