[OE-core] [hardknott][PATCH] sqlite3: fix CVE-2021-36690

[Changqing Li]

From: Changqing Li 

refer:
https://nvd.nist.gov/vuln/detail/CVE-2021-36690
https://www.sqlite.org/forum/forumpost/718c0a8d17
https://sqlite.org/src/info/b1e0c22ec981cf5f

Signed-off-by: Changqing Li 
---
 .../sqlite/sqlite3/CVE-2021-36690.patch   | 62 +++
 meta/recipes-support/sqlite/sqlite3_3.35.0.bb |  4 +-
 2 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2021-36690.patch

diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2021-36690.patch 
b/meta/recipes-support/sqlite/sqlite3/CVE-2021-36690.patch
new file mode 100644
index 00..d383696e42
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3/CVE-2021-36690.patch
@@ -0,0 +1,62 @@
+From c286324a7ff1e98355b638fb821614a65ee03c0c Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Tue, 14 Sep 2021 11:28:54 +0800
+Subject: [PATCH] Fix an issue with the SQLite Expert extension when a column
+ has no collating sequence. Forum post 78165fa250.
+
+Upstream-Status: Backport [https://sqlite.org/src/info/b1e0c22ec981cf5f]
+CVE: CVE-2021-36690
+
+Signed-off-by: Changqing Li 
+---
+ shell.c | 14 +-
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/shell.c b/shell.c
+index de8a665..69a5c05 100644
+--- a/shell.c
 b/shell.c
+@@ -9054,11 +9054,13 @@ static int idxGetTableInfo(
+   rc = idxPrintfPrepareStmt(db, , pzErrmsg, "PRAGMA table_xinfo=%Q", zTab);
+   while( rc==SQLITE_OK && SQLITE_ROW==sqlite3_step(p1) ){
+ const char *zCol = (const char*)sqlite3_column_text(p1, 1);
++const char *zColSeq = 0;
+ nByte += 1 + STRLEN(zCol);
+ rc = sqlite3_table_column_metadata(
+-db, "main", zTab, zCol, 0, , 0, 0, 0
++db, "main", zTab, zCol, 0, , 0, 0, 0
+ );
+-nByte += 1 + STRLEN(zCol);
++if( zColSeq==0 ) zColSeq = "binary";
++nByte += 1 + STRLEN(zColSeq);
+ nCol++;
+ nPk += (sqlite3_column_int(p1, 5)>0);
+   }
+@@ -9078,6 +9080,7 @@ static int idxGetTableInfo(
+   nCol = 0;
+   while( rc==SQLITE_OK && SQLITE_ROW==sqlite3_step(p1) ){
+ const char *zCol = (const char*)sqlite3_column_text(p1, 1);
++const char *zColSeq = 0;
+ int nCopy = STRLEN(zCol) + 1;
+ pNew->aCol[nCol].zName = pCsr;
+ pNew->aCol[nCol].iPk = (sqlite3_column_int(p1, 5)==1 && nPk==1);
+@@ -9085,12 +9088,13 @@ static int idxGetTableInfo(
+ pCsr += nCopy;
+ 
+ rc = sqlite3_table_column_metadata(
+-db, "main", zTab, zCol, 0, , 0, 0, 0
++db, "main", zTab, zCol, 0, , 0, 0, 0
+ );
+ if( rc==SQLITE_OK ){
+-  nCopy = STRLEN(zCol) + 1;
++  if( zColSeq==0 ) zColSeq = "binary";
++  nCopy = STRLEN(zColSeq) + 1;
+   pNew->aCol[nCol].zColl = pCsr;
+-  memcpy(pCsr, zCol, nCopy);
++  memcpy(pCsr, zColSeq, nCopy);
+   pCsr += nCopy;
+ }
+ 
+-- 
+2.17.1
+
diff --git a/meta/recipes-support/sqlite/sqlite3_3.35.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.35.0.bb
index 127065bbc1..8b2732640f 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.35.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.35.0.bb
@@ -3,7 +3,9 @@ require sqlite3.inc
 LICENSE = "PD"
 LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
 
-SRC_URI = "http://www.sqlite.org/2021/sqlite-autoconf-${SQLITE_PV}.tar.gz;
+SRC_URI = "http://www.sqlite.org/2021/sqlite-autoconf-${SQLITE_PV}.tar.gz \
+   file://CVE-2021-36690.patch \
+"
 SRC_URI[sha256sum] = 
"3dfb3f143c83695a555c7dd9e06ed924f9d273c287989874e102656724baf2d0"
 
 # -19242 is only an issue in specific development branch commits
-- 
2.17.1


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

Re: [OE-core][hardknott][PATCH] cpio: fix CVE-2021-38185

[Anuj Mittal]

On Mon, 2021-09-13 at 11:55 +0100, Richard Purdie wrote:
> On Mon, 2021-09-13 at 16:33 +0800, Chen Qi wrote:
> > Just found that Ross has sent out a patch for CVE-2021-38185 and it
> > has 
> > been merged in hardknott.
> > So please ignore this patch.
> > 
> > I'm also curious about how you spot such issue. By double checking
> > the 
> > commit logs in cpio repo?
> 
> I had looked at this one a little as well. I'd looked at some of the
> discussion
> from the debian community on the CVE and noticed they talked about
> regressions,
> which prompts you to look further into the issue.
> 

Yeah, that's what I had done too. Debian tracker has a nice summary:

https://security-tracker.debian.org/tracker/CVE-2021-38185

Thanks,

Anuj


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

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

[Minjae Kim]

[Edited Message Follows]

On Mon, Sep 13, 2021 at 11:34 AM, Steve Sakoman wrote:

> 
> RPMSIGTAG_FILESIGNATURELENGTH

Hi, Steve and Ranjitsinh,
Sorry for the late response.
I know that the RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH are 
defined in the original commit, but are not used.
I left it with the author`s intent. If the build goes well without those 
variables, it doesn't seem to matter.

Thanks,
Minjae Kim.

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

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

[Minjae Kim]

On Mon, Sep 13, 2021 at 11:34 AM, Steve Sakoman wrote:

> 
> RPMSIGTAG_FILESIGNATURELENGTH

Sorry for the late reponse.
I know that the RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH are 
defined in the original commit, but are not used.
I left it with the author`s intent. If the build goes well without those 
variables, it doesn't seem to matter.

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

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 384
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.4", "3.5, "3.99" and "Future", the more pressing/urgent issues
being in "3.4" and then "3.5".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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

[OE-core] busybox: rm and sed not available during upgrade

[Bryan Evenson]

All,

I have custom image based off core-image-minimal that is on the morty branch.  
I am working on upgrading the image up to the latest supported branch, one step 
at a time.  I updated to the pyro branch and got an image to build.  I am using 
opkg for a package manager.  I test firmware upgrade by executing "opkg update; 
opkg --download-only upgrade; opkg upgrade" and then looking for errors in the 
output.  I am seeing some errors during upgrade that I don't know how to fix.

When opkg removes the old version of busybox, updates-alternatives removes all 
the softlinks for busybox.  Then, it proceeds to upgrade other packages prior 
to running upgrade-alternatives to create the new softlinks for busybox.  As a 
result, the preinstall script fails on several packages because the preinstall 
script can't find rm, sed, tr or start-stop-daemon.

I don't remember seeing these errors previously.  Is there some flag or setting 
that should force busybox to complete its upgrade prior to uninstalling and 
installing other packages?

Thanks,
Bryan Evenson

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

[OE-core] how to manually discard some SDK content before bundling up the SDK?

[Robert P. J. Day]

  another off-the-wall question but i want to delete some content from
a standard SDK (sysroots/cortex.../usr/src) before creating the final
.sh script but, because of the slightly weird way this SDK is bring created
via "bitbake -c populate_sdk ...", i have little control of most of the
creation process other than right toward the end, where the easiest way
to do this would be to just sneak in a "rm -rf ..." command at the
appropriate time before the step that creates the tarball and appends it
to the .sh script in populate_sdk_base.bbclass.

  the SDK_PRE_INSTALL and SDK_POST_INSTALL variables would not quite
do it as i want to discard that content *before* creating the SDK so
that it is not in the tarball at all. i'm digging through
populate_sdk_base.bbclass right now, working backwards from the final
SDK creation step to see where i can get away with this, but if there's
a simple answer, that would be just ducky.

  in exchange for an answer, I'll proofread more documentation. :-)

rday




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

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

[Steve Sakoman]

On Wed, Sep 8, 2021 at 4:02 AM Ranjitsinh Rathod
 wrote:
>
> From: Ranjitsinh Rathod 
>
> Change in 2 patch as below to avoid critical issues
> 1) 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> Handled return values of getrlimit() and lzma_cputhreads() functions
> to avoid unexpected behaviours like devide by zero and potential read
> of uninitialized variable 'virtual_memory'
> Upstream-Status: Pending [merge of multithreading patches to upstream]
>
> 2) CVE-2021-3421.patch
> Removed RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH as
> it is not needed during backporting of original patch.
> Upstream-Status: Backport 
> [https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21]

Minjae, can you review this since he is modifying your CVE patch?

Thanks!

Steve

> Signed-off-by: Ranjitsinh Rathod 
> ---
>  ...rict-virtual-memory-usage-if-limit-s.patch | 25 ---
>  .../rpm/files/CVE-2021-3421.patch | 32 +++
>  2 files changed, 19 insertions(+), 38 deletions(-)
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
>  
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> index 6454785254..dc3f74fecd 100644
> --- 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> +++ 
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> @@ -11,36 +11,39 @@ CPU thread.
>  Upstream-Status: Pending [merge of multithreading patches to upstream]
>
>  Signed-off-by: Peter Bergin 
> +Signed-off-by: Ranjitsinh Rathod 
>  ---
> - rpmio/rpmio.c | 34 ++
> - 1 file changed, 34 insertions(+)
> + rpmio/rpmio.c | 36 
> + 1 file changed, 36 insertions(+)
>
>  diff --git a/rpmio/rpmio.c b/rpmio/rpmio.c
>  index e051c98..b3c56b6 100644
>  --- a/rpmio/rpmio.c
>  +++ b/rpmio/rpmio.c
> -@@ -845,6 +845,40 @@ static LZFILE *lzopen_internal(const char *mode, int 
> fd, int xz)
> +@@ -845,6 +845,42 @@ static LZFILE *lzopen_internal(const char *mode, int 
> fd, int xz)
> }
>   #endif
>
> -+  struct rlimit virtual_memory;
> -+  getrlimit(RLIMIT_AS, _memory);
> -+  if (virtual_memory.rlim_cur != RLIM_INFINITY) {
> ++  struct rlimit virtual_memory = {RLIM_INFINITY , 
> RLIM_INFINITY};
> ++  int status = getrlimit(RLIMIT_AS, _memory);
> ++  if ((status != -1) && (virtual_memory.rlim_cur != 
> RLIM_INFINITY)) {
>  +  const uint64_t virtual_memlimit = 
> virtual_memory.rlim_cur;
> ++  uint32_t threads_max = lzma_cputhreads();
>  +  const uint64_t virtual_memlimit_per_cpu_thread =
> -+  virtual_memlimit / lzma_cputhreads();
> -+  uint64_t memory_usage_virt;
> ++  virtual_memlimit / ((threads_max == 0) ? 1 : 
> threads_max);
>  +  rpmlog(RPMLOG_NOTICE, "XZ: virtual memory restricted 
> to %lu and "
>  + "per CPU thread %lu\n", virtual_memlimit, 
> virtual_memlimit_per_cpu_thread);
> ++  uint64_t memory_usage_virt;
>  +  /* keep reducing the number of compression threads 
> until memory
>  + usage falls below the limit per CPU thread*/
>  +  while ((memory_usage_virt = 
> lzma_stream_encoder_mt_memusage(_options)) >
>  + virtual_memlimit_per_cpu_thread) {
> -+  /* If number of threads goes down to zero 
> lzma_stream_encoder will
> -+   * will return UINT64_MAX. We must check here 
> to avoid an infinite loop.
> ++  /* If number of threads goes down to zero or 
> in case of any other error
> ++   * lzma_stream_encoder_mt_memusage will 
> return UINT64_MAX. We must check
> ++   * for both the cases here to avoid an 
> infinite loop.
>  +   * If we get into situation that one thread 
> requires more virtual memory
>  +   * than available we set one thread, print 
> error message and try anyway. */
> -+  if (--mt_options.threads == 0) {
> ++  if ((--mt_options.threads == 0) || 
> (memory_usage_virt == UINT64_MAX)) {
>  +  mt_options.threads = 1;
>  +  rpmlog(RPMLOG_WARNING,
>  + "XZ: Could not adjust number 
> of threads to get below "
> diff --git a/meta/recipes-devtools/rpm/files/CVE-2021-3421.patch 
> 

[OE-core] Release tagging scheme

[Armin Kuster]

Hello,

I don't recall if we discussed changing the release tagging scheme. I
noticed hardknott is now following the Yocto version scheme.  (eg:
hardknott-3.3.2

& yocto-3.3.2
)
while the older releases are using the Poky versioning (eg: 
dunfell-23.0.10

&  yocto-3.1.10
) .
What scheme are we going to use for  honister?

- armin

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

Re: [OE-core] [PATCH 4/4] Modify target cpu for powerpc to "7400"

[Khem Raj]

On Mon, Sep 13, 2021 at 10:35 AM Pgowda  wrote:
>
> During rust testing, some ui test failed due to following message.
> 'powerpc' is not a recognized processor for this target in rust
>
> Hence the target cpu was renamed to "7400" in "llvm_cpu" as per
> default tune for qemuppc.
>
> Signed-off-by: Pgowda 
> ---
>  meta/recipes-devtools/rust/rust-common.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/rust/rust-common.inc 
> b/meta/recipes-devtools/rust/rust-common.inc
> index 153fa3aa97..aece1247a4 100644
> --- a/meta/recipes-devtools/rust/rust-common.inc
> +++ b/meta/recipes-devtools/rust/rust-common.inc
> @@ -265,7 +265,7 @@ def llvm_cpu(d):
>  trans['x86-64'] = "x86-64"
>  trans['i686'] = "i686"
>  trans['i586'] = "i586"
> -trans['powerpc'] = "powerpc"
> +trans['powerpc'] = "7400"

interesting. what happens if you use 'ppc'

>  trans['mips64'] = "mips64"
>  trans['mips64el'] = "mips64"
>  trans['riscv64'] = "generic-rv64"
> --
> 2.31.1
>
>
> 
>

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

[OE-core] [PATCH 4/4] Modify target cpu for powerpc to "7400"

[Pgowda]

During rust testing, some ui test failed due to following message.
'powerpc' is not a recognized processor for this target in rust

Hence the target cpu was renamed to "7400" in "llvm_cpu" as per
default tune for qemuppc.

Signed-off-by: Pgowda 
---
 meta/recipes-devtools/rust/rust-common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc 
b/meta/recipes-devtools/rust/rust-common.inc
index 153fa3aa97..aece1247a4 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -265,7 +265,7 @@ def llvm_cpu(d):
 trans['x86-64'] = "x86-64"
 trans['i686'] = "i686"
 trans['i586'] = "i586"
-trans['powerpc'] = "powerpc"
+trans['powerpc'] = "7400"
 trans['mips64'] = "mips64"
 trans['mips64el'] = "mips64"
 trans['riscv64'] = "generic-rv64"
-- 
2.31.1


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

[OE-core] [PATCH 3/4] Rust oe-selftest file

[Pgowda]

Add file for rust oe-selftest

Signed-off-by: Pgowda 
---
 meta/recipes-devtools/rust/rust-testsuite_1.54.0.bb | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 meta/recipes-devtools/rust/rust-testsuite_1.54.0.bb

diff --git a/meta/recipes-devtools/rust/rust-testsuite_1.54.0.bb 
b/meta/recipes-devtools/rust/rust-testsuite_1.54.0.bb
new file mode 100644
index 00..ad758b71f4
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust-testsuite_1.54.0.bb
@@ -0,0 +1,3 @@
+require rust-testsuite.inc
+require rust-source-${PV}.inc
+require rust-snapshot-${PV}.inc
-- 
2.31.1


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

[OE-core] [PATCH 2/4] Rust cross testing file

[Pgowda]

The file is main entry point for rust oe-selftest.
It configures, compiles and runs the test suite framework.

It implements the above using the following functions:
setup_cargo_environment(): Build bootstrap and some early stage tools.
do_rust_setup_snapshot(): Install the snapshot version of rust binaries.
do_configure(): To generate config.toml
do_compile(): To build "remote-test-server" for qemutarget image.

Signed-off-by: Pgowda 
---
 meta/recipes-devtools/rust/rust-testsuite.inc | 157 ++
 1 file changed, 157 insertions(+)
 create mode 100644 meta/recipes-devtools/rust/rust-testsuite.inc

diff --git a/meta/recipes-devtools/rust/rust-testsuite.inc 
b/meta/recipes-devtools/rust/rust-testsuite.inc
new file mode 100644
index 00..0a8abbef21
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust-testsuite.inc
@@ -0,0 +1,157 @@
+SUMMARY = "Rust testing"
+HOMEPAGE = "https://rustc-dev-guide.rust-lang.org/tests/intro.html;
+SECTION = "test"
+LICENSE = "MIT | Apache-2.0"
+
+inherit rust
+inherit cargo_common
+
+DEPENDS += "file-native python3-native"
+EXCLUDE_FROM_WORLD = "1"
+
+S = "${RUSTSRC}"
+# Path of target specification file "target-poky-linux.json"
+export RUST_TARGET_PATH="${STAGING_LIBDIR_NATIVE}/rustlib"
+
+export FORCE_CRATE_HASH="${BB_TASKHASH}"
+
+# We don't want to use bitbakes vendoring because the rust sources do their
+# own vendoring.
+CARGO_DISABLE_BITBAKE_VENDORING = "1"
+
+# We can't use RUST_BUILD_SYS here because that may be "musl" if
+# TCLIBC="musl". Snapshots are always -unknown-linux-gnu
+SNAPSHOT_BUILD_SYS = "${BUILD_ARCH}-unknown-linux-gnu"
+setup_cargo_environment () {
+# The first step is to build bootstrap and some early stage tools,
+# these are build for the same target as the snapshot, e.g.
+# x86_64-unknown-linux-gnu.
+# Later stages are build for the native target (i.e. target.x86_64-linux)
+cargo_common_do_configure
+
+printf '[target.%s]\n' "${SNAPSHOT_BUILD_SYS}" >> ${CARGO_HOME}/config
+printf "linker = '%s'\n" "${RUST_BUILD_CCLD}" >> ${CARGO_HOME}/config
+}
+
+include rust-common.inc
+do_rust_setup_snapshot () {
+for installer in "${WORKDIR}/rust-snapshot-components/"*"/install.sh"; do
+"${installer}" --prefix="${WORKDIR}/rust-snapshot" --disable-ldconfig
+done
+
+# Some versions of rust (e.g. 1.18.0) tries to find cargo in 
stage0/bin/cargo
+# and fail without it there.
+mkdir -p ${RUSTSRC}/build/${BUILD_SYS}
+ln -sf ${WORKDIR}/rust-snapshot/ ${RUSTSRC}/build/${BUILD_SYS}/stage0
+}
+addtask rust_setup_snapshot after do_unpack before do_configure
+do_rust_setup_snapshot[dirs] += "${WORKDIR}/rust-snapshot"
+
+python do_configure() {
+import json
+from distutils.version import LooseVersion
+try:
+import configparser
+except ImportError:
+import ConfigParser as configparser
+
+# toml is rather similar to standard ini like format except it likes values
+# that look more JSON like. So for our purposes simply escaping all values
+# as JSON seem to work fine.
+
+e = lambda s: json.dumps(s)
+
+config = configparser.RawConfigParser()
+
+# [target.ARCH-unknown-linux-gnu] in case of x86_64 
[target.ARCH-poky-linux]
+target_section = "target.{}".format(d.getVar('TARGET_SYS', True))
+config.add_section(target_section)
+
+# Points to wrapper files which contain target specific compiler and 
linker commands.
+config.set(target_section, "cxx", e(d.expand("${RUST_TARGET_CXX}")))
+config.set(target_section, "cc", e(d.expand("${RUST_TARGET_CC}")))
+config.set(target_section, "linker", e(d.expand("${RUST_TARGET_CCLD}")))
+
+# If we don't do this rust-native will compile it's own llvm for BUILD.
+# [target.${BUILD_ARCH}-unknown-linux-gnu]
+target_section = "target.{}".format(d.getVar('SNAPSHOT_BUILD_SYS', True))
+config.add_section(target_section)
+
+# Wrapper scripts of build system.
+config.set(target_section, "cxx", e(d.expand("${RUST_BUILD_CXX}")))
+config.set(target_section, "cc", e(d.expand("${RUST_BUILD_CC}")))
+
+# [llvm]
+config.add_section("llvm")
+config.set("llvm", "targets", e("ARM;AArch64;Mips;PowerPC;RISCV;X86"))
+
+# [rust]
+config.add_section("rust")
+config.set("rust", "rpath", e(True))
+config.set("rust", "channel", e("stable"))
+
+if LooseVersion(d.getVar("PV")) < LooseVersion("1.32.0"):
+config.set("rust", "use-jemalloc", e(False))
+
+# Whether or not to optimize the compiler and standard library
+config.set("rust", "optimize", e(True))
+
+# Emits extraneous output from tests to ensure that failures of the test
+# harness are debuggable just from logfiles
+config.set("rust", "verbose-tests", e(True))
+
+# Override default linker cc.
+config.set("rust", "default-linker", e(d.expand("${RUST_BUILD_CCLD}")))
+
+# [build]
+config.add_section("build")
+config.set("build", "submodules", e(False))
+

[OE-core] [PATCH 1/4] Rust oe-selftest script

[Pgowda]

The file builds remote-test-server and executes rust testing
remotely using background ssh. It adds the necessary test environment
and variables to run the rust oe-selftest.

Print the results in case of failure of runCmd().

Signed-off-by: Pgowda 
---
 meta/lib/oeqa/selftest/cases/rust.py | 54 
 1 file changed, 54 insertions(+)
 create mode 100644 meta/lib/oeqa/selftest/cases/rust.py

diff --git a/meta/lib/oeqa/selftest/cases/rust.py 
b/meta/lib/oeqa/selftest/cases/rust.py
new file mode 100644
index 00..4ebb9045f4
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/rust.py
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: MIT
+import os
+import subprocess
+from oeqa.core.decorator import OETestTag
+from oeqa.core.case import OEPTestResultTestCase
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars, 
runqemu, Command
+from oeqa.utils.sshcontrol import SSHControl
+
+# Total time taken for testing is of about 2hr 20min, with PARALLEL_MAKE set 
to 40 number of jobs.
+class RustSelfTestBase(OESelftestTestCase, OEPTestResultTestCase):
+
+   def run_check_emulated(self, *args, **kwargs):
+   # build remote-test-server before image build
+   recipe = "rust-testsuite"
+   bitbake("{} -c compile".format(recipe))
+   builddir = get_bb_var("B", "rust-testsuite")
+   # build core-image-minimal with required packages
+   default_installed_packages = ["libgcc", "libstdc++", 
"libatomic", "libgomp"]
+   features = []
+   features.append('IMAGE_FEATURES += "ssh-server-openssh"')
+   features.append('CORE_IMAGE_EXTRA_INSTALL += "{0}"'.format(" 
".join(default_installed_packages)))
+   self.write_config("\n".join(features))
+   bitbake("core-image-minimal")
+   # wrap the execution with a qemu instance
+   with runqemu("core-image-minimal", runqemuparams = "nographic", 
qemuparams = "-m 512") as qemu:
+#  with runqemu("core-image-minimal", runqemuparams = "nographic") 
as qemu:
+   # Copy remote-test-server to image through scp
+   ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, 
user="root")
+   ssh.copy_to(builddir + "/" + 
"build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server","~/")
+   # Execute remote-test-server on image through 
background ssh
+   command = '~/remote-test-server -v remote'
+   sshrun=subprocess.Popen(("ssh", '-o',  
'UserKnownHostsFile=/dev/null', '-o',  'StrictHostKeyChecking=no', '-f', 
"root@%s" % qemu.ip, command),
+shell=False,
+stdout=subprocess.PIPE,
+stderr=subprocess.PIPE)
+   # Get the values of variables.
+   targetsys = get_bb_var("TARGET_SYS", "rust-testsuite")
+   rustlibpath = get_bb_var("STAGING_LIBDIR_NATIVE", 
"rust-testsuite")
+   tmpdir = get_bb_var("TMPDIR", "rust-testsuite")
+   testargs = "--no-fail-fast --bless"
+   # Set path for target-poky-linux-gcc, RUST_TARGET_PATH 
and hosttools.
+   cmd = " export PATH=%s/../bin:$PATH;" % rustlibpath
+   cmd = cmd + " export 
PATH=%s/../bin/%s:%s/hosttools:$PATH;" % (rustlibpath, targetsys, tmpdir)
+   cmd = cmd + " export RUST_TARGET_PATH=%s/rustlib;" % 
rustlibpath
+   # Trigger testing.
+   cmd = cmd + " export TEST_DEVICE_ADDR=\"%s:12345\";" % 
qemu.ip
+   cmd = cmd + " cd %s;  python3 
src/bootstrap/bootstrap.py test %s --target %s ;" % (builddir, testargs, 
targetsys)
+   result = runCmd(cmd)
+
+@OETestTag("toolchain-system")
+class RustSelfTestSystemEmulated(RustSelfTestBase):
+   def test_rust(self):
+   self.run_check_emulated("rust")
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155987): 
https://lists.openembedded.org/g/openembedded-core/message/155987
Mute This Topic: https://lists.openembedded.org/mt/85581535/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] [yocto-security] OE-core CVE metrics for hardknott on Sun 12 Sep 2021 05:00:01 AM HST

[Steve Sakoman]

On Mon, Sep 13, 2021 at 7:01 AM Richard Purdie
 wrote:
>
> On Mon, 2021-09-13 at 05:19 -1000, Steve Sakoman wrote:
> > On Sun, Sep 12, 2021 at 6:05 AM Steve Sakoman via
> > lists.openembedded.org 
> > wrote:
> > >
> > >
> > >
> > > On Sun, Sep 12, 2021, 5:57 AM Richard Purdie 
> > >  wrote:
> > > >
> > > > On Sun, 2021-09-12 at 05:01 -1000, Steve Sakoman wrote:
> > > > > Branch: hardknott
> > > > >
> > > > > New this week: 0 CVEs
> > > > >
> > > > > Removed this week: 2 CVEs
> > > > > CVE-2020-27748: xdg-utils 
> > > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27748 *
> > > > > CVE-2021-38185: cpio 
> > > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-38185 *
> > > >
> > > > I'm not sure I believe these numbers as tar CVEs which showed up for 
> > > > dunfell and
> > > > master don't show up here. Why? :/
> > >
> > >
> > > Don't know! Will investigate tomorrow.
> >
> > I re-ran the hardknott report this morning and it now includes the
> > missing tar cve's (as well as the libsolv, vim, and inetutils cve's we
> > saw in master/dunfell)
> >
> > No idea why these weren't in yesterday's report since they were
> > obviously in the upstream database and appeared in the master and
> > dunfell runs (and hardknott runs last)
> >
> > I've seen this kind of thing once or twice in the past and have never
> > been able to figure out what is going on since it is so intermittent.
>
> I'm not sure how we pull the database but is it possible that there are 
> multiple
> upstream servers of that data and we pull from different instances which may 
> not
> have all updated to the same data? Would there be any way to investigate/prove
> that?

Taking a quick look at the code in cve-update-db-native.bb I see that
database updates can fail with a warning message printed.  So it could
well be that the update failed for some reason, printed the warning,
and then used the old database for the scan. That would explain what
we are seeing.

Perhaps someone who knows the code better can comment (Ross? I see
you've mucked about in this section of the code!)

Unfortunately I didn't enable cron logging on the machine that does
the reports, but I will enable that now so that I can examine the cron
output if this happens in the future.

> I'm a little worried about the inconsistencies. I'm guessing your builds don't
> share a DL_DIR so they'd fetch different CVE databases?

Correct -- I use a separate DL_DIR for each branch.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155986): 
https://lists.openembedded.org/g/openembedded-core/message/155986
Mute This Topic: https://lists.openembedded.org/mt/85554291/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] [yocto-security] OE-core CVE metrics for hardknott on Sun 12 Sep 2021 05:00:01 AM HST

[Richard Purdie]

On Mon, 2021-09-13 at 05:19 -1000, Steve Sakoman wrote:
> On Sun, Sep 12, 2021 at 6:05 AM Steve Sakoman via
> lists.openembedded.org 
> wrote:
> > 
> > 
> > 
> > On Sun, Sep 12, 2021, 5:57 AM Richard Purdie 
> >  wrote:
> > > 
> > > On Sun, 2021-09-12 at 05:01 -1000, Steve Sakoman wrote:
> > > > Branch: hardknott
> > > > 
> > > > New this week: 0 CVEs
> > > > 
> > > > Removed this week: 2 CVEs
> > > > CVE-2020-27748: xdg-utils 
> > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27748 *
> > > > CVE-2021-38185: cpio 
> > > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-38185 *
> > > 
> > > I'm not sure I believe these numbers as tar CVEs which showed up for 
> > > dunfell and
> > > master don't show up here. Why? :/
> > 
> > 
> > Don't know! Will investigate tomorrow.
> 
> I re-ran the hardknott report this morning and it now includes the
> missing tar cve's (as well as the libsolv, vim, and inetutils cve's we
> saw in master/dunfell)
> 
> No idea why these weren't in yesterday's report since they were
> obviously in the upstream database and appeared in the master and
> dunfell runs (and hardknott runs last)
> 
> I've seen this kind of thing once or twice in the past and have never
> been able to figure out what is going on since it is so intermittent.

I'm not sure how we pull the database but is it possible that there are multiple
upstream servers of that data and we pull from different instances which may not
have all updated to the same data? Would there be any way to investigate/prove
that?

I'm a little worried about the inconsistencies. I'm guessing your builds don't
share a DL_DIR so they'd fetch different CVE databases?

Cheers,

Richard




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

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

[Ranjitsinh Rathod]

Can someone please check this and confirm if this can go on dunfell?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155984): 
https://lists.openembedded.org/g/openembedded-core/message/155984
Mute This Topic: https://lists.openembedded.org/mt/85459532/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] libxcrypt: Add fix for CVE-2021-33560

[saloni]

Happy to help!  
I really appreciate you taking time to express gratitude.


Thanks & Regards,
Saloni Jain

From: Steve Sakoman 
Sent: Monday, September 13, 2021 9:03 PM
To: Saloni Jain 
Cc: Patches and discussions about the oe-core layer 
; Khem Raj ; 
Nisha Parrakat ; Saloni Jain 
Subject: Re: [OE-core] [poky][dunfell][PATCH] libxcrypt: Add fix for 
CVE-2021-33560

Caution: This email originated from outside of the KPIT. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.

On Mon, Sep 13, 2021 at 3:16 AM Saloni Jain  wrote:
>
> From: Saloni Jain 
>
> Add fix for below CVE:
> CVE-2021-33560

Armin submitted a patch for this CVE last week:

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openembedded.org%2Fg%2Fopenembedded-core%2Fmessage%2F155935data=04%7C01%7CSaloni.Jain%40kpit.com%7Cab35b176f5054ba2760408d976cbd354%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637671440110080648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=drHkzkMi9PsPKXMK88kMxtc1tPfrCl72UfDLLYlx7yQ%3Dreserved=0

Thanks for helping with CVE's though, I appreciate the effort!

Steve

> Link: 
> [https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.gnupg.org%2Fcgi-bin%2Fgitweb.cgi%3Fp%3Dlibgcrypt.git%3Ba%3Dpatch%3Bh%3D3462280f2e23e16adf3ed5176e0f2413d8861320data=04%7C01%7CSaloni.Jain%40kpit.com%7Cab35b176f5054ba2760408d976cbd354%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637671440110080648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mxW8l7hc7mDiu3UKIXQegIMJsP6kWfWmJ%2FbkQEVL958%3Dreserved=0]
>
> Signed-off-by: Saloni Jain
> ---
>  .../libgcrypt/files/CVE-2021-33560.patch  | 108 ++
>  .../libgcrypt/libgcrypt_1.8.5.bb  |   1 +
>  2 files changed, 109 insertions(+)
>  create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
>
> diff --git a/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch 
> b/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
> new file mode 100644
> index 00..ba51af46b3
> --- /dev/null
> +++ b/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
> @@ -0,0 +1,108 @@
> +From 3462280f2e23e16adf3ed5176e0f2413d8861320 Mon Sep 17 00:00:00 2001
> +From: NIIBE Yutaka 
> +Date: Fri, 21 May 2021 11:15:07 +0900
> +Subject: [PATCH] cipher: Fix ElGamal encryption for other implementations.
> +
> +* cipher/elgamal.c (gen_k): Remove support of smaller K.
> +(do_encrypt): Never use smaller K.
> +(sign): Folllow the change of gen_k.
> +
> +--
> +
> +Cherry-pick master commit of:
> +   632d80ef30e13de6926d503aa697f92b5dbfbc5e
> +
> +This change basically reverts encryption changes in two commits:
> +
> +   74386120dad6b3da62db37f7044267c8ef34689b
> +   78531373a342aeb847950f404343a05e36022065
> +
> +Use of smaller K for ephemeral key in ElGamal encryption is only good,
> +when we can guarantee that recipient's key is generated by our
> +implementation (or compatible).
> +
> +For detail, please see:
> +
> +Luca De Feo, Bertram Poettering, Alessandro Sorniotti,
> +"On the (in)security of ElGamal in OpenPGP";
> +in the proceedings of  CCS'2021.
> +
> +CVE: CVE-2021-33560
> +GnuPG-bug-id: 5328
> +Suggested-by: Luca De Feo, Bertram Poettering, Alessandro Sorniotti
> +Signed-off-by: NIIBE Yutaka 
> +Signed-off-by: Saloni Jain 
> +
> +Upstream-Status: Backport 
> [https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.gnupg.org%2Fcgi-bin%2Fgitweb.cgi%3Fp%3Dlibgcrypt.git%3Ba%3Dpatch%3Bh%3D3462280f2e23e16adf3ed5176e0f2413d8861320data=04%7C01%7CSaloni.Jain%40kpit.com%7Cab35b176f5054ba2760408d976cbd354%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637671440110090650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=XEr2AaiwglyGxJRihsQJmNwA5jqW5mO%2FHHNOtWgoI1o%3Dreserved=0]
> +Comment: No changes/refreshing done.
> +---
> + cipher/elgamal.c | 24 ++--
> + 1 file changed, 6 insertions(+), 18 deletions(-)
> +
> +diff --git a/cipher/elgamal.c b/cipher/elgamal.c
> +index 9835122f..eead4502 100644
> +--- a/cipher/elgamal.c
>  b/cipher/elgamal.c
> +@@ -66,7 +66,7 @@ static const char *elg_names[] =
> +
> +
> + static int test_keys (ELG_secret_key *sk, unsigned int nbits, int nodie);
> +-static gcry_mpi_t gen_k (gcry_mpi_t p, int small_k);
> ++static gcry_mpi_t gen_k (gcry_mpi_t p);
> + static gcry_err_code_t generate (ELG_secret_key *sk, unsigned nbits,
> +  gcry_mpi_t **factors);
> + static int  check_secret_key (ELG_secret_key *sk);
> +@@ -189,11 +189,10 @@ test_keys ( ELG_secret_key *sk, unsigned int nbits, 
> int nodie )
> +
> + /
> +  * Generate a random secret exponent k from prime p, so that k is
> +- * relatively prime to p-1.  With SMALL_K set, k will be selected for
> +- 

Re: [OE-core] [poky][dunfell][PATCH] libxcrypt: Add fix for CVE-2021-33560

[Steve Sakoman]

On Mon, Sep 13, 2021 at 3:16 AM Saloni Jain  wrote:
>
> From: Saloni Jain 
>
> Add fix for below CVE:
> CVE-2021-33560

Armin submitted a patch for this CVE last week:

https://lists.openembedded.org/g/openembedded-core/message/155935

Thanks for helping with CVE's though, I appreciate the effort!

Steve

> Link: 
> [https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=3462280f2e23e16adf3ed5176e0f2413d8861320]
>
> Signed-off-by: Saloni Jain
> ---
>  .../libgcrypt/files/CVE-2021-33560.patch  | 108 ++
>  .../libgcrypt/libgcrypt_1.8.5.bb  |   1 +
>  2 files changed, 109 insertions(+)
>  create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
>
> diff --git a/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch 
> b/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
> new file mode 100644
> index 00..ba51af46b3
> --- /dev/null
> +++ b/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
> @@ -0,0 +1,108 @@
> +From 3462280f2e23e16adf3ed5176e0f2413d8861320 Mon Sep 17 00:00:00 2001
> +From: NIIBE Yutaka 
> +Date: Fri, 21 May 2021 11:15:07 +0900
> +Subject: [PATCH] cipher: Fix ElGamal encryption for other implementations.
> +
> +* cipher/elgamal.c (gen_k): Remove support of smaller K.
> +(do_encrypt): Never use smaller K.
> +(sign): Folllow the change of gen_k.
> +
> +--
> +
> +Cherry-pick master commit of:
> +   632d80ef30e13de6926d503aa697f92b5dbfbc5e
> +
> +This change basically reverts encryption changes in two commits:
> +
> +   74386120dad6b3da62db37f7044267c8ef34689b
> +   78531373a342aeb847950f404343a05e36022065
> +
> +Use of smaller K for ephemeral key in ElGamal encryption is only good,
> +when we can guarantee that recipient's key is generated by our
> +implementation (or compatible).
> +
> +For detail, please see:
> +
> +Luca De Feo, Bertram Poettering, Alessandro Sorniotti,
> +"On the (in)security of ElGamal in OpenPGP";
> +in the proceedings of  CCS'2021.
> +
> +CVE: CVE-2021-33560
> +GnuPG-bug-id: 5328
> +Suggested-by: Luca De Feo, Bertram Poettering, Alessandro Sorniotti
> +Signed-off-by: NIIBE Yutaka 
> +Signed-off-by: Saloni Jain 
> +
> +Upstream-Status: Backport 
> [https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=3462280f2e23e16adf3ed5176e0f2413d8861320]
> +Comment: No changes/refreshing done.
> +---
> + cipher/elgamal.c | 24 ++--
> + 1 file changed, 6 insertions(+), 18 deletions(-)
> +
> +diff --git a/cipher/elgamal.c b/cipher/elgamal.c
> +index 9835122f..eead4502 100644
> +--- a/cipher/elgamal.c
>  b/cipher/elgamal.c
> +@@ -66,7 +66,7 @@ static const char *elg_names[] =
> +
> +
> + static int test_keys (ELG_secret_key *sk, unsigned int nbits, int nodie);
> +-static gcry_mpi_t gen_k (gcry_mpi_t p, int small_k);
> ++static gcry_mpi_t gen_k (gcry_mpi_t p);
> + static gcry_err_code_t generate (ELG_secret_key *sk, unsigned nbits,
> +  gcry_mpi_t **factors);
> + static int  check_secret_key (ELG_secret_key *sk);
> +@@ -189,11 +189,10 @@ test_keys ( ELG_secret_key *sk, unsigned int nbits, 
> int nodie )
> +
> + /
> +  * Generate a random secret exponent k from prime p, so that k is
> +- * relatively prime to p-1.  With SMALL_K set, k will be selected for
> +- * better encryption performance - this must never be used signing!
> ++ * relatively prime to p-1.
> +  */
> + static gcry_mpi_t
> +-gen_k( gcry_mpi_t p, int small_k )
> ++gen_k( gcry_mpi_t p )
> + {
> +   gcry_mpi_t k = mpi_alloc_secure( 0 );
> +   gcry_mpi_t temp = mpi_alloc( mpi_get_nlimbs(p) );
> +@@ -202,18 +201,7 @@ gen_k( gcry_mpi_t p, int small_k )
> +   unsigned int nbits, nbytes;
> +   char *rndbuf = NULL;
> +
> +-  if (small_k)
> +-{
> +-  /* Using a k much lesser than p is sufficient for encryption and
> +-   * it greatly improves the encryption performance.  We use
> +-   * Wiener's table and add a large safety margin. */
> +-  nbits = wiener_map( orig_nbits ) * 3 / 2;
> +-  if( nbits >= orig_nbits )
> +-BUG();
> +-}
> +-  else
> +-nbits = orig_nbits;
> +-
> ++  nbits = orig_nbits;
> +
> +   nbytes = (nbits+7)/8;
> +   if( DBG_CIPHER )
> +@@ -492,7 +480,7 @@ do_encrypt(gcry_mpi_t a, gcry_mpi_t b, gcry_mpi_t input, 
> ELG_public_key *pkey )
> +* error code.
> +*/
> +
> +-  k = gen_k( pkey->p, 1 );
> ++  k = gen_k( pkey->p );
> +   mpi_powm (a, pkey->g, k, pkey->p);
> +
> +   /* b = (y^k * input) mod p
> +@@ -608,7 +596,7 @@ sign(gcry_mpi_t a, gcry_mpi_t b, gcry_mpi_t input, 
> ELG_secret_key *skey )
> + *
> + */
> + mpi_sub_ui(p_1, p_1, 1);
> +-k = gen_k( skey->p, 0 /* no small K ! */ );
> ++k = gen_k( skey->p );
> + mpi_powm( a, skey->g, k, skey->p );
> + mpi_mul(t, skey->x, a );
> + mpi_subm(t, input, t, p_1 );
> +--
> +2.11.0
> diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb 
> b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
> 

Re: [OE-core] [yocto-security] OE-core CVE metrics for hardknott on Sun 12 Sep 2021 05:00:01 AM HST

[Steve Sakoman]

On Sun, Sep 12, 2021 at 6:05 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
>
>
> On Sun, Sep 12, 2021, 5:57 AM Richard Purdie 
>  wrote:
>>
>> On Sun, 2021-09-12 at 05:01 -1000, Steve Sakoman wrote:
>> > Branch: hardknott
>> >
>> > New this week: 0 CVEs
>> >
>> > Removed this week: 2 CVEs
>> > CVE-2020-27748: xdg-utils 
>> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27748 *
>> > CVE-2021-38185: cpio 
>> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-38185 *
>>
>> I'm not sure I believe these numbers as tar CVEs which showed up for dunfell 
>> and
>> master don't show up here. Why? :/
>
>
> Don't know! Will investigate tomorrow.

I re-ran the hardknott report this morning and it now includes the
missing tar cve's (as well as the libsolv, vim, and inetutils cve's we
saw in master/dunfell)

No idea why these weren't in yesterday's report since they were
obviously in the upstream database and appeared in the master and
dunfell runs (and hardknott runs last)

I've seen this kind of thing once or twice in the past and have never
been able to figure out what is going on since it is so intermittent.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155980): 
https://lists.openembedded.org/g/openembedded-core/message/155980
Mute This Topic: https://lists.openembedded.org/mt/85554291/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] db: Whitelist CVEs

[Steve Sakoman]

On Mon, Sep 13, 2021 at 4:56 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> On Mon, Sep 13, 2021 at 2:45 AM Saloni Jain  wrote:
> >
> > From: Saloni Jain 
> >
> > Below CVE affects only Oracle Berkeley DB as per upstream.
> > Hence, whitelisted them.
>
> I suspect that a cleaner solution might be to revert:
>
> db: update CVE_PRODUCT
> (https://git.openembedded.org/openembedded-core/commit/?id=ad799b109716ccd2f44dcf7a6a4cfcbd622ea661)
>
> which adds berkeley_db to CVE_PRODUCT
>
> I did a quick test and this eliminates all of the CVE's below. And of
> course it makes sense to only check for oracle_berkeley_db since that
> is the source code we are using.
>
> Also, this same issue is present in master, so any fix would need to
> go there first and I will cherry-pick.
>
> Could you confirm that this approach works for you too?

And for those who are wondering why the db CVE's don't show up in the
weekly reports, it is because the script that Ross provided me many
moons ago whitelisted db and db-native.

I figured he had a good reason for that, so I left it in for
consistency with the reports he had run :-)

db and db-native are the only whitelisted packages for those who might
be wondering.

Steve

> > 1. CVE-2015-2583
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-2583
> > 2. CVE-2015-2624
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-2624
> > 3. CVE-2015-2626
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-2626
> > 4. CVE-2015-2640
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-2640
> > 5. CVE-2015-2654
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-2654
> > 6. CVE-2015-2656
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-2656
> > 7. CVE-2015-4754
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4754
> > 8. CVE-2015-4764
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4764
> > 9. CVE-2015-4774
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4774
> > 10. CVE-2015-4775
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4775
> > 11. CVE-2015-4776
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4776
> > 12. CVE-2015-4777
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4777
> > 13. CVE-2015-4778
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4778
> > 14. CVE-2015-4779
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4779
> > 15. CVE-2015-4780
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4780
> > 16. CVE-2015-4781
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4781
> > 17. CVE-2015-4782
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4782
> > 18. CVE-2015-4783
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4783
> > 19. CVE-2015-4784
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4784
> > 20. CVE-2015-4785
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4785
> > 21. CVE-2015-4786
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4786
> > 22. CVE-2015-4787
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4787
> > 23. CVE-2015-4788
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4788
> > 24. CVE-2015-4789
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4789
> > 25. CVE-2015-4790
> > Link: https://security-tracker.debian.org/tracker/CVE-2015-4790
> > 26. CVE-2016-0682
> > Link: https://security-tracker.debian.org/tracker/CVE-2016-0682
> > 27. CVE-2016-0689
> > Link: https://security-tracker.debian.org/tracker/CVE-2016-0689
> > 28. CVE-2016-0692
> > Link: https://security-tracker.debian.org/tracker/CVE-2016-0692
> > 29. CVE-2016-0694
> > Link: https://security-tracker.debian.org/tracker/CVE-2016-0694
> > 30. CVE-2016-3418
> > Link: https://security-tracker.debian.org/tracker/CVE-2016-3418
> > 31. CVE-2017-3604
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3604
> > 32. CVE-2017-3605
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3605
> > 33. CVE-2017-3606
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3606
> > 34. CVE-2017-3607
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3607
> > 35. CVE-2017-3608
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3608
> > 36. CVE-2017-3609
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3609
> > 37. CVE-2017-3610
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3610
> > 38. CVE-2017-3611
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3611
> > 39. CVE-2017-3612
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3612
> > 40. CVE-2017-3613
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3613
> > 41. CVE-2017-3614
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3614
> > 42. CVE-2017-3615
> > Link: https://security-tracker.debian.org/tracker/CVE-2017-3615
> > 

Re: [OE-core] [poky][dunfell][PATCH] db: Whitelist CVEs

[Steve Sakoman]

On Mon, Sep 13, 2021 at 2:45 AM Saloni Jain  wrote:
>
> From: Saloni Jain 
>
> Below CVE affects only Oracle Berkeley DB as per upstream.
> Hence, whitelisted them.

I suspect that a cleaner solution might be to revert:

db: update CVE_PRODUCT
(https://git.openembedded.org/openembedded-core/commit/?id=ad799b109716ccd2f44dcf7a6a4cfcbd622ea661)

which adds berkeley_db to CVE_PRODUCT

I did a quick test and this eliminates all of the below CVE's. And of
course it makes sense to only check for oracle_berkeley_db since that
is the source code we are using.

Also, this same issue is present in master, so any fix would need to
go there first and I will cherry-pick.

Could you confirm that this approach works for you too?

Steve

>
> 1. CVE-2015-2583
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2583
> 2. CVE-2015-2624
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2624
> 3. CVE-2015-2626
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2626
> 4. CVE-2015-2640
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2640
> 5. CVE-2015-2654
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2654
> 6. CVE-2015-2656
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2656
> 7. CVE-2015-4754
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4754
> 8. CVE-2015-4764
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4764
> 9. CVE-2015-4774
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4774
> 10. CVE-2015-4775
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4775
> 11. CVE-2015-4776
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4776
> 12. CVE-2015-4777
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4777
> 13. CVE-2015-4778
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4778
> 14. CVE-2015-4779
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4779
> 15. CVE-2015-4780
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4780
> 16. CVE-2015-4781
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4781
> 17. CVE-2015-4782
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4782
> 18. CVE-2015-4783
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4783
> 19. CVE-2015-4784
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4784
> 20. CVE-2015-4785
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4785
> 21. CVE-2015-4786
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4786
> 22. CVE-2015-4787
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4787
> 23. CVE-2015-4788
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4788
> 24. CVE-2015-4789
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4789
> 25. CVE-2015-4790
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4790
> 26. CVE-2016-0682
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0682
> 27. CVE-2016-0689
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0689
> 28. CVE-2016-0692
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0692
> 29. CVE-2016-0694
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0694
> 30. CVE-2016-3418
> Link: https://security-tracker.debian.org/tracker/CVE-2016-3418
> 31. CVE-2017-3604
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3604
> 32. CVE-2017-3605
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3605
> 33. CVE-2017-3606
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3606
> 34. CVE-2017-3607
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3607
> 35. CVE-2017-3608
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3608
> 36. CVE-2017-3609
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3609
> 37. CVE-2017-3610
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3610
> 38. CVE-2017-3611
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3611
> 39. CVE-2017-3612
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3612
> 40. CVE-2017-3613
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3613
> 41. CVE-2017-3614
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3614
> 42. CVE-2017-3615
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3615
> 43. CVE-2017-3616
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3616
> 44. CVE-2017-3617
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3617
> 45. CVE-2020-2981
> Link: https://security-tracker.debian.org/tracker/CVE-2020-2981
>
> Signed-off-by: Saloni 
> ---
>  meta/recipes-support/db/db_5.3.28.bb | 92 
>  1 file changed, 92 insertions(+)
>
> diff --git a/meta/recipes-support/db/db_5.3.28.bb 
> b/meta/recipes-support/db/db_5.3.28.bb
> index b2ae98f05c..000e9ef468 100644
> --- a/meta/recipes-support/db/db_5.3.28.bb
> +++ b/meta/recipes-support/db/db_5.3.28.bb
> @@ -39,6 +39,98 @@ 

Re: [OE-core] [poky][dunfell][PATCH] db: Whitelist CVEs

[Armin Kuster]

Saloni,

Thanks for the CVE cleanup.

On 9/13/21 5:45 AM, Saloni Jain wrote:
> From: Saloni Jain 
>
> Below CVE affects only Oracle Berkeley DB as per upstream.
> Hence, whitelisted them.

This situation will happen more frequently than one thinks including
with mariadb recipe.  I wounder if a "${PN}_cve_ exclude.inc"  like
scheme may help keep the recipe from getting hard to read if the listing
gets out of control?

- Armin


>
> 1. CVE-2015-2583
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2583
> 2. CVE-2015-2624
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2624
> 3. CVE-2015-2626
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2626
> 4. CVE-2015-2640
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2640
> 5. CVE-2015-2654
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2654
> 6. CVE-2015-2656
> Link: https://security-tracker.debian.org/tracker/CVE-2015-2656
> 7. CVE-2015-4754
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4754
> 8. CVE-2015-4764
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4764
> 9. CVE-2015-4774
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4774
> 10. CVE-2015-4775
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4775
> 11. CVE-2015-4776
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4776
> 12. CVE-2015-4777
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4777
> 13. CVE-2015-4778
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4778
> 14. CVE-2015-4779
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4779
> 15. CVE-2015-4780
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4780
> 16. CVE-2015-4781
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4781
> 17. CVE-2015-4782
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4782
> 18. CVE-2015-4783
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4783
> 19. CVE-2015-4784
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4784
> 20. CVE-2015-4785
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4785
> 21. CVE-2015-4786
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4786
> 22. CVE-2015-4787
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4787
> 23. CVE-2015-4788
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4788
> 24. CVE-2015-4789
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4789
> 25. CVE-2015-4790
> Link: https://security-tracker.debian.org/tracker/CVE-2015-4790
> 26. CVE-2016-0682
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0682
> 27. CVE-2016-0689
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0689
> 28. CVE-2016-0692
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0692
> 29. CVE-2016-0694
> Link: https://security-tracker.debian.org/tracker/CVE-2016-0694
> 30. CVE-2016-3418
> Link: https://security-tracker.debian.org/tracker/CVE-2016-3418
> 31. CVE-2017-3604
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3604
> 32. CVE-2017-3605
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3605
> 33. CVE-2017-3606
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3606
> 34. CVE-2017-3607
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3607
> 35. CVE-2017-3608
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3608
> 36. CVE-2017-3609
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3609
> 37. CVE-2017-3610
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3610
> 38. CVE-2017-3611
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3611
> 39. CVE-2017-3612
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3612
> 40. CVE-2017-3613
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3613
> 41. CVE-2017-3614
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3614
> 42. CVE-2017-3615
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3615
> 43. CVE-2017-3616
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3616
> 44. CVE-2017-3617
> Link: https://security-tracker.debian.org/tracker/CVE-2017-3617
> 45. CVE-2020-2981
> Link: https://security-tracker.debian.org/tracker/CVE-2020-2981
>
> Signed-off-by: Saloni 
> ---
>  meta/recipes-support/db/db_5.3.28.bb | 92 
>  1 file changed, 92 insertions(+)
>
> diff --git a/meta/recipes-support/db/db_5.3.28.bb 
> b/meta/recipes-support/db/db_5.3.28.bb
> index b2ae98f05c..000e9ef468 100644
> --- a/meta/recipes-support/db/db_5.3.28.bb
> +++ b/meta/recipes-support/db/db_5.3.28.bb
> @@ -39,6 +39,98 @@ SRC_URI[sha256sum] = 
> "e0a992d740709892e81f9d93f06daf305cf73fb81b545afe7247804317
>  
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=ed1158e31437f4f87cdd4ab2b8613955"
>  
> +# Below CVEs affects only Oracle Berkeley DB as per upstream.
> +# https://security-tracker.debian.org/tracker/CVE-2015-2583
> 

Re: [OE-core] [hardknott][PATCH] bitbake: server: Fix early parsing errors preventing zombie bitbake

[Chris Laplante via lists.openembedded.org]

Hi Anuj,

> Thanks, this is the right way to request a backport. But since this is a 
> bitbake
> change, should have been sent to the bitbake list. I had picked this though so
> no need to re-send.

Ah right. Thank you!
Chris 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155976): 
https://lists.openembedded.org/g/openembedded-core/message/155976
Mute This Topic: https://lists.openembedded.org/mt/85254139/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] libxcrypt: Add fix for CVE-2021-33560

[Saloni Jain]

From: Saloni Jain 

Add fix for below CVE:
CVE-2021-33560
Link: 
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=3462280f2e23e16adf3ed5176e0f2413d8861320]

Signed-off-by: Saloni Jain
---
 .../libgcrypt/files/CVE-2021-33560.patch  | 108 ++
 .../libgcrypt/libgcrypt_1.8.5.bb  |   1 +
 2 files changed, 109 insertions(+)
 create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch

diff --git a/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch 
b/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
new file mode 100644
index 00..ba51af46b3
--- /dev/null
+++ b/meta/recipes-support/libgcrypt/files/CVE-2021-33560.patch
@@ -0,0 +1,108 @@
+From 3462280f2e23e16adf3ed5176e0f2413d8861320 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka 
+Date: Fri, 21 May 2021 11:15:07 +0900
+Subject: [PATCH] cipher: Fix ElGamal encryption for other implementations.
+
+* cipher/elgamal.c (gen_k): Remove support of smaller K.
+(do_encrypt): Never use smaller K.
+(sign): Folllow the change of gen_k.
+
+--
+
+Cherry-pick master commit of:
+   632d80ef30e13de6926d503aa697f92b5dbfbc5e
+
+This change basically reverts encryption changes in two commits:
+
+   74386120dad6b3da62db37f7044267c8ef34689b
+   78531373a342aeb847950f404343a05e36022065
+
+Use of smaller K for ephemeral key in ElGamal encryption is only good,
+when we can guarantee that recipient's key is generated by our
+implementation (or compatible).
+
+For detail, please see:
+
+Luca De Feo, Bertram Poettering, Alessandro Sorniotti,
+"On the (in)security of ElGamal in OpenPGP";
+in the proceedings of  CCS'2021.
+
+CVE: CVE-2021-33560
+GnuPG-bug-id: 5328
+Suggested-by: Luca De Feo, Bertram Poettering, Alessandro Sorniotti
+Signed-off-by: NIIBE Yutaka 
+Signed-off-by: Saloni Jain 
+
+Upstream-Status: Backport 
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=3462280f2e23e16adf3ed5176e0f2413d8861320]
+Comment: No changes/refreshing done.
+---
+ cipher/elgamal.c | 24 ++--
+ 1 file changed, 6 insertions(+), 18 deletions(-)
+
+diff --git a/cipher/elgamal.c b/cipher/elgamal.c
+index 9835122f..eead4502 100644
+--- a/cipher/elgamal.c
 b/cipher/elgamal.c
+@@ -66,7 +66,7 @@ static const char *elg_names[] =
+ 
+ 
+ static int test_keys (ELG_secret_key *sk, unsigned int nbits, int nodie);
+-static gcry_mpi_t gen_k (gcry_mpi_t p, int small_k);
++static gcry_mpi_t gen_k (gcry_mpi_t p);
+ static gcry_err_code_t generate (ELG_secret_key *sk, unsigned nbits,
+  gcry_mpi_t **factors);
+ static int  check_secret_key (ELG_secret_key *sk);
+@@ -189,11 +189,10 @@ test_keys ( ELG_secret_key *sk, unsigned int nbits, int 
nodie )
+ 
+ /
+  * Generate a random secret exponent k from prime p, so that k is
+- * relatively prime to p-1.  With SMALL_K set, k will be selected for
+- * better encryption performance - this must never be used signing!
++ * relatively prime to p-1.
+  */
+ static gcry_mpi_t
+-gen_k( gcry_mpi_t p, int small_k )
++gen_k( gcry_mpi_t p )
+ {
+   gcry_mpi_t k = mpi_alloc_secure( 0 );
+   gcry_mpi_t temp = mpi_alloc( mpi_get_nlimbs(p) );
+@@ -202,18 +201,7 @@ gen_k( gcry_mpi_t p, int small_k )
+   unsigned int nbits, nbytes;
+   char *rndbuf = NULL;
+ 
+-  if (small_k)
+-{
+-  /* Using a k much lesser than p is sufficient for encryption and
+-   * it greatly improves the encryption performance.  We use
+-   * Wiener's table and add a large safety margin. */
+-  nbits = wiener_map( orig_nbits ) * 3 / 2;
+-  if( nbits >= orig_nbits )
+-BUG();
+-}
+-  else
+-nbits = orig_nbits;
+-
++  nbits = orig_nbits;
+ 
+   nbytes = (nbits+7)/8;
+   if( DBG_CIPHER )
+@@ -492,7 +480,7 @@ do_encrypt(gcry_mpi_t a, gcry_mpi_t b, gcry_mpi_t input, 
ELG_public_key *pkey )
+* error code.
+*/
+ 
+-  k = gen_k( pkey->p, 1 );
++  k = gen_k( pkey->p );
+   mpi_powm (a, pkey->g, k, pkey->p);
+ 
+   /* b = (y^k * input) mod p
+@@ -608,7 +596,7 @@ sign(gcry_mpi_t a, gcry_mpi_t b, gcry_mpi_t input, 
ELG_secret_key *skey )
+ *
+ */
+ mpi_sub_ui(p_1, p_1, 1);
+-k = gen_k( skey->p, 0 /* no small K ! */ );
++k = gen_k( skey->p );
+ mpi_powm( a, skey->g, k, skey->p );
+ mpi_mul(t, skey->x, a );
+ mpi_subm(t, input, t, p_1 );
+-- 
+2.11.0
diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
index 16a58ad9b8..174b087b24 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.5.bb
@@ -28,6 +28,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \

file://0002-AES-move-look-up-tables-to-.data-section-and-unshare.patch \

file://0003-GCM-move-look-up-table-to-.data-section-and-unshare-.patch \
file://determinism.patch \
+   file://CVE-2021-33560.patch \
 "
 SRC_URI[md5sum] = 

[OE-core] [dunfell][PATCH] iputils: Fix regression of arp table update

[Visa Hankala]

Backport a fix from iputils 20210202 to make arp table updating
work again.

Fixes: 77c5792aa5e7 ("iputils: fix various arping regressions")
Signed-off-by: Visa Hankala 
---
 ...ng-make-update-neighbours-work-again.patch | 79 +++
 .../iputils/iputils_s20190709.bb  |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 
meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch

diff --git 
a/meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
 
b/meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
new file mode 100644
index 00..bf86115843
--- /dev/null
+++ 
b/meta/recipes-extended/iputils/iputils/0001-arping-make-update-neighbours-work-again.patch
@@ -0,0 +1,79 @@
+From 86ed08936d49e2c81ef49dfbd02aca1c74d0c098 Mon Sep 17 00:00:00 2001
+From: lac-0073 <61903197+lac-0...@users.noreply.github.com>
+Date: Mon, 26 Oct 2020 09:45:42 +0800
+Subject: [PATCH] arpping: make update neighbours work again
+
+The arping is using inconsistent sender_ip_addr and target_ip_addr in
+messages.  This causes the client receiving the arp message not to update
+the arp table entries.
+
+The specific performance is as follows:
+
+There is a machine 2 with IP 10.20.30.3 configured on eth0:0 that is in the
+same IP subnet as eth0.  This IP was originally used on another machine 1,
+and th IP needs to be changed back to the machine 1.  When using the arping
+command to announce what ethernet address has IP 10.20.30.3, the arp table
+on machine 3 is not updated.
+
+Machine 3 original arp table:
+
+10.20.30.3  machine 2 eth0:000:00:00:00:00:02
+10.20.30.2  machine 2 eth0  00:00:00:00:00:02
+10.20.30.1  machine 1 eth0  00:00:00:00:00:01
+
+Create interface eth0:0 on machine 1, and use the arping command to send arp
+packets.  Expected outcome on machine 3:
+
+10.20.30.3  machine 1 eth0:000:00:00:00:00:01
+10.20.30.2  machine 2 eth0  00:00:00:00:00:02
+10.20.30.1  machine 1 eth0  00:00:00:00:00:01
+
+Actual results on machine 3:
+
+10.20.30.3  machine 2 eth0:000:00:00:00:00:02
+10.20.30.2  machine 2 eth0  00:00:00:00:00:02
+10.20.30.1  machine 1 eth0  00:00:00:00:00:01
+
+Fixes: https://github.com/iputils/iputils/issues/298
+Fixes: 68f12fc4a0dbef4ae4c404da24040d22c5a14339
+Signed-off-by: Aichun Li 
+Upstream-Status: Backport 
[https://github.com/iputils/iputils/commit/86ed08936d49e2c81ef49dfbd02aca1c74d0c098]
+Signed-off-by: Visa Hankala 
+---
+ arping.c | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/arping.c b/arping.c
+index a002786..53fdbb4 100644
+--- a/arping.c
 b/arping.c
+@@ -968,7 +968,7 @@ int main(int argc, char **argv)
+   }
+   memset(, 0, sizeof(saddr));
+   saddr.sin_family = AF_INET;
+-  if (!ctl.unsolicited && (ctl.source || ctl.gsrc.s_addr)) {
++  if (ctl.source || ctl.gsrc.s_addr) {
+   saddr.sin_addr = ctl.gsrc;
+   if (bind(probe_fd, (struct sockaddr *), 
sizeof(saddr)) == -1)
+   error(2, errno, "bind");
+@@ -979,12 +979,14 @@ int main(int argc, char **argv)
+   saddr.sin_port = htons(1025);
+   saddr.sin_addr = ctl.gdst;
+ 
+-  if (setsockopt(probe_fd, SOL_SOCKET, SO_DONTROUTE, 
(char *), sizeof(on)) == -1)
+-  error(0, errno, _("WARNING: 
setsockopt(SO_DONTROUTE)"));
+-  if (connect(probe_fd, (struct sockaddr *), 
sizeof(saddr)) == -1)
+-  error(2, errno, "connect");
+-  if (getsockname(probe_fd, (struct sockaddr *), 
) == -1)
+-  error(2, errno, "getsockname");
++  if (!ctl.unsolicited) {
++  if (setsockopt(probe_fd, SOL_SOCKET, 
SO_DONTROUTE, (char *), sizeof(on)) == -1)
++  error(0, errno, _("WARNING: 
setsockopt(SO_DONTROUTE)"));
++  if (connect(probe_fd, (struct sockaddr 
*), sizeof(saddr)) == -1)
++  error(2, errno, "connect");
++  if (getsockname(probe_fd, (struct sockaddr 
*), ) == -1)
++  error(2, errno, "getsockname");
++  }
+   ctl.gsrc = saddr.sin_addr;
+   }
+   close(probe_fd);
diff --git a/meta/recipes-extended/iputils/iputils_s20190709.bb 
b/meta/recipes-extended/iputils/iputils_s20190709.bb
index d652bfcaad..b33b913817 100644
--- a/meta/recipes-extended/iputils/iputils_s20190709.bb
+++ b/meta/recipes-extended/iputils/iputils_s20190709.bb
@@ -20,6 +20,7 @@ SRC_URI = "git://github.com/iputils/iputils \

[OE-core] [poky][dunfell][PATCH] db: Whitelist CVEs

[Saloni Jain]

From: Saloni Jain 

Below CVE affects only Oracle Berkeley DB as per upstream.
Hence, whitelisted them.

1. CVE-2015-2583
Link: https://security-tracker.debian.org/tracker/CVE-2015-2583
2. CVE-2015-2624
Link: https://security-tracker.debian.org/tracker/CVE-2015-2624
3. CVE-2015-2626
Link: https://security-tracker.debian.org/tracker/CVE-2015-2626
4. CVE-2015-2640
Link: https://security-tracker.debian.org/tracker/CVE-2015-2640
5. CVE-2015-2654
Link: https://security-tracker.debian.org/tracker/CVE-2015-2654
6. CVE-2015-2656
Link: https://security-tracker.debian.org/tracker/CVE-2015-2656
7. CVE-2015-4754
Link: https://security-tracker.debian.org/tracker/CVE-2015-4754
8. CVE-2015-4764
Link: https://security-tracker.debian.org/tracker/CVE-2015-4764
9. CVE-2015-4774
Link: https://security-tracker.debian.org/tracker/CVE-2015-4774
10. CVE-2015-4775
Link: https://security-tracker.debian.org/tracker/CVE-2015-4775
11. CVE-2015-4776
Link: https://security-tracker.debian.org/tracker/CVE-2015-4776
12. CVE-2015-4777
Link: https://security-tracker.debian.org/tracker/CVE-2015-4777
13. CVE-2015-4778
Link: https://security-tracker.debian.org/tracker/CVE-2015-4778
14. CVE-2015-4779
Link: https://security-tracker.debian.org/tracker/CVE-2015-4779
15. CVE-2015-4780
Link: https://security-tracker.debian.org/tracker/CVE-2015-4780
16. CVE-2015-4781
Link: https://security-tracker.debian.org/tracker/CVE-2015-4781
17. CVE-2015-4782
Link: https://security-tracker.debian.org/tracker/CVE-2015-4782
18. CVE-2015-4783
Link: https://security-tracker.debian.org/tracker/CVE-2015-4783
19. CVE-2015-4784
Link: https://security-tracker.debian.org/tracker/CVE-2015-4784
20. CVE-2015-4785
Link: https://security-tracker.debian.org/tracker/CVE-2015-4785
21. CVE-2015-4786
Link: https://security-tracker.debian.org/tracker/CVE-2015-4786
22. CVE-2015-4787
Link: https://security-tracker.debian.org/tracker/CVE-2015-4787
23. CVE-2015-4788
Link: https://security-tracker.debian.org/tracker/CVE-2015-4788
24. CVE-2015-4789
Link: https://security-tracker.debian.org/tracker/CVE-2015-4789
25. CVE-2015-4790
Link: https://security-tracker.debian.org/tracker/CVE-2015-4790
26. CVE-2016-0682
Link: https://security-tracker.debian.org/tracker/CVE-2016-0682
27. CVE-2016-0689
Link: https://security-tracker.debian.org/tracker/CVE-2016-0689
28. CVE-2016-0692
Link: https://security-tracker.debian.org/tracker/CVE-2016-0692
29. CVE-2016-0694
Link: https://security-tracker.debian.org/tracker/CVE-2016-0694
30. CVE-2016-3418
Link: https://security-tracker.debian.org/tracker/CVE-2016-3418
31. CVE-2017-3604
Link: https://security-tracker.debian.org/tracker/CVE-2017-3604
32. CVE-2017-3605
Link: https://security-tracker.debian.org/tracker/CVE-2017-3605
33. CVE-2017-3606
Link: https://security-tracker.debian.org/tracker/CVE-2017-3606
34. CVE-2017-3607
Link: https://security-tracker.debian.org/tracker/CVE-2017-3607
35. CVE-2017-3608
Link: https://security-tracker.debian.org/tracker/CVE-2017-3608
36. CVE-2017-3609
Link: https://security-tracker.debian.org/tracker/CVE-2017-3609
37. CVE-2017-3610
Link: https://security-tracker.debian.org/tracker/CVE-2017-3610
38. CVE-2017-3611
Link: https://security-tracker.debian.org/tracker/CVE-2017-3611
39. CVE-2017-3612
Link: https://security-tracker.debian.org/tracker/CVE-2017-3612
40. CVE-2017-3613
Link: https://security-tracker.debian.org/tracker/CVE-2017-3613
41. CVE-2017-3614
Link: https://security-tracker.debian.org/tracker/CVE-2017-3614
42. CVE-2017-3615
Link: https://security-tracker.debian.org/tracker/CVE-2017-3615
43. CVE-2017-3616
Link: https://security-tracker.debian.org/tracker/CVE-2017-3616
44. CVE-2017-3617
Link: https://security-tracker.debian.org/tracker/CVE-2017-3617
45. CVE-2020-2981
Link: https://security-tracker.debian.org/tracker/CVE-2020-2981

Signed-off-by: Saloni 
---
 meta/recipes-support/db/db_5.3.28.bb | 92 
 1 file changed, 92 insertions(+)

diff --git a/meta/recipes-support/db/db_5.3.28.bb 
b/meta/recipes-support/db/db_5.3.28.bb
index b2ae98f05c..000e9ef468 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -39,6 +39,98 @@ SRC_URI[sha256sum] = 
"e0a992d740709892e81f9d93f06daf305cf73fb81b545afe7247804317
 
 LIC_FILES_CHKSUM = "file://LICENSE;md5=ed1158e31437f4f87cdd4ab2b8613955"
 
+# Below CVEs affects only Oracle Berkeley DB as per upstream.
+# https://security-tracker.debian.org/tracker/CVE-2015-2583
+CVE_CHECK_WHITELIST += "CVE-2015-2583"
+# https://security-tracker.debian.org/tracker/CVE-2015-2624
+CVE_CHECK_WHITELIST += "CVE-2015-2624"
+# https://security-tracker.debian.org/tracker/CVE-2015-2626
+CVE_CHECK_WHITELIST += "CVE-2015-2626"
+# https://security-tracker.debian.org/tracker/CVE-2015-2640
+CVE_CHECK_WHITELIST += "CVE-2015-2640"
+# https://security-tracker.debian.org/tracker/CVE-2015-2654
+CVE_CHECK_WHITELIST += "CVE-2015-2654"
+# https://security-tracker.debian.org/tracker/CVE-2015-2656
+CVE_CHECK_WHITELIST += "CVE-2015-2656"
+# 

Re: [OE-core] [PATCH] bitbake.conf: support persistent /var/tmp

[Richard Purdie]

On Mon, 2021-09-13 at 11:42 +0800, Changqing Li wrote:
> ping
> On 8/30/21 4:11 PM, Changqing Li wrote:
>  
> > On 8/6/21 9:21 AM, Changqing Li wrote:
> >  
> > > From: Changqing Li 
> > > 
> > > Steps:
> > > 1. build out rootfs core-image-minimal-qemux86-64.tar.bz2
> > > 2. docker import core-image-minimal-qemux86-64.tar.bz2 poky:latest
> > > 3. docker run -it --rm poky:latest /bin/sh
> > > 4.
> > > /var # ls -al
> > > drwxr-xr-x8 root root  4096 Mar  9  2018 .
> > > drwxr-xr-x1 root root  4096 Aug  5 06:59 ..
> > > drwxr-xr-x2 root root  4096 Mar  9  2018 backups
> > > drwxr-xr-x2 root root  4096 Mar  9  2018 cache
> > > drwxr-xr-x5 root root  4096 Mar  9  2018 lib
> > > drwxr-xr-x2 root root  4096 Mar  9  2018 local
> > > lrwxrwxrwx1 root root11 Mar  9  2018 lock ->
> > > ../run/lock
> > > lrwxrwxrwx1 root root12 Mar  9  2018 log ->
> > > volatile/log
> > > lrwxrwxrwx1 root root 6 Mar  9  2018 run -> ../run
> > > drwxr-xr-x3 root root  4096 Mar  9  2018 spool
> > > lrwxrwxrwx1 root root12 Mar  9  2018 tmp ->
> > > volatile/tmp
> > > drwxr-xr-x2 root root  4096 Mar  9  2018 volatile
> > > /var # cd log
> > > /bin/sh: cd: can't cd to log: No such file or directory
> > > /var # cd tmp
> > > /bin/sh: cd: can't cd to tmp: No such file or directory
> > > /var # cd volatile/
> > > /var/volatile # ls -al
> > > drwxr-xr-x2 root root  4096 Mar  9  2018 .

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

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

I am unlikely to want to make changes in this area until the next release now,
sorry :/.

This is one of the problems with not having enough people with specialist
knowledge to help review, too much falls to me and I just don't have the time to
dive into each different thing and stand a chance of making the correct
decisions. This is frustrating for everyone.

Cheers,

Richard





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

Re: [OE-core][hardknott][PATCH] cpio: fix CVE-2021-38185

[Richard Purdie]

On Mon, 2021-09-13 at 16:33 +0800, Chen Qi wrote:
> Just found that Ross has sent out a patch for CVE-2021-38185 and it has 
> been merged in hardknott.
> So please ignore this patch.
> 
> I'm also curious about how you spot such issue. By double checking the 
> commit logs in cpio repo?

I had looked at this one a little as well. I'd looked at some of the discussion
from the debian community on the CVE and noticed they talked about regressions,
which prompts you to look further into the issue.

Ross' patches in master included the regressions fixes too.

Cheers,

Richard




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

Re: [OE-core][hardknott][PATCH] cpio: fix CVE-2021-38185

[Chen Qi]

Just found that Ross has sent out a patch for CVE-2021-38185 and it has 
been merged in hardknott.

So please ignore this patch.

I'm also curious about how you spot such issue. By double checking the 
commit logs in cpio repo?


Best Regards,
Chen Qi

On 09/13/2021 03:11 PM, Mittal, Anuj wrote:

It looks like this has introduced regressions and we'll need at least
these two too:

https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=dfc801c44a93bed7b3951905b188823d6a0432c8
https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=236684f6deb3178043fe72a8e2faca538fa2aae1

Thanks,

Anuj

On Mon, 2021-09-13 at 12:49 +0800, Chen Qi wrote:

Signed-off-by: Chen Qi 
---
  .../0001-Rewrite-dynamic-string-support.patch | 458 ++
  meta/recipes-extended/cpio/cpio_2.13.bb   |   1 +
  2 files changed, 459 insertions(+)
  create mode 100644 meta/recipes-extended/cpio/cpio-2.13/0001-Rewrite-
dynamic-string-support.patch

diff --git a/meta/recipes-extended/cpio/cpio-2.13/0001-Rewrite-dynamic-
string-support.patch b/meta/recipes-extended/cpio/cpio-2.13/0001-
Rewrite-dynamic-string-support.patch
new file mode 100644
index 00..93ed05184f
--- /dev/null
+++ b/meta/recipes-extended/cpio/cpio-2.13/0001-Rewrite-dynamic-string-
support.patch
@@ -0,0 +1,458 @@
+From 0cdda8baddbbc50a4212e36a470053ac624075bb Mon Sep 17 00:00:00 2001
+From: Sergey Poznyakoff 
+Date: Sat, 7 Aug 2021 12:52:21 +0300
+Subject: [PATCH] Rewrite dynamic string support.
+
+* src/dstring.c (ds_init): Take a single argument.
+(ds_free): New function.
+(ds_resize): Take a single argument.  Use x2nrealloc to expand
+the storage.
+(ds_reset,ds_append,ds_concat,ds_endswith): New function.
+(ds_fgetstr): Rewrite.  In particular, this fixes integer overflow.
+* src/dstring.h (dynamic_string): Keep both the allocated length
+(ds_size) and index of the next free byte in the string (ds_idx).
+(ds_init,ds_resize): Change signature.
+(ds_len): New macro.
+(ds_free,ds_reset,ds_append,ds_concat,ds_endswith): New protos.
+* src/copyin.c: Use new ds_ functions.
+* src/copyout.c: Likewise.
+* src/copypass.c: Likewise.
+* src/util.c: Likewise.
+
+Upstream-Status: Backport
+CVE: CVE-2021-38185
+Signed-off-by: Chen Qi 
+---
+ src/copyin.c   | 40 +++
+ src/copyout.c  | 16 -
+ src/copypass.c | 34 +--
+ src/dstring.c  | 88 -
-
+ src/dstring.h  | 31 +-
+ src/util.c |  6 ++--
+ 6 files changed, 123 insertions(+), 92 deletions(-)
+
+diff --git a/src/copyin.c b/src/copyin.c
+index b29f348..37e503a 100644
+--- a/src/copyin.c
 b/src/copyin.c
+@@ -55,11 +55,12 @@ query_rename(struct cpio_file_stat* file_hdr, FILE
*tty_in, FILE *tty_out,
+   char *str_res;  /* Result for string function.  */
+   static dynamic_string new_name; /* New file name for rename
option.  */
+   static int initialized_new_name = false;
++
+   if (!initialized_new_name)
+-  {
+-ds_init (_name, 128);
+-initialized_new_name = true;
+-  }
++{
++  ds_init (_name);
++  initialized_new_name = true;
++}
+
+   if (rename_flag)
+ {
+@@ -779,37 +780,36 @@ long_format (struct cpio_file_stat *file_hdr,
char const *link_name)
+already in `save_patterns' (from the command line) are preserved.
*/
+
+ static void
+-read_pattern_file ()
++read_pattern_file (void)
+ {
+-  int max_new_patterns;
+-  char **new_save_patterns;
+-  int new_num_patterns;
++  char **new_save_patterns = NULL;
++  size_t max_new_patterns;
++  size_t new_num_patterns;
+   int i;
+-  dynamic_string pattern_name;
++  dynamic_string pattern_name = DYNAMIC_STRING_INITIALIZER;
+   FILE *pattern_fp;
+
+   if (num_patterns < 0)
+ num_patterns = 0;
+-  max_new_patterns = 1 + num_patterns;
+-  new_save_patterns = (char **) xmalloc (max_new_patterns * sizeof
(char *));
+   new_num_patterns = num_patterns;
+-  ds_init (_name, 128);
++  max_new_patterns = num_patterns;
++  new_save_patterns = xcalloc (max_new_patterns, sizeof
(new_save_patterns[0]));
+
+   pattern_fp = fopen (pattern_file_name, "r");
+   if (pattern_fp == NULL)
+ open_fatal (pattern_file_name);
+   while (ds_fgetstr (pattern_fp, _name, '\n') != NULL)
+ {
+-  if (new_num_patterns >= max_new_patterns)
+-  {
+-max_new_patterns += 1;
+-new_save_patterns = (char **)
+-  xrealloc ((char *) new_save_patterns,
+-max_new_patterns * sizeof (char *));
+-  }
++  if (new_num_patterns == max_new_patterns)
++  new_save_patterns = x2nrealloc (new_save_patterns,
++  _new_patterns,
++  sizeof (new_save_patterns[0]));
+   new_save_patterns[new_num_patterns] = xstrdup
(pattern_name.ds_string);
+   ++new_num_patterns;
+ }
++
++  ds_free (_name);
++
+   if (ferror (pattern_fp) || fclose (pattern_fp) == EOF)
+ close_error (pattern_file_name);
+
+@@ -1196,7 +1196,7 @@ swab_array 

[OE-core] [PATCH v2] wic/bootimg-efi: Add Unified Kernel Image option

[Kristian Klausen via lists.openembedded.org]

"A unified kernel image is a single EFI PE executable combining an EFI
stub loader, a kernel image, an initramfs image, and the kernel command
line.

[...]

Images of this type have the advantage that all metadata and payload
that makes up the boot entry is monopolized in a single PE file that can
be signed cryptographically as one for the purpose of EFI
SecureBoot."[1]

This commit adds a create-unified-kernel-image=true option to the
bootimg-efi plugin for creating a Unified Kernel Image[1] and installing
it into $BOOT/EFI/Linux/ with a .efi extension per the the Boot Loader
Specification[1][2]. This is useful for implementing Secure Boot.

systemd-boot is the only mainstream bootloader implementing the
specification, but GRUB should be able to boot the EFI binary, this
commit however doesn't implement the necessary changes to the GRUB
config generation logic to boot the Unified Kernel Image.

[1] 
https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
[2] https://systemd.io/BOOT_LOADER_SPECIFICATION/

Signed-off-by: Kristian Klausen 
---
V2:
Add os-release as dependency
Pull os-release file from STAGING_DIR_HOST, so it doesn't need to be
installed into the rootfs
Add selftest

 meta-selftest/wic/test_efi_plugin.wks |  6 ++
 meta/classes/image_types_wic.bbclass  |  5 +-
 meta/lib/oeqa/selftest/cases/wic.py   | 29 
 scripts/lib/wic/plugins/source/bootimg-efi.py | 71 ---
 4 files changed, 99 insertions(+), 12 deletions(-)
 create mode 100644 meta-selftest/wic/test_efi_plugin.wks

diff --git a/meta-selftest/wic/test_efi_plugin.wks 
b/meta-selftest/wic/test_efi_plugin.wks
new file mode 100644
index 00..1603d6c4bb
--- /dev/null
+++ b/meta-selftest/wic/test_efi_plugin.wks
@@ -0,0 +1,6 @@
+# short-description: This file is used in oe-selftest wic module to test efi 
plugin
+
+part /boot --source bootimg-efi 
--sourceparams="loader=systemd-boot,create-unified-kernel-image=true,initrd=${INITRAMFS_IMAGE}-${MACHINE}.${INITRAMFS_FSTYPES}"
 --active --align 1024 --use-uuid
+part / --source rootfs --fstype=ext4 --align 1024 --use-uuid
+
+bootloader  --timeout=0 --append="console=ttyS0,115200n8"
diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index d561fb2636..e3863c88a9 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -27,6 +27,7 @@ WICVARS ?= "\
ROOTFS_SIZE \
STAGING_DATADIR \
STAGING_DIR \
+   STAGING_DIR_HOST \
STAGING_LIBDIR \
TARGET_SYS \
 "
@@ -84,8 +85,8 @@ do_image_wic[deptask] += "do_image_complete"
 WKS_FILE_DEPENDS_DEFAULT = '${@bb.utils.contains_any("BUILD_ARCH", [ 'x86_64', 
'i686' ], "syslinux-native", "",d)}'
 WKS_FILE_DEPENDS_DEFAULT += "bmap-tools-native cdrtools-native 
btrfs-tools-native squashfs-tools-native e2fsprogs-native"
 WKS_FILE_DEPENDS_BOOTLOADERS = ""
-WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot"
-WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux grub-efi systemd-boot"
+WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
+WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux grub-efi systemd-boot 
os-release"
 WKS_FILE_DEPENDS_BOOTLOADERS:x86-x32 = "syslinux grub-efi"
 
 WKS_FILE_DEPENDS ??= "${WKS_FILE_DEPENDS_DEFAULT} 
${WKS_FILE_DEPENDS_BOOTLOADERS}"
diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index dc7b9e637e..5fc8e65142 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -1158,6 +1158,35 @@ class Wic2(WicTestCase):
 out = glob(self.resultdir + "%s-*.direct" % wksname)
 self.assertEqual(1, len(out))
 
+@only_for_arch(['i586', 'i686', 'x86_64'])
+def test_efi_plugin_unified_kernel_image_qemu(self):
+"""Test efi plugin's Unified Kernel Image feature in qemu"""
+config = 'IMAGE_FSTYPES = "wic"\n'\
+ 'INITRAMFS_IMAGE = "core-image-minimal-initramfs"\n'\
+ 'WKS_FILE = "test_efi_plugin.wks"\n'\
+ 'MACHINE_FEATURES:append = " efi"\n'
+self.append_config(config)
+self.assertEqual(0, bitbake('core-image-minimal 
core-image-minimal-initramfs ovmf').status)
+self.remove_config(config)
+
+with runqemu('core-image-minimal', ssh=False,
+ runqemuparams='ovmf', image_fstype='wic') as qemu:
+# Check that /boot has EFI bootx64.efi (required for EFI)
+cmd = "ls /boot/EFI/BOOT/bootx64.efi | wc -l"
+status, output = qemu.run_serial(cmd)
+self.assertEqual(1, status, 'Failed to run command "%s": %s' % 
(cmd, output))
+self.assertEqual(output, '1')
+# Check that /boot has EFI/Linux/linux.efi (required for Unified 
Kernel Images auto detection)
+cmd = "ls /boot/EFI/Linux/linux.efi | wc -l"
+status, output = qemu.run_serial(cmd)
+   

[OE-core] [PATCH v2 1/1] oeqa/sdk: assimp.py -> cmake.py

[Robert Yang]

The downloaded non-free sources, now download expat-2.4.1.tar.bz2 to replace
it, and also rename the test case to cmake.py since it is used for testing 
cmake.

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/sdk/cases/{assimp.py => cmake.py} | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)
 rename meta/lib/oeqa/sdk/cases/{assimp.py => cmake.py} (81%)

diff --git a/meta/lib/oeqa/sdk/cases/assimp.py 
b/meta/lib/oeqa/sdk/cases/cmake.py
similarity index 81%
rename from meta/lib/oeqa/sdk/cases/assimp.py
rename to meta/lib/oeqa/sdk/cases/cmake.py
index f166758e498..24741d4c0ac 100644
--- a/meta/lib/oeqa/sdk/cases/assimp.py
+++ b/meta/lib/oeqa/sdk/cases/cmake.py
@@ -21,12 +21,12 @@ class BuildAssimp(OESDKTestCase):
 self.tc.hasHostPackage("cmake-native")):
 raise unittest.SkipTest("Needs cmake")
 
-def test_assimp(self):
-with tempfile.TemporaryDirectory(prefix="assimp", dir=self.tc.sdk_dir) 
as testdir:
-tarball = self.fetch(testdir, self.td["DL_DIR"], 
"https://github.com/assimp/assimp/archive/v4.1.0.tar.gz;)
+def test_cmake(self):
+with tempfile.TemporaryDirectory(prefix="cmake", dir=self.tc.sdk_dir) 
as testdir:
+tarball = self.fetch(testdir, self.td["DL_DIR"], 
"https://downloads.sourceforge.net/expat/expat-2.4.1.tar.bz2;)
 
 dirs = {}
-dirs["source"] = os.path.join(testdir, "assimp-4.1.0")
+dirs["source"] = os.path.join(testdir, "expat-2.4.1")
 dirs["build"] = os.path.join(testdir, "build")
 dirs["install"] = os.path.join(testdir, "install")
 
@@ -37,4 +37,4 @@ class BuildAssimp(OESDKTestCase):
 self._run("cd {build} && cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
{source}".format(**dirs))
 self._run("cmake --build {build} -- -j".format(**dirs))
 self._run("cmake --build {build} --target install -- 
DESTDIR={install}".format(**dirs))
-self.check_elf(os.path.join(dirs["install"], "usr", "local", 
"lib", "libassimp.so.4.1.0"))
+self.check_elf(os.path.join(dirs["install"], "usr", "local", 
"lib", "libexpat.so.1.8.1"))
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155967): 
https://lists.openembedded.org/g/openembedded-core/message/155967
Mute This Topic: https://lists.openembedded.org/mt/85569833/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 0/1] oeqa/sdk: assimp.py -> cmake.py

[Robert Yang]

* V2:
  - Fixed Ross' comments:
1) Keep -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
2) Avoid "/" in os.path.join()

// Robert

The following changes since commit 50154869b496cf63a4fae2c8278350fcf9a2591d:

  binutils: inherit pkgconfig to address libdebuginfod depdency (2021-09-11 
22:36:27 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/test
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/test

Robert Yang (1):
  oeqa/sdk: assimp.py -> cmake.py

 meta/lib/oeqa/sdk/cases/{assimp.py => cmake.py} | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)
 rename meta/lib/oeqa/sdk/cases/{assimp.py => cmake.py} (81%)

-- 
2.31.1


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

Re: [OE-core][hardknott][PATCH] cpio: fix CVE-2021-38185

[Anuj Mittal]

It looks like this has introduced regressions and we'll need at least
these two too:

https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=dfc801c44a93bed7b3951905b188823d6a0432c8
https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=236684f6deb3178043fe72a8e2faca538fa2aae1

Thanks,

Anuj

On Mon, 2021-09-13 at 12:49 +0800, Chen Qi wrote:
> Signed-off-by: Chen Qi 
> ---
>  .../0001-Rewrite-dynamic-string-support.patch | 458 ++
>  meta/recipes-extended/cpio/cpio_2.13.bb   |   1 +
>  2 files changed, 459 insertions(+)
>  create mode 100644 meta/recipes-extended/cpio/cpio-2.13/0001-Rewrite-
> dynamic-string-support.patch
> 
> diff --git a/meta/recipes-extended/cpio/cpio-2.13/0001-Rewrite-dynamic-
> string-support.patch b/meta/recipes-extended/cpio/cpio-2.13/0001-
> Rewrite-dynamic-string-support.patch
> new file mode 100644
> index 00..93ed05184f
> --- /dev/null
> +++ b/meta/recipes-extended/cpio/cpio-2.13/0001-Rewrite-dynamic-string-
> support.patch
> @@ -0,0 +1,458 @@
> +From 0cdda8baddbbc50a4212e36a470053ac624075bb Mon Sep 17 00:00:00 2001
> +From: Sergey Poznyakoff 
> +Date: Sat, 7 Aug 2021 12:52:21 +0300
> +Subject: [PATCH] Rewrite dynamic string support.
> +
> +* src/dstring.c (ds_init): Take a single argument.
> +(ds_free): New function.
> +(ds_resize): Take a single argument.  Use x2nrealloc to expand
> +the storage.
> +(ds_reset,ds_append,ds_concat,ds_endswith): New function.
> +(ds_fgetstr): Rewrite.  In particular, this fixes integer overflow.
> +* src/dstring.h (dynamic_string): Keep both the allocated length
> +(ds_size) and index of the next free byte in the string (ds_idx).
> +(ds_init,ds_resize): Change signature.
> +(ds_len): New macro.
> +(ds_free,ds_reset,ds_append,ds_concat,ds_endswith): New protos.
> +* src/copyin.c: Use new ds_ functions.
> +* src/copyout.c: Likewise.
> +* src/copypass.c: Likewise.
> +* src/util.c: Likewise.
> +
> +Upstream-Status: Backport
> +CVE: CVE-2021-38185
> +Signed-off-by: Chen Qi 
> +---
> + src/copyin.c   | 40 +++
> + src/copyout.c  | 16 -
> + src/copypass.c | 34 +--
> + src/dstring.c  | 88 -
> -
> + src/dstring.h  | 31 +-
> + src/util.c |  6 ++--
> + 6 files changed, 123 insertions(+), 92 deletions(-)
> +
> +diff --git a/src/copyin.c b/src/copyin.c
> +index b29f348..37e503a 100644
> +--- a/src/copyin.c
>  b/src/copyin.c
> +@@ -55,11 +55,12 @@ query_rename(struct cpio_file_stat* file_hdr, FILE
> *tty_in, FILE *tty_out,
> +   char *str_res;  /* Result for string function.  */
> +   static dynamic_string new_name; /* New file name for rename
> option.  */
> +   static int initialized_new_name = false;
> ++
> +   if (!initialized_new_name)
> +-  {
> +-    ds_init (_name, 128);
> +-    initialized_new_name = true;
> +-  }
> ++    {
> ++  ds_init (_name);
> ++  initialized_new_name = true;
> ++    }
> + 
> +   if (rename_flag)
> + {
> +@@ -779,37 +780,36 @@ long_format (struct cpio_file_stat *file_hdr,
> char const *link_name)
> +    already in `save_patterns' (from the command line) are preserved. 
> */
> + 
> + static void
> +-read_pattern_file ()
> ++read_pattern_file (void)
> + {
> +-  int max_new_patterns;
> +-  char **new_save_patterns;
> +-  int new_num_patterns;
> ++  char **new_save_patterns = NULL;
> ++  size_t max_new_patterns;
> ++  size_t new_num_patterns;
> +   int i;
> +-  dynamic_string pattern_name;
> ++  dynamic_string pattern_name = DYNAMIC_STRING_INITIALIZER;
> +   FILE *pattern_fp;
> + 
> +   if (num_patterns < 0)
> + num_patterns = 0;
> +-  max_new_patterns = 1 + num_patterns;
> +-  new_save_patterns = (char **) xmalloc (max_new_patterns * sizeof
> (char *));
> +   new_num_patterns = num_patterns;
> +-  ds_init (_name, 128);
> ++  max_new_patterns = num_patterns;
> ++  new_save_patterns = xcalloc (max_new_patterns, sizeof
> (new_save_patterns[0]));
> + 
> +   pattern_fp = fopen (pattern_file_name, "r");
> +   if (pattern_fp == NULL)
> + open_fatal (pattern_file_name);
> +   while (ds_fgetstr (pattern_fp, _name, '\n') != NULL)
> + {
> +-  if (new_num_patterns >= max_new_patterns)
> +-  {
> +-    max_new_patterns += 1;
> +-    new_save_patterns = (char **)
> +-  xrealloc ((char *) new_save_patterns,
> +-    max_new_patterns * sizeof (char *));
> +-  }
> ++  if (new_num_patterns == max_new_patterns)
> ++  new_save_patterns = x2nrealloc (new_save_patterns,
> ++  _new_patterns,
> ++  sizeof (new_save_patterns[0]));
> +   new_save_patterns[new_num_patterns] = xstrdup
> (pattern_name.ds_string);
> +   ++new_num_patterns;
> + }
> ++
> ++  ds_free (_name);
> ++  
> +   if (ferror (pattern_fp) || fclose (pattern_fp) == EOF)
> + close_error (pattern_file_name);
> + 
> +@@ -1196,7 +1196,7 @@ swab_array (char *ptr, int count)
> +    in