[OE-core][PATCH v3] gcc: depend on zstd

2023-09-27 Thread Sean Nyekjaer
Add zstd LTO support for target and nativesdk compiler.
This also brings gcc into sync with gcc-cross.

% x86_64-oe-linux-gcc -v
[...]
 Supported LTO compression algorithms: zlib zstd
 gcc version 12.2.0 (GCC)
% x86_64-oesdk-linux-gcc -v
[...]
 Supported LTO compression algorithms: zlib
 gcc version 12.2.0 (GCC)

Signed-off-by: Sean Nyekjaer 
---
Changes since v2:
 - removed git syntax from commit msg

 meta/recipes-devtools/gcc/gcc-13.2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-13.2.inc 
b/meta/recipes-devtools/gcc/gcc-13.2.inc
index d96f3171e4..359db1e278 100644
--- a/meta/recipes-devtools/gcc/gcc-13.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-13.2.inc
@@ -10,7 +10,7 @@ BINV = "13.2.0"
 
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
 
-DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
+DEPENDS =+ "mpfr gmp libmpc zlib zstd flex-native"
 NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native 
zstd-native"
 
 LICENSE = "GPL-3.0-with-GCC-exception & GPL-3.0-only"
-- 
2.42.0


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



[OE-core][kirkstone 17/17] kernel.bbclass: Add force flag to rm calls

2023-09-27 Thread Steve Sakoman
From: Ryan Eatmon 

The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it.  Simple fix is to add the
-f (force) flag to the call.

(From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc)

Signed-off-by: Ryan Eatmon 
Signed-off-by: Richard Purdie 
Signed-off-by: Alexander Sverdlin 
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f7d199e917..5951347361 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -442,8 +442,8 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo 
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} 
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+   rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+   rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
# Remove empty module directories to prevent QA issues
find 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty 
-delete
else
-- 
2.34.1


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



[OE-core][kirkstone 16/17] cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfig

2023-09-27 Thread Steve Sakoman
From: Jaeyoon Jung 

Variable overrides in KCONFIG_CONFIG_COMMAND do not work as expected due
to double quote mismatches. The issue is reproducible in an environment
where gold is the default linker. Below is an example snippet of
run.do_terminal generated by do_menuconfig.

do_terminal() {
exec sh -c "make menuconfig   CC="aarch64-webos-linux-gcc ..."
LD="aarch64-webos-linux-ld.bfd ..."
...
}

Although LD override is set to bfd correctly, it is not passed to make
and make menuconfig ends up with messages like:
| gold linker is not supported as it is not capable of linking the kernel 
proper.
| scripts/Kconfig.include:56: Sorry, this linker is not supported.

(From OE-Core rev: 9c483765db762dbe8020423c8778518612b7e5f7)

Signed-off-by: Jaeyoon Jung 
Signed-off-by: Richard Purdie 
(cherry picked from commit d4664d2b7974354e73d891762ebb2c8a12d62438)
Backported: File was renamed between kirkstone and master.
Signed-off-by: Yoann Congal 
Signed-off-by: Steve Sakoman 
---
 meta/classes/cml1.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index d319d66ab2..fd087c2a14 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -48,7 +48,7 @@ python do_menuconfig() {
 # ensure that environment variables are overwritten with this tasks 'd' 
values
 d.appendVar("OE_TERMINAL_EXPORTS", " PKG_CONFIG_DIR PKG_CONFIG_PATH 
PKG_CONFIG_LIBDIR PKG_CONFIG_SYSROOT_DIR")
 
-oe_terminal("sh -c \"make %s; if [ \\$? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"" % 
d.getVar('KCONFIG_CONFIG_COMMAND'),
+oe_terminal("sh -c 'make %s; if [ \\$? -ne 0 ]; then echo \"Command 
failed.\"; printf \"Press any key to continue... \"; read r; fi'" % 
d.getVar('KCONFIG_CONFIG_COMMAND'),
 d.getVar('PN') + ' Configuration', d)
 
 # FIXME this check can be removed when the minimum bitbake version has 
been bumped
-- 
2.34.1


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



[OE-core][kirkstone 15/17] bind: update to 9.18.19

2023-09-27 Thread Steve Sakoman
From: Lee Chee Yang 

Notes for BIND 9.18.19
Security Fixes
Previously, sending a specially crafted message over the control channel
could cause the packet-parsing code to run out of available stack
memory, causing named to terminate unexpectedly. This has been fixed.
(CVE-2023-3341)

ISC would like to thank Eric Sesterhenn from X41 D-Sec GmbH for bringing
this vulnerability to our attention. [GL #4152]

A flaw in the networking code handling DNS-over-TLS queries could cause
named to terminate unexpectedly due to an assertion failure under
significant DNS-over-TLS query load. This has been fixed.
(CVE-2023-4236)

ISC would like to thank Robert Story from USC/ISI Root Server Operations
for bringing this vulnerability to our attention. [GL #4242]

Removed Features
The dnssec-must-be-secure option has been deprecated and will be removed
in a future release. [GL #4263]

Feature Changes
If the server command is specified, nsupdate now honors the nsupdate -v
option for SOA queries by sending both the UPDATE request and the
initial query over TCP. [GL #1181]

Bug Fixes
The value of the If-Modified-Since header in the statistics channel was
not being correctly validated for its length, potentially allowing an
authorized user to trigger a buffer overflow. Ensuring the statistics
channel is configured correctly to grant access exclusively to
authorized users is essential (see the statistics-channels block
definition and usage section). [GL #4124]

This issue was reported independently by Eric Sesterhenn of X41 D-Sec
GmbH and Cameron Whitehead.

The Content-Length header in the statistics channel was lacking proper
bounds checking. A negative or excessively large value could potentially
trigger an integer overflow and result in an assertion failure. [GL

This issue was reported by Eric Sesterhenn of X41 D-Sec GmbH.

Several memory leaks caused by not clearing the OpenSSL error stack were
fixed. [GL #4159]

This issue was reported by Eric Sesterhenn of X41 D-Sec GmbH.

The introduction of krb5-subdomain-self-rhs and ms-subdomain-self-rhs
UPDATE policies accidentally caused named to return SERVFAIL responses
to deletion requests for non-existent PTR and SRV records. This has been
fixed. [GL #4280]

The stale-refresh-time feature was mistakenly disabled when the server
cache was flushed by rndc flush. This has been fixed. [GL #4278]

BIND’s memory consumption has been improved by implementing dedicated
jemalloc memory arenas for sending buffers. This optimization ensures
that memory usage is more efficient and better manages the return of
memory pages to the operating system. [GL #4038]

Previously, partial writes in the TLS DNS code were not accounted for
correctly, which could have led to DNS message corruption. This has been
fixed. [GL #4255]

Known Issues
There are no new known issues with this release. See above for a list of
all known issues affecting this BIND 9 branch.

Notes for BIND 9.18.18
Feature Changes
When a primary server for a zone responds to an SOA query, but the
subsequent TCP connection required to transfer the zone is refused, that
server is marked as temporarily unreachable. This now also happens if
the TCP connection attempt times out, preventing too many zones from
queuing up on an unreachable server and allowing the refresh process to
move on to the next configured primary more quickly. [GL #4215]

The dialup and heartbeat-interval options have been deprecated and will
be removed in a future BIND 9 release. [GL #3700]

Bug Fixes
Processing already-queued queries received over TCP could cause an
assertion failure, when the server was reconfigured at the same time or
the cache was being flushed. This has been fixed. [GL #4200]

Setting dnssec-policy to insecure prevented zones containing resource
records with a TTL value larger than 86400 seconds (1 day) from being
loaded. This has been fixed by ignoring the TTL values in the zone and
using a value of 604800 seconds (1 week) as the maximum zone TTL in key
rollover timing calculations. [GL #4032]

Known Issues
There are no new known issues with this release. See above for a list of
all known issues affecting this BIND 9 branch.

Link to release notes:
https://bind9.readthedocs.io/en/v9.18.19/notes.html#notes-for-bind-9-18-19

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 .../0001-avoid-start-failure-with-bind-user.patch   | 0
 .../0001-named-lwresd-V-and-start-log-hide-build-options.patch  | 0
 .../bind-ensure-searching-for-json-headers-searches-sysr.patch  | 0
 meta/recipes-connectivity/bind/{bind-9.18.17 => bind}/bind9 | 0
 .../recipes-connectivity/bind/{bind-9.18.17 => bind}/conf.patch | 0
 .../bind/{bind-9.18.17 => bind}/generate-rndc-key.sh| 0
 .../init.d-add-support-for-read-only-rootfs.patch   | 0
 .../{bind-9.18.17 => bind}/make-etc-initd-bind-stop-work.patch  | 0
 .../bind/{bind-9.18.17 => bind}/named.service   | 0
 .../bind/{bind_9.18.17.bb => bind_9.18.19.bb}

[OE-core][kirkstone 14/17] python3-git: upgrade 3.1.32 -> 3.1.37

2023-09-27 Thread Steve Sakoman
From: Narpat Mali 

The delta between 3.1.32 & 3.1.37 contains the CVE-2023-40590 and
CVE-2023-41040 fixes and other bugfixes.

Changelog:
==
- WIP Quick doc by @LeoDaCoda in #1608
- Partial clean up wrt mypy and black by @bodograumann in #1617
- Disable merge_includes in config writers by @bodograumann in #1618
- feat: full typing for "progress" parameter in Repo class by @madebylydia in 
#1634
- Fix CVE-2023-40590 by @EliahKagan in #1636
- #1566 Creating a lock now uses python built-in "open()" method to work arou… 
by @HageMaster3108 in #1619
- util: close lockfile after opening successfully by @skshetry in #1639
- Bump actions/checkout from 3 to 4 by @dependabot in #1643
- Fix 'Tree' object has no attribute '_name' when submodule path is normal path 
by @CosmosAtlas in #1645
- Fix CVE-2023-41040 by @facutuesca in #1644
- Only make config more permissive in tests that need it by @EliahKagan in #1648
- Added test for PR #1645 submodule path by @CosmosAtlas in #1647
- Fix Windows environment variable upcasing bug by @EliahKagan in #1650
- Improve Python version and OS compatibility, fixing deprecations by 
@EliahKagan in #1654
- Better document env_case test/fixture and cwd by @EliahKagan in #1657
- Remove spurious executable permissions by @EliahKagan in #1658
- Fix up checks in Makefile and make them portable by @EliahKagan in #1661
- Fix URLs that were redirecting to another license by @EliahKagan in #1662
- Assorted small fixes/improvements to root dir docs by @EliahKagan in #1663
- Use venv instead of virtualenv in test_installation by @EliahKagan in #1664
- Omit py_modules in setup by @EliahKagan in #1665
- Don't track code coverage temporary files by @EliahKagan in #1666
- Configure tox by @EliahKagan in #1667
- Format tests with black and auto-exclude untracked paths by @EliahKagan in 
#1668
- Upgrade and broaden flake8, fixing style problems and bugs by @EliahKagan in 
#1673
- Fix rollback bug in SymbolicReference.set_reference by @EliahKagan in #1675
- Remove @NoEffect annotations by @EliahKagan in #1677
- Add more checks for the validity of refnames by @facutuesca in #1672

Note that the changes to the license file are just removal of excess whitespace
(the extra blank line at the end, and spaces appearing at the end of lines).

References:
https://github.com/gitpython-developers/GitPython/releases
https://github.com/gitpython-developers/GitPython/blob/main/doc/source/changes.rst
https://github.com/gitpython-developers/GitPython/commit/e1af18377fd69f9c1007f8abf6ccb95b3c5a6558

Signed-off-by: Narpat Mali 
Signed-off-by: Steve Sakoman 
---
 .../python/{python3-git_3.1.32.bb => python3-git_3.1.37.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-git_3.1.32.bb => 
python3-git_3.1.37.bb} (86%)

diff --git a/meta/recipes-devtools/python/python3-git_3.1.32.bb 
b/meta/recipes-devtools/python/python3-git_3.1.37.bb
similarity index 86%
rename from meta/recipes-devtools/python/python3-git_3.1.32.bb
rename to meta/recipes-devtools/python/python3-git_3.1.37.bb
index f217577eb8..56a335a79e 100644
--- a/meta/recipes-devtools/python/python3-git_3.1.32.bb
+++ b/meta/recipes-devtools/python/python3-git_3.1.37.bb
@@ -6,13 +6,13 @@ access with big-files support."
 HOMEPAGE = "http://github.com/gitpython-developers/GitPython;
 SECTION = "devel/python"
 LICENSE = "BSD-3-Clause"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=8b8d26c37c1d5a04f9b0186edbebc183"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=5279a7ab369ba336989dcf2a107e5c8e"
 
 PYPI_PACKAGE = "GitPython"
 
 inherit pypi python_setuptools_build_meta
 
-SRC_URI[sha256sum] = 
"8d9b8cb1e80b9735e8717c9362079d3ce4c6e5ddeebedd0361b228c3a67a62f6"
+SRC_URI[sha256sum] = 
"f9b9ddc0761c125d5780eab2d64be4873fc6817c2899cbcb34b02344bdc7bc54"
 
 DEPENDS += " ${PYTHON_PN}-gitdb"
 
-- 
2.34.1


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



[OE-core][kirkstone 12/17] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Steve Sakoman
From: Colin McAllister 

Add patch from libwebp 1.2.4 to fix CVE-2023-5129

Signed-off-by: Colin McAllister 
Signed-off-by: Steve Sakoman 
---
 .../webp/files/CVE-2023-5129.patch| 364 ++
 meta/recipes-multimedia/webp/libwebp_1.2.4.bb |   1 +
 2 files changed, 365 insertions(+)
 create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch

diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
new file mode 100644
index 00..356806ad87
--- /dev/null
+++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
@@ -0,0 +1,364 @@
+From 383b8b4eb6780d855e8a8177fbce96ab39dba6a5 Mon Sep 17 00:00:00 2001
+From: Vincent Rabaud 
+Date: Thu, 7 Sep 2023 21:16:03 +0200
+Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
+
+First, BuildHuffmanTable is called to check if the data is valid.
+If it is and the table is not big enough, more memory is allocated.
+
+This will make sure that valid (but unoptimized because of unbalanced
+codes) streams are still decodable.
+
+Bug: chromium:1479274
+Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
+
+CVE: CVE-2023-5129
+Upstream-Status: Backport 
[https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a]
+Signed-off-by: Colin McAllister 
+---
+ src/dec/vp8l_dec.c| 46 ++-
+ src/dec/vp8li_dec.h   |  2 +-
+ src/utils/huffman_utils.c | 97 +++
+ src/utils/huffman_utils.h | 27 +--
+ 4 files changed, 129 insertions(+), 43 deletions(-)
+
+diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
+index 13480551..186b0b2f 100644
+--- a/src/dec/vp8l_dec.c
 b/src/dec/vp8l_dec.c
+@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
+   int symbol;
+   int max_symbol;
+   int prev_code_len = DEFAULT_CODE_LENGTH;
+-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
++  HuffmanTables tables;
+ 
+-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
+- code_length_code_lengths,
+- NUM_CODE_LENGTH_CODES)) {
++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
++ code_length_code_lengths, 
NUM_CODE_LENGTH_CODES)) {
+ goto End;
+   }
+ 
+@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
+ int code_len;
+ if (max_symbol-- == 0) break;
+ VP8LFillBitWindow(br);
+-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
++p = _segment->start[VP8LPrefetchBits(br) & 
LENGTHS_TABLE_MASK];
+ VP8LSetBitPos(br, br->bit_pos_ + p->bits);
+ code_len = p->value;
+ if (code_len < kCodeLengthLiterals) {
+@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
+   ok = 1;
+ 
+  End:
++  VP8LHuffmanTablesDeallocate();
+   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
+   return ok;
+ }
+@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
+ // 'code_lengths' is pre-allocated temporary buffer, used for creating Huffman
+ // tree.
+ static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
+-   int* const code_lengths, HuffmanCode* const table) 
{
++   int* const code_lengths,
++   HuffmanTables* const table) {
+   int ok = 0;
+   int size = 0;
+   VP8LBitReader* const br = >br_;
+@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   VP8LMetadata* const hdr = >hdr_;
+   uint32_t* huffman_image = NULL;
+   HTreeGroup* htree_groups = NULL;
+-  HuffmanCode* huffman_tables = NULL;
+-  HuffmanCode* huffman_table = NULL;
++  HuffmanTables* huffman_tables = >huffman_tables_;
+   int num_htree_groups = 1;
+   int num_htree_groups_max = 1;
+   int max_alphabet_size = 0;
+@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   int* mapping = NULL;
+   int ok = 0;
+ 
++  // Check the table has been 0 initialized (through InitMetadata).
++  assert(huffman_tables->root.start == NULL);
++  assert(huffman_tables->curr_segment == NULL);
++
+   if (allow_recursion && VP8LReadBits(br, 1)) {
+ // use meta Huffman codes.
+ const int huffman_precision = VP8LReadBits(br, 3) + 2;
+@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+ 
+   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
+   sizeof(*code_lengths));
+-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * table_size,
+-sizeof(*huffman_tables));
+   htree_groups = VP8LHtreeGroupsNew(num_htree_groups);
+ 
+-  if (htree_groups == NULL || code_lengths == NULL || huffman_tables == NULL) 
{
++  if (htree_groups == NULL || code_lengths == NULL ||
++  !VP8LHuffmanTablesAllocate(num_htree_groups * table_size,
++ 

[OE-core][kirkstone 13/17] openssl: Upgrade 3.0.10 -> 3.0.11

2023-09-27 Thread Steve Sakoman
From: Peter Marko 

https://github.com/openssl/openssl/blob/openssl-3.0/NEWS.md#major-changes-between-openssl-3010-and-openssl-3011-19-sep-2023
Major changes between OpenSSL 3.0.10 and OpenSSL 3.0.11 [19 Sep 2023]
* Fix POLY1305 MAC implementation corrupting XMM registers on Windows 
(CVE-2023-4807)

Signed-off-by: Peter Marko 
Signed-off-by: Steve Sakoman 
---
 .../openssl/{openssl_3.0.10.bb => openssl_3.0.11.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-connectivity/openssl/{openssl_3.0.10.bb => 
openssl_3.0.11.bb} (99%)

diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.10.bb 
b/meta/recipes-connectivity/openssl/openssl_3.0.11.bb
similarity index 99%
rename from meta/recipes-connectivity/openssl/openssl_3.0.10.bb
rename to meta/recipes-connectivity/openssl/openssl_3.0.11.bb
index c770f1c712..22eaa3af33 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.10.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.11.bb
@@ -18,7 +18,7 @@ SRC_URI:append:class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[sha256sum] = 
"1761d4f5b13a1028b9b6f3d4b8e17feb0cedc9370f6afe61d7193d2cdce83323"
+SRC_URI[sha256sum] = 
"b3425d3bb4a2218d0697eb41f7fc0cdede016ed19ca49d168b78e8d947887f55"
 
 inherit lib_package multilib_header multilib_script ptest perlnative
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
-- 
2.34.1


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



[OE-core][kirkstone 09/17] webkitgtk: fix CVE-2023-32439

2023-09-27 Thread Steve Sakoman
From: Yogita Urade 

A type confusion issue was addressed with improved checks.
This issue is fixed in iOS 16.5.1 and iPadOS 16.5.1, Safari
16.5.1, macOS Ventura 13.4.1, iOS 15.7.7 and iPadOS 15.7.7.
Processing maliciously crafted web content may lead to
arbitrary code execution. Apple is aware of a report that
this issue may have been actively exploited.

Signed-off-by: Yogita Urade 
Signed-off-by: Steve Sakoman 
---
 .../webkit/webkitgtk/CVE-2023-32439.patch | 127 ++
 meta/recipes-sato/webkit/webkitgtk_2.36.8.bb  |   1 +
 2 files changed, 128 insertions(+)
 create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2023-32439.patch

diff --git a/meta/recipes-sato/webkit/webkitgtk/CVE-2023-32439.patch 
b/meta/recipes-sato/webkit/webkitgtk/CVE-2023-32439.patch
new file mode 100644
index 00..f8d7b613fa
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk/CVE-2023-32439.patch
@@ -0,0 +1,127 @@
+From ebefb9e6b7e7440ab6bb29452f4ac6350bd8b975 Mon Sep 17 00:00:00 2001
+From: Yijia Huang 
+Date: Tue, 26 Sep 2023 09:23:31 +
+Subject: [PATCH] Cherry-pick 263909@main (52fe95e5805c).
+ https://bugs.webkit.org/show_bug.cgi?id=256567
+
+EnumeratorNextUpdateIndexAndMode and HasIndexedProperty should have 
different heap location kinds
+https://bugs.webkit.org/show_bug.cgi?id=256567
+rdar://109089013
+
+Reviewed by Yusuke Suzuki.
+
+EnumeratorNextUpdateIndexAndMode and HasIndexedProperty are different DFG 
nodes. However,
+they might introduce the same heap location kind in DFGClobberize.h which 
might lead to
+hash collision. We should introduce a new locationn kind for 
EnumeratorNextUpdateIndexAndMode.
+
+* JSTests/stress/heap-location-collision-dfg-clobberize.js: Added.
+(foo):
+* Source/JavaScriptCore/dfg/DFGClobberize.h:
+(JSC::DFG::clobberize):
+* Source/JavaScriptCore/dfg/DFGHeapLocation.cpp:
+(WTF::printInternal):
+* Source/JavaScriptCore/dfg/DFGHeapLocation.h:
+
+Canonical link: https://commits.webkit.org/263909@main
+
+Canonical link: https://commits.webkit.org/260527.376@webkitglib/2.40
+
+CVE: CVE-2023-32439
+
+Upstream-Status: Backport [https://github.com/WebKit/WebKit/commit/ebefb9e]
+
+Signed-off-by: Yogita Urade 
+---
+ .../stress/heap-location-collision-dfg-clobberize.js | 12 
+ Source/JavaScriptCore/dfg/DFGClobberize.h|  7 ---
+ Source/JavaScriptCore/dfg/DFGHeapLocation.cpp|  4 
+ Source/JavaScriptCore/dfg/DFGHeapLocation.h  |  1 +
+ 4 files changed, 21 insertions(+), 3 deletions(-)
+ create mode 100644 JSTests/stress/heap-location-collision-dfg-clobberize.js
+
+diff --git a/JSTests/stress/heap-location-collision-dfg-clobberize.js 
b/JSTests/stress/heap-location-collision-dfg-clobberize.js
+new file mode 100644
+index ..ed40601e
+--- /dev/null
 b/JSTests/stress/heap-location-collision-dfg-clobberize.js
+@@ -0,0 +1,12 @@
++//@ runDefault("--watchdog=300", "--watchdog-exception-ok")
++const arr = [0];
++
++function foo() {
++for (let _ in arr) {
++0 in arr;
++while(1);
++}
++}
++
++
++foo();
+diff --git a/Source/JavaScriptCore/dfg/DFGClobberize.h 
b/Source/JavaScriptCore/dfg/DFGClobberize.h
+index f96e21d2..af3e864b 100644
+--- a/Source/JavaScriptCore/dfg/DFGClobberize.h
 b/Source/JavaScriptCore/dfg/DFGClobberize.h
+@@ -371,6 +371,7 @@ void clobberize(Graph& graph, Node* node, const 
ReadFunctor& read, const WriteFu
+
+ read(JSObject_butterfly);
+ ArrayMode mode = node->arrayMode();
++LocationKind locationKind = node->op() == 
EnumeratorNextUpdateIndexAndMode ? EnumeratorNextUpdateIndexAndModeLoc : 
HasIndexedPropertyLoc;
+ switch (mode.type()) {
+ case Array::ForceExit: {
+ write(SideState);
+@@ -380,7 +381,7 @@ void clobberize(Graph& graph, Node* node, const 
ReadFunctor& read, const WriteFu
+ if (mode.isInBounds()) {
+ read(Butterfly_publicLength);
+ read(IndexedInt32Properties);
+-def(HeapLocation(HasIndexedPropertyLoc, 
IndexedInt32Properties, graph.varArgChild(node, 0), graph.varArgChild(node, 
1)), LazyNode(node));
++def(HeapLocation(locationKind, IndexedInt32Properties, 
graph.varArgChild(node, 0), graph.varArgChild(node, 1)), LazyNode(node));
+ return;
+ }
+ break;
+@@ -390,7 +391,7 @@ void clobberize(Graph& graph, Node* node, const 
ReadFunctor& read, const WriteFu
+ if (mode.isInBounds()) {
+ read(Butterfly_publicLength);
+ read(IndexedDoubleProperties);
+-def(HeapLocation(HasIndexedPropertyLoc, 
IndexedDoubleProperties, graph.varArgChild(node, 0), graph.varArgChild(node, 
1)), LazyNode(node));
++def(HeapLocation(locationKind, IndexedDoubleProperties, 
graph.varArgChild(node, 0), graph.varArgChild(node, 1)), LazyNode(node));
+ return;
+ }
+ 

[OE-core][kirkstone 11/17] cups: Fix CVE-2023-4504

2023-09-27 Thread Steve Sakoman
From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-extended/cups/cups.inc   |  1 +
 .../cups/cups/CVE-2023-4504.patch | 42 +++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-4504.patch

diff --git a/meta/recipes-extended/cups/cups.inc 
b/meta/recipes-extended/cups/cups.inc
index 4d0c52eab8..047ab33898 100644
--- a/meta/recipes-extended/cups/cups.inc
+++ b/meta/recipes-extended/cups/cups.inc
@@ -18,6 +18,7 @@ SRC_URI = 
"https://github.com/OpenPrinting/cups/releases/download/v${PV}/cups-${
file://CVE-2023-32324.patch \
file://CVE-2023-34241.patch \
   file://CVE-2023-32360.patch \
+  file://CVE-2023-4504.patch \
"
 
 UPSTREAM_CHECK_URI = "https://github.com/OpenPrinting/cups/releases;
diff --git a/meta/recipes-extended/cups/cups/CVE-2023-4504.patch 
b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
new file mode 100644
index 00..e52e43a209
--- /dev/null
+++ b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
@@ -0,0 +1,42 @@
+CVE: CVE-2023-4504
+Upstream-Status: Backport 
[https://github.com/OpenPrinting/cups/commit/2431caddb7e6a87f04ac90b5c6366ad268b6ff31
 ]
+Signed-off-by: Lee Chee Yang 
+
+From 2431caddb7e6a87f04ac90b5c6366ad268b6ff31 Mon Sep 17 00:00:00 2001
+From: Zdenek Dohnal 
+Date: Wed, 20 Sep 2023 14:45:17 +0200
+Subject: [PATCH] raster-interpret.c: Fix CVE-2023-4504
+
+We didn't check for end of buffer if it looks there is an escaped
+character - check for NULL terminator there and if found, return NULL
+as return value and in `ptr`, because a lone backslash is not
+a valid PostScript character.
+---
+ cups/raster-interpret.c | 14 +-
+ 1 files changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/cups/raster-interpret.c b/cups/raster-interpret.c
+index 6fcf731b5..b8655c8c6 100644
+--- a/cups/raster-interpret.c
 b/cups/raster-interpret.c
+@@ -1116,7 +1116,19 @@ scan_ps(_cups_ps_stack_t *st,   /* I  - Stack */
+ 
+   cur ++;
+ 
+-if (*cur == 'b')
++ /*
++  * Return NULL if we reached NULL terminator, a lone backslash
++  * is not a valid character in PostScript.
++  */
++
++  if (!*cur)
++  {
++*ptr = NULL;
++
++return (NULL);
++  }
++
++  if (*cur == 'b')
+ *valptr++ = '\b';
+   else if (*cur == 'f')
+ *valptr++ = '\f';
-- 
2.34.1


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



[OE-core][kirkstone 10/17] xserver-xorg: ignore CVE-2022-3553 as it is XQuartz-specific

2023-09-27 Thread Steve Sakoman
From: Ross Burton 

(cherry-pick from commit 769576f36aac9652525beec5c7e8a4d26632b844 )

Signed-off-by: Ross Burton 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Lee Chee Yang 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 6b11c79be6..ecb164ddf7 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -28,6 +28,8 @@ CVE_CHECK_IGNORE += "CVE-2011-4613"
 # impossible or difficult to exploit. There is currently no upstream patch
 # available for this flaw.
 CVE_CHECK_IGNORE += "CVE-2020-25697"
+# This is specific to XQuartz, which is the macOS X server port
+CVE_CHECK_IGNORE += "CVE-2022-3553"
 
 S = "${WORKDIR}/${XORG_PN}-${PV}"
 
-- 
2.34.1


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



[OE-core][kirkstone 08/17] ruby: fix CVE-2023-36617

2023-09-27 Thread Steve Sakoman
From: Meenali Gupta 

Backport two patches [1] [2] to fix CVE-2023-36617

Signed-off-by: Meenali Gupta 
Signed-off-by: Steve Sakoman 
---
 .../ruby/ruby/CVE-2023-36617_1.patch  | 52 +++
 .../ruby/ruby/CVE-2023-36617_2.patch  | 47 +
 meta/recipes-devtools/ruby/ruby_3.1.3.bb  |  2 +
 3 files changed, 101 insertions(+)
 create mode 100644 meta/recipes-devtools/ruby/ruby/CVE-2023-36617_1.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/CVE-2023-36617_2.patch

diff --git a/meta/recipes-devtools/ruby/ruby/CVE-2023-36617_1.patch 
b/meta/recipes-devtools/ruby/ruby/CVE-2023-36617_1.patch
new file mode 100644
index 00..57a15d302e
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/CVE-2023-36617_1.patch
@@ -0,0 +1,52 @@
+From 9c2eb12776c1b5df2517a7e618e5fe818cc3395e Mon Sep 17 00:00:00 2001
+From: Nobuyoshi Nakada 
+Date: Thu, 27 Jul 2023 15:53:01 +0800
+Subject: [PATCH] ruby: Fix quadratic backtracking on invalid relative URI
+
+Upstream-Status: Backport 
[https://github.com/ruby/uri/commit/9010ee2536adda10a0555ae1ed6fe2f5808e6bf1]
+CVE: CVE-2023-36617
+
+Signed-off-by: Meenali Gupta 
+---
+ lib/uri/rfc2396_parser.rb |  4 ++--
+ test/uri/test_parser.rb   | 12 
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/lib/uri/rfc2396_parser.rb b/lib/uri/rfc2396_parser.rb
+index 76a8f99..00c66cf 100644
+--- a/lib/uri/rfc2396_parser.rb
 b/lib/uri/rfc2396_parser.rb
+@@ -497,8 +497,8 @@ module URI
+   ret = {}
+
+   # for URI::split
+-  ret[:ABS_URI] = Regexp.new('\A\s*' + pattern[:X_ABS_URI] + '\s*\z', 
Regexp::EXTENDED)
+-  ret[:REL_URI] = Regexp.new('\A\s*' + pattern[:X_REL_URI] + '\s*\z', 
Regexp::EXTENDED)
++  ret[:ABS_URI] = Regexp.new('\A\s*+' + pattern[:X_ABS_URI] + '\s*\z', 
Regexp::EXTENDED)
++  ret[:REL_URI] = Regexp.new('\A\s*+' + pattern[:X_REL_URI] + '\s*\z', 
Regexp::EXTENDED)
+
+   # for URI::extract
+   ret[:URI_REF] = Regexp.new(pattern[:URI_REF])
+diff --git a/test/uri/test_parser.rb b/test/uri/test_parser.rb
+index 03de137..01ed32a 100644
+--- a/test/uri/test_parser.rb
 b/test/uri/test_parser.rb
+@@ -63,4 +63,16 @@ class URI::TestParser < Test::Unit::TestCase
+ assert_equal("\u3042", 
p1.unescape('%e3%81%82'.force_encoding(Encoding::US_ASCII)))
+ assert_equal("\xe3\x83\x90\xe3\x83\x90", 
p1.unescape("\xe3\x83\x90%e3%83%90"))
+   end
++
++  def test_rfc2822_parse_relative_uri
++pre = ->(length) {
++  " " * length + "\0"
++}
++parser = URI::RFC2396_Parser.new
++assert_linear_performance((1..5).map {|i| 10**i}, pre: pre) do |uri|
++  assert_raise(URI::InvalidURIError) do
++parser.split(uri)
++  end
++end
++  end
+ end
+--
+2.40.0
diff --git a/meta/recipes-devtools/ruby/ruby/CVE-2023-36617_2.patch 
b/meta/recipes-devtools/ruby/ruby/CVE-2023-36617_2.patch
new file mode 100644
index 00..ff558183b6
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/CVE-2023-36617_2.patch
@@ -0,0 +1,47 @@
+From eea5868120509c245216c4b5c2d4b5db1c593d0e Mon Sep 17 00:00:00 2001
+From: Nobuyoshi Nakada 
+Date: Thu, 27 Jul 2023 16:16:30 +0800
+Subject: [PATCH] ruby: Fix quadratic backtracking on invalid port number
+
+Upstream-Status: Backport 
[https://github.com/ruby/uri/commit/9d7bcef1e6ad23c9c6e4932f297fb737888144c8]
+CVE: CVE-2023-36617
+Signed-off-by: Meenali Gupta 
+---
+ lib/uri/rfc3986_parser.rb |  2 +-
+ test/uri/test_parser.rb   | 10 ++
+ 2 files changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/lib/uri/rfc3986_parser.rb b/lib/uri/rfc3986_parser.rb
+index 3c89311..cde3ea7 100644
+--- a/lib/uri/rfc3986_parser.rb
 b/lib/uri/rfc3986_parser.rb
+@@ -101,7 +101,7 @@ module URI
+ QUERY: /\A(?:%\h\h|[!$&-.0-;=@-Z_a-z~\/?])*\z/,
+ FRAGMENT: /\A(?:%\h\h|[!$&-.0-;=@-Z_a-z~\/?])*\z/,
+ OPAQUE: /\A(?:[^\/].*)?\z/,
+-PORT: /\A[\x09\x0a\x0c\x0d ]*\d*[\x09\x0a\x0c\x0d ]*\z/,
++PORT: /\A[\x09\x0a\x0c\x0d ]*+\d*[\x09\x0a\x0c\x0d ]*\z/,
+   }
+ end
+
+diff --git a/test/uri/test_parser.rb b/test/uri/test_parser.rb
+index 01ed32a..81c2210 100644
+--- a/test/uri/test_parser.rb
 b/test/uri/test_parser.rb
+@@ -75,4 +75,14 @@ class URI::TestParser < Test::Unit::TestCase
+   end
+ end
+   end
++
++  def test_rfc3986_port_check
++pre = ->(length) {"\t" * length + "a"}
++uri = URI.parse("http://my.example.com;)
++assert_linear_performance((1..5).map {|i| 10**i}, pre: pre) do |port|
++  assert_raise(URI::InvalidComponentError) do
++uri.port = port
++  end
++end
++  end
+ end
+--
+2.40.0
diff --git a/meta/recipes-devtools/ruby/ruby_3.1.3.bb 
b/meta/recipes-devtools/ruby/ruby_3.1.3.bb
index 72030508dd..228a2204db 100644
--- a/meta/recipes-devtools/ruby/ruby_3.1.3.bb
+++ b/meta/recipes-devtools/ruby/ruby_3.1.3.bb
@@ -31,6 +31,8 @@ SRC_URI = 
"http://cache.ruby-lang.org/pub/ruby/${SHRT_VER}/ruby-${PV}.tar.gz \

[OE-core][kirkstone 04/17] gstreamer1.0-plugins-bad: fix CVE-2023-40475

2023-09-27 Thread Steve Sakoman
From: Archana Polampalli 

gst-plugins-bad: Integer overflow leading to heap overwrite in MXF file 
handling with AES3 audio

Signed-off-by: Archana Polampalli 
Signed-off-by: Steve Sakoman 
---
 .../CVE-2023-40475.patch  | 49 +++
 .../gstreamer1.0-plugins-bad_1.20.7.bb|  1 +
 2 files changed, 50 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40475.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40475.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40475.patch
new file mode 100644
index 00..ab9ac7afaa
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40475.patch
@@ -0,0 +1,49 @@
+From 72742dee30cce7bf909639f82de119871566ce39 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= 
+Date: Thu, 10 Aug 2023 15:47:03 +0300
+Subject: [PATCH] mxfdemux: Check number of channels for AES3 audio
+
+Only up to 8 channels are allowed and using a higher number would cause
+integer overflows when copying the data, and lead to out of bound
+writes.
+
+Also check that each buffer is at least 4 bytes long to avoid another
+overflow.
+
+Fixes ZDI-CAN-21661, CVE-2023-40475
+
+Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2897
+
+Part-of: 

+
+Upstream-Status: Backport 
[https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/72742dee30cce7bf909639f82de119871566ce39]
+CVE: CVE-2023-40475
+
+Signed-off-by: Archana Polampalli 
+---
+ gst/mxf/mxfd10.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/gst/mxf/mxfd10.c b/gst/mxf/mxfd10.c
+index 03854d9303..0ad0d2d283 100644
+--- a/gst/mxf/mxfd10.c
 b/gst/mxf/mxfd10.c
+@@ -101,7 +101,7 @@ mxf_d10_sound_handle_essence_element (const MXFUL * key, 
GstBuffer * buffer,
+   gst_buffer_map (buffer, , GST_MAP_READ);
+
+   /* Now transform raw AES3 into raw audio, see SMPTE 331M */
+-  if ((map.size - 4) % 32 != 0) {
++  if (map.size < 4 || (map.size - 4) % 32 != 0) {
+ gst_buffer_unmap (buffer, );
+ GST_ERROR ("Invalid D10 sound essence buffer size");
+ return GST_FLOW_ERROR;
+@@ -201,6 +201,7 @@ mxf_d10_create_caps (MXFMetadataTimelineTrack * track, 
GstTagList ** tags,
+ GstAudioFormat audio_format;
+
+ if (s->channel_count == 0 ||
++s->channel_count > 8 ||
+ s->quantization_bits == 0 ||
+ s->audio_sampling_rate.n == 0 || s->audio_sampling_rate.d == 0) {
+   GST_ERROR ("Invalid descriptor");
+--
+2.40.0
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb
index 52acb30d74..d5f1e794cd 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"https://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad
file://0003-ensure-valid-sentinals-for-gst_structure_get-etc.patch \

file://0004-opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch \
file://CVE-2023-40474.patch \
+   file://CVE-2023-40475.patch \
"
 SRC_URI[sha256sum] = 
"87251beebfd1325e5118cc67774061f6e8971761ca65a9e5957919610080d195"
 
-- 
2.34.1


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



[OE-core][kirkstone 06/17] go: Fix CVE-2023-39318

2023-09-27 Thread Steve Sakoman
From: Siddharth Doshi 

Upstream-Status: Backport from 
[https://github.com/golang/go/commit/023b542edf38e2a1f87fcefb9f75ff2f99401b4c]
CVE: CVE-2023-39318
Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |   1 +
 .../go/go-1.21/CVE-2023-39318.patch   | 238 ++
 2 files changed, 239 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.21/CVE-2023-39318.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index c753a26a7e..ed2645bc12 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -44,6 +44,7 @@ SRC_URI += "\
 file://CVE-2023-24531_2.patch \
 file://CVE-2023-29409.patch \
 file://CVE-2023-39319.patch \
+file://CVE-2023-39318.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.21/CVE-2023-39318.patch 
b/meta/recipes-devtools/go/go-1.21/CVE-2023-39318.patch
new file mode 100644
index 00..85c6ec97c8
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.21/CVE-2023-39318.patch
@@ -0,0 +1,238 @@
+From 023b542edf38e2a1f87fcefb9f75ff2f99401b4c Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Thu, 3 Aug 2023 12:24:13 -0700
+Subject: [PATCH] [release-branch.go1.20] html/template: support HTML-like
+ comments in script contexts
+
+Per Appendix B.1.1 of the ECMAScript specification, support HTML-like
+comments in script contexts. Also per section 12.5, support hashbang
+comments. This brings our parsing in-line with how browsers treat these
+comment types.
+
+Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for
+reporting this issue.
+
+Fixes #62196
+Fixes #62395
+Fixes CVE-2023-39318
+
+Change-Id: Id512702c5de3ae46cf648e268cb10e1eb392a181
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1976593
+Run-TryBot: Roland Shoemaker 
+Reviewed-by: Tatiana Bradley 
+Reviewed-by: Damien Neil 
+Reviewed-by: Dmitri Shuralyov 
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2014620
+Reviewed-on: https://go-review.googlesource.com/c/go/+/526098
+Run-TryBot: Cherry Mui 
+TryBot-Result: Gopher Robot 
+
+Upstream-Status: Backport from 
[https://github.com/golang/go/commit/023b542edf38e2a1f87fcefb9f75ff2f99401b4c]
+CVE: CVE-2023-39318
+Signed-off-by: Siddharth Doshi 
+---
+ src/html/template/context.go  |  6 ++-
+ src/html/template/escape.go   |  5 +-
+ src/html/template/escape_test.go  | 10 
+ src/html/template/state_string.go |  4 +-
+ src/html/template/transition.go   | 80 ---
+ 5 files changed, 72 insertions(+), 33 deletions(-)
+
+diff --git a/src/html/template/context.go b/src/html/template/context.go
+index f5f44a1..feb6517 100644
+--- a/src/html/template/context.go
 b/src/html/template/context.go
+@@ -124,6 +124,10 @@ const (
+   stateJSBlockCmt
+   // stateJSLineCmt occurs inside a JavaScript // line comment.
+   stateJSLineCmt
++  // stateJSHTMLOpenCmt occurs inside a JavaScript  HTML-like comment.
++  stateJSHTMLCloseCmt
+   // stateCSS occurs inside a 

[OE-core][kirkstone 05/17] gstreamer1.0-plugins-bad: fix CVE-2023-40476

2023-09-27 Thread Steve Sakoman
From: Archana Polampalli 

gst-plugins-bad: h265parser: Fix possible overflow using max_sub_layers_minus1

Signed-off-by: Archana Polampalli 
Signed-off-by: Steve Sakoman 
---
 .../CVE-2023-40476.patch  | 44 +++
 .../gstreamer1.0-plugins-bad_1.20.7.bb|  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40476.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40476.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40476.patch
new file mode 100644
index 00..7810e98024
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40476.patch
@@ -0,0 +1,44 @@
+From 1b51467ea640bcc73c97f3186350d72cbfba5cb4 Mon Sep 17 00:00:00 2001
+From: Nicolas Dufresne 
+Date: Wed, 9 Aug 2023 12:49:19 -0400
+Subject: [PATCH] h265parser: Fix possible overflow using max_sub_layers_minus1
+
+This fixes a possible overflow that can be triggered by an invalid value of
+max_sub_layers_minus1 being set in the bitstream. The bitstream uses 3 bits,
+but the allowed range is 0 to 6 only.
+
+Fixes ZDI-CAN-21768, CVE-2023-40476
+
+Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2895
+
+Part-of: 

+
+Upstream-Status: Backport 
[https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/ff91a3d8d6f7e2412c44663bf30fad5c7fdbc9d9]
+CVE: CVE-2023-40476
+
+Signed-off-by: Archana Polampalli 
+
+---
+ gst-libs/gst/codecparsers/gsth265parser.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/gst-libs/gst/codecparsers/gsth265parser.c 
b/gst-libs/gst/codecparsers/gsth265parser.c
+index a4e7549..3db1c38 100644
+--- a/gst-libs/gst/codecparsers/gsth265parser.c
 b/gst-libs/gst/codecparsers/gsth265parser.c
+@@ -1670,6 +1670,7 @@ gst_h265_parse_vps (GstH265NalUnit * nalu, GstH265VPS * 
vps)
+
+   READ_UINT8 (, vps->max_layers_minus1, 6);
+   READ_UINT8 (, vps->max_sub_layers_minus1, 3);
++  CHECK_ALLOWED (vps->max_sub_layers_minus1, 0, 6);
+   READ_UINT8 (, vps->temporal_id_nesting_flag, 1);
+
+   /* skip reserved_0x_16bits */
+@@ -1849,6 +1850,7 @@ gst_h265_parse_sps (GstH265Parser * parser, 
GstH265NalUnit * nalu,
+   sps->vps = vps;
+
+   READ_UINT8 (, sps->max_sub_layers_minus1, 3);
++  CHECK_ALLOWED (sps->max_sub_layers_minus1, 0, 6);
+   READ_UINT8 (, sps->temporal_id_nesting_flag, 1);
+
+   if (!gst_h265_parse_profile_tier_level (>profile_tier_level, ,
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb
index d5f1e794cd..fbaabda3f9 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.7.bb
@@ -12,6 +12,7 @@ SRC_URI = 
"https://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad

file://0004-opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch \
file://CVE-2023-40474.patch \
file://CVE-2023-40475.patch \
+   file://CVE-2023-40476.patch \
"
 SRC_URI[sha256sum] = 
"87251beebfd1325e5118cc67774061f6e8971761ca65a9e5957919610080d195"
 
-- 
2.34.1


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



[OE-core][kirkstone 03/17] gstreamer1.0-plugins-bad: fix CVE-2023-40474

2023-09-27 Thread Steve Sakoman
From: Archana Polampalli 

gst-plugins-bad: Heap-based buffer overflow in the MXF file demuxer when 
handling
malformed files with uncompressed video in GStreamer versions before 1.22.6

Signed-off-by: Archana Polampalli 
Signed-off-by: Steve Sakoman 
---
 .../CVE-2023-40474.patch  | 118 ++
 .../gstreamer1.0-plugins-bad_1.20.7.bb|   1 +
 2 files changed, 119 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40474.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40474.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40474.patch
new file mode 100644
index 00..dd5886863d
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/CVE-2023-40474.patch
@@ -0,0 +1,118 @@
+From ce17e968e4cf900d28ca5b46f6e095febc42b4f0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= 
+Date: Thu, 10 Aug 2023 15:45:01 +0300
+Subject: [PATCH] mxfdemux: Fix integer overflow causing out of bounds writes
+ when handling invalid uncompressed video
+
+Check ahead of time when parsing the track information whether
+width, height and bpp are valid and usable without overflows.
+
+Fixes ZDI-CAN-21660, CVE-2023-40474
+
+Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2896
+
+Part-of: 

+
+Upstream-Status: Backport 
[https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/ce17e968e4cf900d28ca5b46f6e095febc42b4f0]
+CVE: CVE-2023-40474
+
+Signed-off-by: Archana Polampalli 
+---
+ gst/mxf/mxfup.c | 51 +
+ 1 file changed, 43 insertions(+), 8 deletions(-)
+
+diff --git a/gst/mxf/mxfup.c b/gst/mxf/mxfup.c
+index d72ed22cb7..0c0178c1c9 100644
+--- a/gst/mxf/mxfup.c
 b/gst/mxf/mxfup.c
+@@ -118,6 +118,8 @@ mxf_up_handle_essence_element (const MXFUL * key, 
GstBuffer * buffer,
+ gpointer mapping_data, GstBuffer ** outbuf)
+ {
+   MXFUPMappingData *data = mapping_data;
++  gsize expected_in_stride = 0, out_stride = 0;
++  gsize expected_in_size = 0, out_size = 0;
+
+   /* SMPTE 384M 7.1 */
+   if (key->u[12] != 0x15 || (key->u[14] != 0x01 && key->u[14] != 0x02
+@@ -146,22 +148,25 @@ mxf_up_handle_essence_element (const MXFUL * key, 
GstBuffer * buffer,
+ }
+   }
+
+-  if (gst_buffer_get_size (buffer) != data->bpp * data->width * data->height) 
{
++  // Checked for overflows when parsing the descriptor
++  expected_in_stride = data->bpp * data->width;
++  out_stride = GST_ROUND_UP_4 (expected_in_stride);
++  expected_in_size = expected_in_stride * data->height;
++  out_size = out_stride * data->height;
++
++  if (gst_buffer_get_size (buffer) != expected_in_size) {
+ GST_ERROR ("Invalid buffer size");
+ gst_buffer_unref (buffer);
+ return GST_FLOW_ERROR;
+   }
+
+-  if (data->bpp != 4
+-  || GST_ROUND_UP_4 (data->width * data->bpp) != data->width * data->bpp) 
{
++  if (data->bpp != 4 || out_stride != expected_in_stride) {
+ guint y;
+ GstBuffer *ret;
+ GstMapInfo inmap, outmap;
+ guint8 *indata, *outdata;
+
+-ret =
+-gst_buffer_new_and_alloc (GST_ROUND_UP_4 (data->width * data->bpp) *
+-data->height);
++ret = gst_buffer_new_and_alloc (out_size);
+ gst_buffer_map (buffer, , GST_MAP_READ);
+ gst_buffer_map (ret, , GST_MAP_WRITE);
+ indata = inmap.data;
+@@ -169,8 +174,8 @@ mxf_up_handle_essence_element (const MXFUL * key, 
GstBuffer * buffer,
+
+ for (y = 0; y < data->height; y++) {
+   memcpy (outdata, indata, data->width * data->bpp);
+-  outdata += GST_ROUND_UP_4 (data->width * data->bpp);
+-  indata += data->width * data->bpp;
++  outdata += out_stride;
++  indata += expected_in_stride;
+ }
+
+ gst_buffer_unmap (buffer, );
+@@ -378,6 +383,36 @@ mxf_up_create_caps (MXFMetadataTimelineTrack * track, 
GstTagList ** tags,
+ return NULL;
+   }
+
++  if (caps) {
++MXFUPMappingData *data = *mapping_data;
++gsize expected_in_stride = 0, out_stride = 0;
++gsize expected_in_size = 0, out_size = 0;
++
++// Do some checking of the parameters to see if they're valid and
++// we can actually work with them.
++if (data->image_start_offset > data->image_end_offset) {
++  GST_WARNING ("Invalid image start/end offset");
++  g_free (data);
++  *mapping_data = NULL;
++  gst_clear_caps ();
++
++  return NULL;
++}
++
++if (!g_size_checked_mul (_in_stride, data->bpp, data->width) ||
++(out_stride = GST_ROUND_UP_4 (expected_in_stride)) < 
expected_in_stride
++|| !g_size_checked_mul (_in_size, expected_in_stride,
++data->height)
++|| !g_size_checked_mul (_size, out_stride, data->height)) {
++  GST_ERROR ("Invalid resolution or bit depth");
++  g_free (data);
++  *mapping_data = NULL;
++  gst_clear_caps ();
++
++  return NULL;
++}

[OE-core][kirkstone 02/17] ghostscript: fix CVE-2023-43115

2023-09-27 Thread Steve Sakoman
From: Archana Polampalli 

In Artifex Ghostscript through 10.01.2, gdevijs.c in GhostPDL can lead to remote
code execution via crafted PostScript documents because they can switch to the
IJS device, or change the IjsServer parameter, after SAFER has been activated.
NOTE: it is a documented risk that the IJS server can be specified on a gs
command line (the IJS device inherently must execute a command to start the IJS 
server).

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-43115

Upstream patches:
https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8b0f20002536867bd73ff4552408a72597190cbe

Signed-off-by: Archana Polampalli 
Signed-off-by: Steve Sakoman 
---
 .../ghostscript/CVE-2023-43115.patch  | 62 +++
 .../ghostscript/ghostscript_9.55.0.bb |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2023-43115.patch

diff --git a/meta/recipes-extended/ghostscript/ghostscript/CVE-2023-43115.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2023-43115.patch
new file mode 100644
index 00..979f354ed5
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2023-43115.patch
@@ -0,0 +1,62 @@
+From 8b0f20002536867bd73ff4552408a72597190cbe Mon Sep 17 00:00:00 2001
+From: Ken Sharp 
+Date: Thu, 24 Aug 2023 15:24:35 +0100
+Subject: [PATCH] IJS device - try and secure the IJS server startup
+
+Bug #707051 ""ijs" device can execute arbitrary commands"
+
+The problem is that the 'IJS' device needs to start the IJS server, and
+that is indeed an arbitrary command line. There is (apparently) no way
+to validate it. Indeed, this is covered quite clearly in the comments
+at the start of the source:
+
+ * WARNING: The ijs server can be selected on the gs command line
+ * which is a security risk, since any program can be run.
+
+Previously this used the awful LockSafetyParams hackery, which we
+abandoned some time ago because it simply couldn't be made secure (it
+was implemented in PostScript and was therefore vulnerable to PostScript
+programs).
+
+This commit prevents PostScript programs switching to the IJS device
+after SAFER has been activated, and prevents changes to the IjsServer
+parameter after SAFER has been activated.
+
+SAFER is activated, unless explicitly disabled, before any user
+PostScript is executed which means that the device and the server
+invocation can only be configured on the command line. This does at
+least provide minimal security against malicious PostScript programs.
+
+Upstream-Status: Backport 
[https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8b0f20002536867bd73ff4552408a72597190cbe]
+
+CVE: CVE-2023-43115
+
+Signed-off-by: Archana Polampalli 
+---
+ devices/gdevijs.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/devices/gdevijs.c b/devices/gdevijs.c
+index 8cbd84b97..16f5a1752 100644
+--- a/devices/gdevijs.c
 b/devices/gdevijs.c
+@@ -888,6 +888,8 @@ gsijs_initialize_device(gx_device *dev)
+ static const char rgb[] = "DeviceRGB";
+ gx_device_ijs *ijsdev = (gx_device_ijs *)dev;
+
++if (ijsdev->memory->gs_lib_ctx->core->path_control_active)
++return_error(gs_error_invalidaccess);
+ if (!ijsdev->ColorSpace) {
+ ijsdev->ColorSpace = gs_malloc(ijsdev->memory, sizeof(rgb), 1,
+"gsijs_initialize");
+@@ -1326,7 +1328,7 @@ gsijs_put_params(gx_device *dev, gs_param_list *plist)
+ if (code >= 0)
+ code = gsijs_read_string(plist, "IjsServer",
+ ijsdev->IjsServer, sizeof(ijsdev->IjsServer),
+-dev->LockSafetyParams, is_open);
++ijsdev->memory->gs_lib_ctx->core->path_control_active, is_open);
+
+ if (code >= 0)
+ code = gsijs_read_string_malloc(plist, "DeviceManufacturer",
+--
+2.40.0
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb 
b/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb
index ad0b008cab..4c4c22cf39 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb
@@ -38,6 +38,7 @@ SRC_URI_BASE = 
"https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/d
 file://CVE-2023-36664-0001.patch \
 file://CVE-2023-36664-0002.patch \
 file://CVE-2023-38559.patch \
+file://CVE-2023-43115.patch \
 "
 
 SRC_URI = "${SRC_URI_BASE} \
-- 
2.34.1


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



[OE-core][kirkstone 00/17] Patch review

2023-09-27 Thread Steve Sakoman
Please review this set of changes for kirkstone and have comments back by
end of day Friday, September 29

Passed a-full on autobuilder (other than a known send-qa-email issue):

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5956
 
The following changes since commit d90e4d5e3cca9cffe8f60841afc63667a9ac39fa:

  build-appliance-image: Update to kirkstone head revision (2023-09-24 10:53:54 
-1000)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/kirkstone-nut
  
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut

Archana Polampalli (4):
  ghostscript: fix CVE-2023-43115
  gstreamer1.0-plugins-bad: fix CVE-2023-40474
  gstreamer1.0-plugins-bad: fix CVE-2023-40475
  gstreamer1.0-plugins-bad: fix CVE-2023-40476

Colin McAllister (1):
  libwebp: Fix CVE-2023-5129

Jaeyoon Jung (1):
  cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfig

Lee Chee Yang (2):
  cups: Fix CVE-2023-4504
  bind: update to 9.18.19

Meenali Gupta (1):
  ruby: fix CVE-2023-36617

Narpat Mali (1):
  python3-git: upgrade 3.1.32 -> 3.1.37

Peter Marko (1):
  openssl: Upgrade 3.0.10 -> 3.0.11

Ross Burton (2):
  linux-yocto: update CVE exclusions
  xserver-xorg: ignore CVE-2022-3553 as it is XQuartz-specific

Ryan Eatmon (1):
  kernel.bbclass: Add force flag to rm calls

Siddharth Doshi (1):
  go: Fix CVE-2023-39318

Soumya Sambu (1):
  shadow: Fix CVE-2023-4641

Yogita Urade (1):
  webkitgtk: fix CVE-2023-32439

 meta/classes/cml1.bbclass |2 +-
 meta/classes/kernel.bbclass   |4 +-
 ...1-avoid-start-failure-with-bind-user.patch |0
 ...d-V-and-start-log-hide-build-options.patch |0
 ...ching-for-json-headers-searches-sysr.patch |0
 .../bind/{bind-9.18.17 => bind}/bind9 |0
 .../bind/{bind-9.18.17 => bind}/conf.patch|0
 .../generate-rndc-key.sh  |0
 ...t.d-add-support-for-read-only-rootfs.patch |0
 .../make-etc-initd-bind-stop-work.patch   |0
 .../bind/{bind-9.18.17 => bind}/named.service |0
 .../bind/{bind_9.18.17.bb => bind_9.18.19.bb} |2 +-
 .../{openssl_3.0.10.bb => openssl_3.0.11.bb}  |2 +-
 meta/recipes-devtools/go/go-1.17.13.inc   |1 +
 .../go/go-1.21/CVE-2023-39318.patch   |  238 +
 ...n3-git_3.1.32.bb => python3-git_3.1.37.bb} |4 +-
 .../ruby/ruby/CVE-2023-36617_1.patch  |   52 +
 .../ruby/ruby/CVE-2023-36617_2.patch  |   47 +
 meta/recipes-devtools/ruby/ruby_3.1.3.bb  |2 +
 meta/recipes-extended/cups/cups.inc   |1 +
 .../cups/cups/CVE-2023-4504.patch |   42 +
 .../ghostscript/CVE-2023-43115.patch  |   62 +
 .../ghostscript/ghostscript_9.55.0.bb |1 +
 .../shadow/files/CVE-2023-4641-0001.patch |   36 +
 .../shadow/files/CVE-2023-4641-0002.patch |  147 +
 meta/recipes-extended/shadow/shadow.inc   |2 +
 .../xorg-xserver/xserver-xorg.inc |2 +
 .../linux/cve-exclusion_5.10.inc  | 7255 +
 .../linux/cve-exclusion_5.15.inc  |  151 +-
 meta/recipes-kernel/linux/linux-yocto_5.10.bb |1 +
 .../CVE-2023-40474.patch  |  118 +
 .../CVE-2023-40475.patch  |   49 +
 .../CVE-2023-40476.patch  |   44 +
 .../gstreamer1.0-plugins-bad_1.20.7.bb|3 +
 .../webp/files/CVE-2023-5129.patch|  364 +
 meta/recipes-multimedia/webp/libwebp_1.2.4.bb |1 +
 .../webkit/webkitgtk/CVE-2023-32439.patch |  127 +
 meta/recipes-sato/webkit/webkitgtk_2.36.8.bb  |1 +
 38 files changed, 8719 insertions(+), 42 deletions(-)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => 
bind}/0001-avoid-start-failure-with-bind-user.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => 
bind}/0001-named-lwresd-V-and-start-log-hide-build-options.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => 
bind}/bind-ensure-searching-for-json-headers-searches-sysr.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => bind}/bind9 (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => bind}/conf.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => 
bind}/generate-rndc-key.sh (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => 
bind}/init.d-add-support-for-read-only-rootfs.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => 
bind}/make-etc-initd-bind-stop-work.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.17 => bind}/named.service 
(100%)
 rename meta/recipes-connectivity/bind/{bind_9.18.17.bb => bind_9.18.19.bb} 
(97%)
 rename meta/recipes-connectivity/openssl/{openssl_3.0.10.bb => 
openssl_3.0.11.bb} (99%)
 create mode 100644 meta/recipes-devtools/go/go-1.21/CVE-2023-39318.patch
 rename meta/recipes-devtools/python/{python3-git_3.1.32.bb => 
python3-git_3.1.37.bb} (86%)
 create mode 100644 

[OE-core][kirkstone 01/17] shadow: Fix CVE-2023-4641

2023-09-27 Thread Steve Sakoman
From: Soumya Sambu 

shadow-utils: possible password leak during passwd(1) change

Signed-off-by: Soumya Sambu 
Signed-off-by: Steve Sakoman 
---
 .../shadow/files/CVE-2023-4641-0001.patch |  36 +
 .../shadow/files/CVE-2023-4641-0002.patch | 147 ++
 meta/recipes-extended/shadow/shadow.inc   |   2 +
 3 files changed, 185 insertions(+)
 create mode 100644 meta/recipes-extended/shadow/files/CVE-2023-4641-0001.patch
 create mode 100644 meta/recipes-extended/shadow/files/CVE-2023-4641-0002.patch

diff --git a/meta/recipes-extended/shadow/files/CVE-2023-4641-0001.patch 
b/meta/recipes-extended/shadow/files/CVE-2023-4641-0001.patch
new file mode 100644
index 00..2d3c462f4d
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2023-4641-0001.patch
@@ -0,0 +1,36 @@
+From 58b6e97a9eef866e9e479fb781aaaf59fb11ef36 Mon Sep 17 00:00:00 2001
+From: Christian Göttsche 
+Date: Mon Apr 25 12:17:40 2022 +0200
+Subject: [PATCH 1/2] passwd: erase password copy on all error branches
+
+CVE: CVE-2023-4641
+
+Upstream-Status: Backport 
[https://github.com/shadow-maint/shadow/commit/58b6e97a9eef866e9e479fb781aaaf59fb11ef36]
+
+Signed-off-by: Soumya Sambu 
+---
+ src/passwd.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/passwd.c b/src/passwd.c
+index 80531ec..8c6f81a 100644
+--- a/src/passwd.c
 b/src/passwd.c
+@@ -289,6 +289,7 @@ static int new_password (const struct passwd *pw)
+   cp = getpass (_("New password: "));
+   if (NULL == cp) {
+   memzero (orig, sizeof orig);
++  memzero (pass, sizeof pass);
+   return -1;
+   }
+   if (warned && (strcmp (pass, cp) != 0)) {
+@@ -316,6 +317,7 @@ static int new_password (const struct passwd *pw)
+   cp = getpass (_("Re-enter new password: "));
+   if (NULL == cp) {
+   memzero (orig, sizeof orig);
++  memzero (pass, sizeof pass);
+   return -1;
+   }
+   if (strcmp (cp, pass) != 0) {
+--
+2.40.0
diff --git a/meta/recipes-extended/shadow/files/CVE-2023-4641-0002.patch 
b/meta/recipes-extended/shadow/files/CVE-2023-4641-0002.patch
new file mode 100644
index 00..a37379d7a0
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2023-4641-0002.patch
@@ -0,0 +1,147 @@
+From 65c88a43a23c2391dcc90c0abda3e839e9c57904 Mon Sep 17 00:00:00 2001
+From: Alejandro Colomar 
+Date: Sat, 10 Jun 2023 16:20:05 +0200
+Subject: [PATCH 2/2] gpasswd(1): Fix password leak
+
+How to trigger this password leak?
+~~
+
+When gpasswd(1) asks for the new password, it asks twice (as is usual
+for confirming the new password).  Each of those 2 password prompts
+uses agetpass() to get the password.  If the second agetpass() fails,
+the first password, which has been copied into the 'static' buffer
+'pass' via STRFCPY(), wasn't being zeroed.
+
+agetpass() is defined in <./libmisc/agetpass.c> (around line 91), and
+can fail for any of the following reasons:
+
+-  malloc(3) or readpassphrase(3) failure.
+
+   These are going to be difficult to trigger.  Maybe getting the system
+   to the limits of memory utilization at that exact point, so that the
+   next malloc(3) gets ENOMEM, and possibly even the OOM is triggered.
+   About readpassphrase(3), ENFILE and EINTR seem the only plausible
+   ones, and EINTR probably requires privilege or being the same user;
+   but I wouldn't discard ENFILE so easily, if a process starts opening
+   files.
+
+-  The password is longer than PASS_MAX.
+
+   The is plausible with physical access.  However, at that point, a
+   keylogger will be a much simpler attack.
+
+And, the attacker must be able to know when the second password is being
+introduced, which is not going to be easy.
+
+How to read the password after the leak?
+
+
+Provoking the leak yourself at the right point by entering a very long
+password is easy, and inspecting the process stack at that point should
+be doable.  Try to find some consistent patterns.
+
+Then, search for those patterns in free memory, right after the victim
+leaks their password.
+
+Once you get the leak, a program should read all the free memory
+searching for patterns that gpasswd(1) leaves nearby the leaked
+password.
+
+On 6/10/23 03:14, Seth Arnold wrote:
+> An attacker process wouldn't be able to use malloc(3) for this task.
+> There's a handful of tools available for userspace to allocate memory:
+>
+> -  brk / sbrk
+> -  mmap MAP_ANONYMOUS
+> -  mmap /dev/zero
+> -  mmap some other file
+> -  shm_open
+> -  shmget
+>
+> Most of these return only pages of zeros to a process.  Using mmap of an
+> existing file, you can get some of the contents of the file demand-loaded
+> into the memory space on the first use.
+>
+> The MAP_UNINITIALIZED flag only works if the kernel was compiled with

[OE-core] [PATCH] curl: Skip tests marked flaky

2023-09-27 Thread Robert Joslyn via lists.openembedded.org
From: Robert Joslyn 

Some tests can fail intermittently and upstream has marked these as
flaky so they can easily be skipped. At present there are 12 tests
marked flaky with 10 of them running in the default recipe
configuration. Skip them to avoid the failures.

Signed-off-by: Robert Joslyn 
---
 meta/recipes-support/curl/curl/run-ptest | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/curl/curl/run-ptest 
b/meta/recipes-support/curl/curl/run-ptest
index 95af2bd7b3..8f9c20f34d 100644
--- a/meta/recipes-support/curl/curl/run-ptest
+++ b/meta/recipes-support/curl/curl/run-ptest
@@ -1,6 +1,6 @@
 #!/bin/sh
 cd tests
-{ ./runtests.pl -a -n -s -j4 || echo "FAIL: curl" ; } | sed \
+{ ./runtests.pl -a -n -s -j4 !flaky || echo "FAIL: curl" ; } | sed \
  -e 's|\([^ ]* *\) \([^ ]* *\)...OK|PASS: \1 \2|' \
  -e 's|\([^ ]* *\) \([^ ]* *\)...FAILED|FAIL: \1 \2|' \
  -e 's/Warning: test[0-9]\+ not present in tests\/data\/Makefile.inc//'
-- 
2.41.0


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



[OE-core] [PATCH] Revert "glibc: fix CVE-2023-4527"

2023-09-27 Thread Khem Raj
This reverts commit 82dfa7b8ac5661134da21307d07d9ea2ed3ac6ea.

Its already included in the glibc minor update patch

Signed-off-by: Khem Raj 
---
 .../glibc/glibc/0024-CVE-2023-4527.patch  | 219 --
 meta/recipes-core/glibc/glibc_2.38.bb |   1 -
 2 files changed, 220 deletions(-)
 delete mode 100644 meta/recipes-core/glibc/glibc/0024-CVE-2023-4527.patch

diff --git a/meta/recipes-core/glibc/glibc/0024-CVE-2023-4527.patch 
b/meta/recipes-core/glibc/glibc/0024-CVE-2023-4527.patch
deleted file mode 100644
index 7d9adf6a667..000
--- a/meta/recipes-core/glibc/glibc/0024-CVE-2023-4527.patch
+++ /dev/null
@@ -1,219 +0,0 @@
-From 4ea972b7edd7e36610e8cde18bf7a8149d7bac4f Mon Sep 17 00:00:00 2001
-From: Florian Weimer 
-Date: Wed, 13 Sep 2023 14:10:56 +0200
-Subject: [PATCH] CVE-2023-4527: Stack read overflow with large TCP responses
- in no- mode
-
-Without passing alt_dns_packet_buffer, __res_context_search can only
-store 2048 bytes (what fits into dns_packet_buffer).  However,
-the function returns the total packet size, and the subsequent
-DNS parsing code in _nss_dns_gethostbyname4_r reads beyond the end
-of the stack-allocated buffer.
-
-Fixes commit f282cdbe7f436c75864e5640a4 ("resolv: Implement no-
-stub resolver option") and bug 30842.
-
-(cherry picked from commit bd77dd7e73e3530203be1c52c8a29d08270cb25d)
-
-Upstream-Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4ea972b7edd7e36610e8cde18bf7a8149d7bac4f]
-CVE: CVE-2023-4527
-
-Signed-off-by: Yash Shinde 
-

- NEWS  |   7 ++
- resolv/Makefile   |   2 +
- resolv/nss_dns/dns-host.c |   2 +-
- resolv/tst-resolv-no-vc.c | 129 ++
- 4 files changed, 139 insertions(+), 1 deletion(-)
- create mode 100644 resolv/tst-resolv-no-vc.c
-
-diff --git a/NEWS b/NEWS
 a/NEWS
-+++ b/NEWS
-@@ -126,6 +126,7 @@
-   [30477] libc: [RISCV]: time64 does not work on riscv32
-   [30515] dynamic-link: _dl_find_object incorrectly returns 1 during
- early startup
-+  [30842] Stack read overflow in getaddrinfo in no- mode (CVE-2023-4527)
-   [30527] network: resolv_conf lock not unlocked on allocation failure
-   [30550] math: powerpc64le: GCC-specific code for isinf() is being used
- on clang
-@@ -157,6 +158,12 @@
-   heap and prints it to the target log file, potentially revealing a
-   portion of the contents of the heap.
-
-+  CVE-2023-4527: If the system is configured in no- mode via
-+  /etc/resolv.conf, getaddrinfo is called for the AF_UNSPEC address
-+  family, and a DNS response is received over TCP that is larger than
-+  2048 bytes, getaddrinfo may potentially disclose stack contents via
-+  the returned address data, or crash.
-+
- The following bugs are resolved with this release:
-
-   [12154] network: Cannot resolve hosts which have wildcard aliases
-diff --git a/resolv/Makefile b/resolv/Makefile
 a/resolv/Makefile
-+++ b/resolv/Makefile
-@@ -102,6 +102,7 @@
-   tst-resolv-invalid-cname \
-   tst-resolv-network \
-   tst-resolv-no \
-+  tst-resolv-no-vc \
-   tst-resolv-nondecimal \
-   tst-resolv-res_init-multi \
-   tst-resolv-search \
-@@ -293,6 +294,7 @@
- $(objpfx)tst-resolv-invalid-cname: $(objpfx)libresolv.so \
-   $(shared-thread-library)
- $(objpfx)tst-resolv-no: $(objpfx)libresolv.so $(shared-thread-library)
-+$(objpfx)tst-resolv-no-vc: $(objpfx)libresolv.so $(shared-thread-library)
- $(objpfx)tst-resolv-nondecimal: $(objpfx)libresolv.so $(shared-thread-library)
- $(objpfx)tst-resolv-qtypes: $(objpfx)libresolv.so $(shared-thread-library)
- $(objpfx)tst-resolv-rotate: $(objpfx)libresolv.so $(shared-thread-library)
-diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
 a/resolv/nss_dns/dns-host.c
-+++ b/resolv/nss_dns/dns-host.c
-@@ -427,7 +427,7 @@ _nss_dns_gethostbyname4_r (const char *name, struct 
gaih_addrtuple **pat,
- {
-   n = __res_context_search (ctx, name, C_IN, T_A,
-   dns_packet_buffer, sizeof (dns_packet_buffer),
--  NULL, NULL, NULL, NULL, NULL);
-+  _dns_packet_buffer, NULL, NULL, NULL, NULL);
-   if (n >= 0)
-   status = gaih_getanswer_no (alt_dns_packet_buffer, n,
-   , pat, errnop, herrnop, ttlp);
-diff --git a/resolv/tst-resolv-no-vc.c b/resolv/tst-resolv-no-vc.c
-new file mode 100644
 /dev/null
-+++ b/resolv/tst-resolv-no-vc.c
-@@ -0,0 +1,129 @@
-+/* Test the RES_NO resolver option with a large response.
-+   Copyright (C) 2022-2023 Free Software Foundation, Inc.
-+   This file is part of the GNU C Library.
-+
-+   The GNU C Library is free software; you can redistribute it and/or
-+   modify it under the terms of the GNU Lesser General Public
-+   License as published by the Free Software Foundation; either
-+   version 2.1 of the License, or (at your option) any later 

Re: [OE-core] [][PATCH] glibc: stable 2.38 branch updates.

2023-09-27 Thread Khem Raj
Please rebase this change on top of latest master, seeing patching issues see
https://errors.yoctoproject.org/Errors/Details/738684/

On Wed, Sep 27, 2023 at 3:14 AM Hemraj, Deepthi via
lists.openembedded.org
 wrote:
>
> Below commits on glibc-2.38 stable branch are updated.
> 0e1ef6779a (HEAD -> release/2.38/master, origin/release/2.38/master) 
> manual/jobs.texi: Add missing @item EPERM for getpgid
> d94461bb86 string: Fix tester build with fortify enable with gcc < 12
> 63250e9c57 iconv: restore verbosity with unrecognized encoding names (bug 
> 30694)
> 00ae4f10b5 getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
> b25508dd77 CVE-2023-4527: Stack read overflow with large TCP responses in 
> no- mode
> 89da8bc588 NEWS: Add the 2.38.1 bug list
> d3ba6c1333 elf: Move l_init_called_next to old place of l_text_end in link map
> 750f19526a elf: Remove unused l_text_end field from struct link_map
> a3189f66a5 elf: Always call destructors in reverse constructor order (bug 
> 30785)
> 7ae211a01b elf: Do not run constructors for proxy objects
> 92201f16cb libio: Fix oversized __io_vtables
> 5bdef6f27c io: Fix record locking contants for powerpc64 with 
> __USE_FILE_OFFSET64
>
> Signed-off-by: Deepthi Hemraj 
> ---
>  meta/recipes-core/glibc/glibc-version.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-version.inc 
> b/meta/recipes-core/glibc/glibc-version.inc
> index a907444f50..f5ebbb2ee6 100644
> --- a/meta/recipes-core/glibc/glibc-version.inc
> +++ b/meta/recipes-core/glibc/glibc-version.inc
> @@ -1,6 +1,6 @@
>  SRCBRANCH ?= "release/2.38/master"
>  PV = "2.38+git"
> -SRCREV_glibc ?= "1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1"
> +SRCREV_glibc ?= "0e1ef6779a90bc0f8a05bc367796df2793deecaa"
>  SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1"
>
>  GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"
> --
> 2.39.0
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188347): 
https://lists.openembedded.org/g/openembedded-core/message/188347
Mute This Topic: https://lists.openembedded.org/mt/101614434/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Richard Purdie
On Wed, 2023-09-27 at 14:47 +0200, Julien Stephan wrote:
> Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni
>  a écrit :
> > 
> > Hello,
> > 
> > I had a build were all the tests passed, then I had this failure:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio
> > 
> 
> Hi Alexandre,
> I only see
> 
>bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED
> 
> but I can't see the actual error :( Is it possible to have it somewhere?

I am a bit worried this will be hard to reproduce/debug so I had a look
at things as I do really want to get things resolved.

The error log says:

WARNING: The quilt:do_build sig is computed to be 
255536826e64d835fcc6b5a277e9a3dacaae75318e608fa2df289bdfa23df40e, but the sig 
is locked to 0f48875f011499948d53edc6abbe9e4efd617d5ef9233055e4b61411cf01cb87 
in SIGGEN_LOCKEDSIGS_core2-64

and I couldn't reproduce those stamps in a local build or on the
builder where it failed (once I got access which took a while).

The "while" is important as I think in the meantime things changed
which effected the results.

On the autobuilder, "bitbake quilt -S none" generated stamp files for
quilt. I did this for "build" and "build-st-3046552", the latter being
the one where the test failed. There were two different do_build stamps
generated. The diff:

bitbake-diffsigs 
tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.b502a759bb6bceb6c8ccd76b57db2612501bb66bd9c46ece5f99f8bf16d7ac4a
  
../build/tmp/stamps/core2-64-poky-linux/quilt/0.67.do_build.sigdata.7cf16a1f87d5058e134f3f6fc02612515e28784625413c87d3545e93ae0ab407
 
NOTE: Reconnecting to bitbake server...
Hash for task dependency diffstat:do_package_write_rpm changed from 
41171f7938a2ddbe244372c1cc4300d91b7dca425eb8b214c19262e4949a7f18 to 
2211ac20553e9dddc710970cf1a663412ece5b5a2071e47c5471b3ee01efa2ce
Hash for task dependency diffstat:do_package changed from 
f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec to 
e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec
Unable to find matching sigdata for diffstat:do_package with hash 
e5ff0ed8a81d8022b0981162e9b4e286886d9e281adee81175725072c3d413ec

i.e. a couple of dependencies were different.

bitbake-diffsigs 
tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.f3fe486831eede23d2ebbc1efe2e2510f49f5df6d5d8a8ceb7aa2ddc6e11b1ec
  
../build/tmp/stamps/core2-64-poky-linux/diffstat/1.65.do_package.sigdata.af8ebe96c5cf424e1094c1599400a56096302e16d0f691daaeec380b963f37b2

showed no output, i.e. they appear to be the same but different.

My best guess at what is going on here is hash equivalence causing
problems. 

So in summary, I think the best solution will be to disable hash
equivalence for these tests.


Cheers,

Richard

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



Re: [OE-core] [PATCH V2] glibc: stable 2.38 branch updates.

2023-09-27 Thread Randy MacLeod via lists.openembedded.org

On 2023-09-27 3:52 p.m., Alexandre Belloni via lists.openembedded.org wrote:

Randy,

Can you please ensure everyone at Windriver that will contribute to YP
has setup their from identity? This is described here:

https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#fixing-your-from-identity

Thanks!

Hi Alex,


I've broadcast a summary of your email, the link and content internally.

If this continues next week, please just reject any patches until people 
make the change.


../Randy



On 27/09/2023 03:46:59-0700, Hemraj, Deepthi via lists.openembedded.org wrote:

Below commits on glibc-2.38 stable branch are updated.
0e1ef6779a (HEAD -> release/2.38/master, origin/release/2.38/master) 
manual/jobs.texi: Add missing @item EPERM for getpgid
d94461bb86 string: Fix tester build with fortify enable with gcc < 12
63250e9c57 iconv: restore verbosity with unrecognized encoding names (bug 30694)
00ae4f10b5 getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
b25508dd77 CVE-2023-4527: Stack read overflow with large TCP responses in 
no- mode
89da8bc588 NEWS: Add the 2.38.1 bug list
d3ba6c1333 elf: Move l_init_called_next to old place of l_text_end in link map
750f19526a elf: Remove unused l_text_end field from struct link_map
a3189f66a5 elf: Always call destructors in reverse constructor order (bug 30785)
7ae211a01b elf: Do not run constructors for proxy objects
92201f16cb libio: Fix oversized __io_vtables
5bdef6f27c io: Fix record locking contants for powerpc64 with 
__USE_FILE_OFFSET64

Signed-off-by: Deepthi Hemraj
---
  meta/recipes-core/glibc/glibc-version.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index a907444f50..f5ebbb2ee6 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
  SRCBRANCH ?= "release/2.38/master"
  PV = "2.38+git"
-SRCREV_glibc ?= "1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1"
+SRCREV_glibc ?= "0e1ef6779a90bc0f8a05bc367796df2793deecaa"
  SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1"
  
  GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"

--
2.39.0








--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188345): 
https://lists.openembedded.org/g/openembedded-core/message/188345
Mute This Topic: https://lists.openembedded.org/mt/101614685/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] json-c: define CVE_VERSION

2023-09-27 Thread Peter Marko via lists.openembedded.org
From: Peter Marko 

Recently NVD updated all CVEs for json-c and old fixed
cves are reported in some older yocto branches.
NVD match clause now includes full tag name including
date which is "greater" than tag without additional numbers.

Define CVE_VERSION identical to full tag also on master to
avoid future CVEs to be reported incorrectly.
Put it close to hash so recipe update patch includes this line.

Signed-off-by: Peter Marko 
---
 meta/recipes-devtools/json-c/json-c_0.17.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.17.bb 
b/meta/recipes-devtools/json-c/json-c_0.17.bb
index b7b596212f..f4b7a32cea 100644
--- a/meta/recipes-devtools/json-c/json-c_0.17.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.17.bb
@@ -9,6 +9,9 @@ SRC_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz \
"
 SRC_URI[sha256sum] = 
"7550914d58fb63b2c3546f3ccfbe11f1c094147bd31a69dcd23714d7956159e6"
 
+# NVD uses full tag name including date
+CVE_VERSION = "0.17-20230812"
+
 UPSTREAM_CHECK_URI = "https://github.com/${BPN}/${BPN}/tags;
 UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+)-\d+"
 
-- 
2.30.2


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



[OE-core][kirkstone][PATCH] json-c: define CVE_VERSION

2023-09-27 Thread Peter Marko via lists.openembedded.org
From: Peter Marko 

Recently NVD updated all CVEs for json-c and old fixed
CVE-2020-12762 is reported by cve_check now.
NVD match clause now includes full tag name including
date which is "greater" than tag without additional numbers.

Fix it by defining CVE_VERSION identical to full tag.
Put it close to hash so recipe update patch includes this line.

Signed-off-by: Peter Marko 
---
 meta/recipes-devtools/json-c/json-c_0.15.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.15.bb 
b/meta/recipes-devtools/json-c/json-c_0.15.bb
index 4da30bc50c..b3679e0135 100644
--- a/meta/recipes-devtools/json-c/json-c_0.15.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.15.bb
@@ -12,6 +12,9 @@ SRC_URI = " \
 
 SRC_URI[sha256sum] = 
"b8d80a1ddb718b3ba7492916237bbf86609e9709fb007e7f7d4322f02341a4c6"
 
+# NVD uses full tag name including date
+CVE_VERSION = "0.15-20200726"
+
 UPSTREAM_CHECK_URI = "https://github.com/${BPN}/${BPN}/tags;
 UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+)-\d+"
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188343): 
https://lists.openembedded.org/g/openembedded-core/message/188343
Mute This Topic: https://lists.openembedded.org/mt/101626335/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] devtool: modify: correctly handle multiple sources in SRC_URI

2023-09-27 Thread Richard Purdie
On Wed, 2023-09-27 at 18:50 +0200, Julien Stephan wrote:
> [YOCTO #15162]
> 
> When recipes such as bzip2 have several sources in SRC_URI, all the
> sources are correctly extracted into devtool temporary workdir, but
> currently, we only get back the primary source and all files declared
> using "files://", then the devtool temporary workdir is deleted
> 
> Fix this by moving all remaining files from devtool temporary workdir
> into actual WORKDIR (except "source-date-epoch", "recipe-sysroot",
> and "recipe-sysroot-native") before deleting it
> 
> Here is the stack trace from devtool modify/build bzip2:
> 
> NOTE: bzip2: compiling from external source tree 
> <...>/build/workspace/sources/bzip2
> ERROR: bzip2-1.0.8-r0 do_install_ptest_base: 
> ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368',
>  1, None, None)
> ERROR: Logfile of failure stored in: 
> <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
> Log data follows:
> > DEBUG: Executing shell function do_install_ptest_base
> > NOTE: make -j 16 
> > DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest
> >  install-ptest
> > sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
> >../../../../../../workspace/sources/bzip2/Makefile.am  > 
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
> > cp ../../../../../../workspace/sources/bzip2/sample1.ref  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
> > cp ../../../../../../workspace/sources/bzip2/sample2.ref  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
> > cp ../../../../../../workspace/sources/bzip2/sample3.ref  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
> > cp ../../../../../../workspace/sources/bzip2/sample1.bz2  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
> > cp ../../../../../../workspace/sources/bzip2/sample2.bz2  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
> > cp ../../../../../../workspace/sources/bzip2/sample3.bz2  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
> > ln -s /usr/bin/bzip2  
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
> > cp: cannot stat 
> > '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress':
> >  No such file or directory
> > WARNING: 
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189
> >  exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
> 1.0.8/git/commons-compress 
> <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
> > WARNING: Backtrace (BB generated script):
> >   #1: do_install_ptest, 
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368,
> >  line 189
> >   #2: do_install_ptest_base, 
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368,
> >  line 158
> >   #3: main, 
> > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368,
> >  line 226
> ERROR: Task 
> (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) 
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun 
> and 1 failed.
> 
> Summary: 1 task failed:
>   <...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base
> 
> Signed-off-by: Julien Stephan 
> ---
>  scripts/lib/devtool/standard.py | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
> index d53fb810071..6c8ad7a6c8c 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -684,6 +684,14 @@ def _extract_source(srctree, keep_temp, devbranch, sync, 
> config, basepath, works
>  shutil.move(srcsubdir, srctree)
>  symlink_oelocal_files_srctree(d,srctree)
>  
> +# In case SRC_URI contains multiple sources
> +# they are extracted into the devtool temporary workdir
> +# We need to move them into WORKDIR, otherwise they will be lost
> +for path in os.listdir(os.path.join(tempdir, 'workdir')):
> +if not path in ["source-date-epoch", "recipe-sysroot", 
> "recipe-sysroot-native"]:
> +workdir = d.getVar('WORKDIR')
> +shutil.move(os.path.join(tempdir, 'workdir', path), 
> workdir)
> +
>  if is_kernel_yocto:
>  logger.info('Copying kernel config to srctree')
>  shutil.copy2(os.path.join(tempdir, '.config'), srctree)

Looks like a good start 

[OE-core] [PATCH] oeqa/utils/gitarchive: Handle broken commit counts in results repo

2023-09-27 Thread Richard Purdie
The test results repository contains tags like:

master/64501-g65c94ca3196e5ef3344a469fea8e30444f2e967a/0
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/3
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/2
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/1
master/1-g65c94ca3196e5ef3344a469fea8e30444f2e967a/0

where the commit count is correct in one case and not in the others. This causes
assertion errors in the current code.

Add in some code to work around these historical issues where the commit counts 
are low.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/gitarchive.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/gitarchive.py 
b/meta/lib/oeqa/utils/gitarchive.py
index 64448f47d94..f9c152681db 100644
--- a/meta/lib/oeqa/utils/gitarchive.py
+++ b/meta/lib/oeqa/utils/gitarchive.py
@@ -255,7 +255,15 @@ def get_test_revs(log, repo, tag_name, **kwargs):
 if not commit in revs:
 revs[commit] = TestedRev(commit, commit_num, [tag])
 else:
-assert commit_num == revs[commit].commit_number, "Commit numbers 
do not match"
+if commit_num != revs[commit].commit_number:
+# Historically we have incorrect commit counts of '1' in the 
repo so fix these up
+if int(revs[commit].commit_number) < 5:
+tags = revs[commit].tags
+revs[commit] = TestedRev(commit, commit_num, [tags])
+elif int(commit_num) < 5:
+pass
+else:
+sys.exit("Commit numbers for commit %s don't match (%s vs 
%s)" % (commit, commit_num, revs[commit].commit_number))
 revs[commit].tags.append(tag)
 
 # Return in sorted table
-- 
2.39.2


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



Re: [OE-core] [PATCH V2] glibc: stable 2.38 branch updates.

2023-09-27 Thread Alexandre Belloni via lists.openembedded.org
Randy,

Can you please ensure everyone at Windriver that will contribute to YP
has setup their from identity? This is described here:

https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#fixing-your-from-identity

Thanks!

On 27/09/2023 03:46:59-0700, Hemraj, Deepthi via lists.openembedded.org wrote:
> Below commits on glibc-2.38 stable branch are updated.
> 0e1ef6779a (HEAD -> release/2.38/master, origin/release/2.38/master) 
> manual/jobs.texi: Add missing @item EPERM for getpgid
> d94461bb86 string: Fix tester build with fortify enable with gcc < 12
> 63250e9c57 iconv: restore verbosity with unrecognized encoding names (bug 
> 30694)
> 00ae4f10b5 getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
> b25508dd77 CVE-2023-4527: Stack read overflow with large TCP responses in 
> no- mode
> 89da8bc588 NEWS: Add the 2.38.1 bug list
> d3ba6c1333 elf: Move l_init_called_next to old place of l_text_end in link map
> 750f19526a elf: Remove unused l_text_end field from struct link_map
> a3189f66a5 elf: Always call destructors in reverse constructor order (bug 
> 30785)
> 7ae211a01b elf: Do not run constructors for proxy objects
> 92201f16cb libio: Fix oversized __io_vtables
> 5bdef6f27c io: Fix record locking contants for powerpc64 with 
> __USE_FILE_OFFSET64
> 
> Signed-off-by: Deepthi Hemraj 
> ---
>  meta/recipes-core/glibc/glibc-version.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/glibc/glibc-version.inc 
> b/meta/recipes-core/glibc/glibc-version.inc
> index a907444f50..f5ebbb2ee6 100644
> --- a/meta/recipes-core/glibc/glibc-version.inc
> +++ b/meta/recipes-core/glibc/glibc-version.inc
> @@ -1,6 +1,6 @@
>  SRCBRANCH ?= "release/2.38/master"
>  PV = "2.38+git"
> -SRCREV_glibc ?= "1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1"
> +SRCREV_glibc ?= "0e1ef6779a90bc0f8a05bc367796df2793deecaa"
>  SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1"
>  
>  GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"
> -- 
> 2.39.0
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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



[OE-core] [kirkstone][PATCH] ccache: fix build with gcc-13

2023-09-27 Thread Martin Jansa
* needed on hosts with gcc-13 for ccache-native

Signed-off-by: Martin Jansa 
---
 ...x-FTBFS-with-not-yet-released-GCC-13.patch | 92 +++
 meta/recipes-devtools/ccache/ccache_4.6.bb|  4 +-
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/ccache/ccache/0001-build-Fix-FTBFS-with-not-yet-released-GCC-13.patch

diff --git 
a/meta/recipes-devtools/ccache/ccache/0001-build-Fix-FTBFS-with-not-yet-released-GCC-13.patch
 
b/meta/recipes-devtools/ccache/ccache/0001-build-Fix-FTBFS-with-not-yet-released-GCC-13.patch
new file mode 100644
index 00..d62e1ef26b
--- /dev/null
+++ 
b/meta/recipes-devtools/ccache/ccache/0001-build-Fix-FTBFS-with-not-yet-released-GCC-13.patch
@@ -0,0 +1,92 @@
+From 1523eaeff4669e421b3f60618b43c878e4860fe6 Mon Sep 17 00:00:00 2001
+From: Joel Rosdahl 
+Date: Tue, 5 Jul 2022 21:42:58 +0200
+Subject: [PATCH] build: Fix FTBFS with not yet released GCC 13
+
+Reference: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
+
+Fixes #1105.
+
+Upstream-Status: Backport [v4.7 
https://github.com/ccache/ccache/commit/19ef6e267d38d4d8b3e11c915213472d5662d593]
+Signed-off-by: Martin Jansa 
+---
+ src/Stat.hpp  | 1 +
+ src/core/CacheEntryHeader.hpp | 2 ++
+ src/core/Sloppiness.hpp   | 1 +
+ src/core/Statistics.hpp   | 3 ++-
+ src/util/TextTable.hpp| 3 ++-
+ 5 files changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/src/Stat.hpp b/src/Stat.hpp
+index 2f56214a..074cdeeb 100644
+--- a/src/Stat.hpp
 b/src/Stat.hpp
+@@ -23,6 +23,7 @@
+ #include 
+ #include 
+ 
++#include 
+ #include 
+ #include 
+ 
+diff --git a/src/core/CacheEntryHeader.hpp b/src/core/CacheEntryHeader.hpp
+index 4c3e04c7..dcc32e1c 100644
+--- a/src/core/CacheEntryHeader.hpp
 b/src/core/CacheEntryHeader.hpp
+@@ -21,6 +21,8 @@
+ #include 
+ #include 
+ 
++#include 
++
+ // Cache entry format
+ // ==
+ //
+diff --git a/src/core/Sloppiness.hpp b/src/core/Sloppiness.hpp
+index 917526bf..1ab31d71 100644
+--- a/src/core/Sloppiness.hpp
 b/src/core/Sloppiness.hpp
+@@ -18,6 +18,7 @@
+ 
+ #pragma once
+ 
++#include 
+ #include 
+ 
+ namespace core {
+diff --git a/src/core/Statistics.hpp b/src/core/Statistics.hpp
+index 3e9ed816..54f32e9c 100644
+--- a/src/core/Statistics.hpp
 b/src/core/Statistics.hpp
+@@ -1,4 +1,4 @@
+-// Copyright (C) 2020-2021 Joel Rosdahl and other contributors
++// Copyright (C) 2020-2022 Joel Rosdahl and other contributors
+ //
+ // See doc/AUTHORS.adoc for a complete list of contributors.
+ //
+@@ -20,6 +20,7 @@
+ 
+ #include 
+ 
++#include 
+ #include 
+ #include 
+ #include 
+diff --git a/src/util/TextTable.hpp b/src/util/TextTable.hpp
+index 05c0e0e5..60edee75 100644
+--- a/src/util/TextTable.hpp
 b/src/util/TextTable.hpp
+@@ -1,4 +1,4 @@
+-// Copyright (C) 2021 Joel Rosdahl and other contributors
++// Copyright (C) 2021-2022 Joel Rosdahl and other contributors
+ //
+ // See doc/AUTHORS.adoc for a complete list of contributors.
+ //
+@@ -18,6 +18,7 @@
+ 
+ #pragma once
+ 
++#include 
+ #include 
+ #include 
+ 
diff --git a/meta/recipes-devtools/ccache/ccache_4.6.bb 
b/meta/recipes-devtools/ccache/ccache_4.6.bb
index f019679cf1..d94c5d591a 100644
--- a/meta/recipes-devtools/ccache/ccache_4.6.bb
+++ b/meta/recipes-devtools/ccache/ccache_4.6.bb
@@ -11,7 +11,9 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.adoc;md5=ff5327dc93e2b286c931dda3d6079da9"
 
 DEPENDS = "zstd"
 
-SRC_URI = 
"https://github.com/ccache/ccache/releases/download/v${PV}/${BP}.tar.gz;
+SRC_URI = 
"https://github.com/ccache/ccache/releases/download/v${PV}/${BP}.tar.gz \
+file://0001-build-Fix-FTBFS-with-not-yet-released-GCC-13.patch \
+"
 SRC_URI[sha256sum] = 
"73a1767ac6b7c0404a1a55f761a746d338e702883c7137fbf587023062258625"
 
 UPSTREAM_CHECK_URI = "https://github.com/ccache/ccache/releases/;
-- 
2.42.0


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



Re: [OE-core][PATCH 1/2] sstatesig: be more precise and show the full path in exceptions

2023-09-27 Thread Jose Quaresma
Gentle ping.

The other patch of the series was rejected but imho this one is useful as
it improves the error reporting.

Jose

Jose Quaresma via lists.openembedded.org  escreveu no dia quinta, 13/07/2023 à(s)
12:03:

> Also remove the warning than doesn't make sense as the code will generate
> an exception and bitbake will abort.
>
> Before:
> | WARNING: core-image-minimal-initramfs-1.0-r0 do_image_complete: KeyError
> in .
> | Exception: Exception: KeyError: 'getpwuid(): uid not found: x'
> | Path . is owned by uid x, gid yyy, which doesn't match any
> user/group on target. This may be due to host contamination.
>
> After:
> | Exception: Exception: KeyError: 'getpwuid(): uid not found: x'
> | Path
> /build/tmp/work/intel_corei7_64-lmp-linux/core-image-minimal-initramfs/1.0-r0/sstate-build-image_complete
> is owned by uid x, gid yyy, which doesn't match any user/group on
> target. This may be due to host contamination.
>
> Signed-off-by: Jose Quaresma 
> ---
>  meta/lib/oe/sstatesig.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index 30f27b0f4f..4a886215b2 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -595,9 +595,9 @@ def OEOuthashBasic(path, sigfile, task, d):
>  update_hash(" %10s" %
> pwd.getpwuid(s.st_uid).pw_name)
>  update_hash(" %10s" %
> grp.getgrgid(s.st_gid).gr_name)
>  except KeyError as e:
> -bb.warn("KeyError in %s" % path)
>  msg = ("KeyError: %s\nPath %s is owned by uid %d,
> gid %d, which doesn't match "
> -"any user/group on target. This may be due to
> host contamination." % (e, path, s.st_uid, s.st_gid))
> +"any user/group on target. This may be due to
> host contamination." %
> +(e, os.path.abspath(path), s.st_uid,
> s.st_gid))
>  raise
> Exception(msg).with_traceback(e.__traceback__)
>
>  if include_timestamps:
> --
> 2.34.1
>
>
> 
>
>

-- 
Best regards,

José Quaresma

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



Re: [OE-core][PATCH v2] gcc: depend on zstd

2023-09-27 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Sean Nyekjaer
> Sent: den 27 september 2023 14:58
> To: openembedded-core@lists.openembedded.org
> Cc: Sean Nyekjaer ; kas...@krinvent.dk
> Subject: [OE-core][PATCH v2] gcc: depend on zstd
> 
> Add zstd LTO support for target and nativesdk compiler.
> This also brings gcc into sync with gcc-cross.
> 
> ---

You do not want to use a line like the above in your commit 
message since Git will cut the commit message at the first 
occurrence of three dashes at the start of a line. I.e., 
everything below until the actual diff is ignored when 
applying this patch.

> % x86_64-oe-linux-gcc -v
> [...]
>  Supported LTO compression algorithms: zlib zstd
>  gcc version 12.2.0 (GCC)
> % x86_64-oesdk-linux-gcc -v
> [...]
>  Supported LTO compression algorithms: zlib
>  gcc version 12.2.0 (GCC)
> ---
> 
> Signed-off-by: Sean Nyekjaer 
> ---
>  meta/recipes-devtools/gcc/gcc-13.2.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-13.2.inc 
> b/meta/recipes-devtools/gcc/gcc-13.2.inc
> index d96f3171e4..359db1e278 100644
> --- a/meta/recipes-devtools/gcc/gcc-13.2.inc
> +++ b/meta/recipes-devtools/gcc/gcc-13.2.inc
> @@ -10,7 +10,7 @@ BINV = "13.2.0"
> 
>  FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
> 
> -DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
> +DEPENDS =+ "mpfr gmp libmpc zlib zstd flex-native"
>  NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native 
> zstd-native"
> 
>  LICENSE = "GPL-3.0-with-GCC-exception & GPL-3.0-only"
> --
> 2.42.0

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188337): 
https://lists.openembedded.org/g/openembedded-core/message/188337
Mute This Topic: https://lists.openembedded.org/mt/101616424/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] [Openembedded-architecture] [yocto] Security processes: YP needs

2023-09-27 Thread Marta Rybczynska
On Wed, 27 Sept 2023, 12:05 Reyna, David,  wrote:

> Hi Marta!
>
> > What about 11am Pacific on tomorrow (28 Sept or Oct 3)?
>
> Let us aim for October 3 so that I can prepare a full demo..
>
> > I think that you have meant 10am to 2PM, otherwise 1am Pacific would
> work very well for me too
>
> I actually did mean 2:00 am Pacific. I do work with our India team, so I
> am often up late to sync with them..
>
> > As discussed yesterday in the call, there are some other people who seem
> interested.
>
> What time zone are you in?
> I believe Ross is in England (UTC)
> I know that Randy is in Ottawa.
>
> If anyone else wants to join, that would be great!. They should ping us
> and I can send the Zoom link. I do not want to send that link blindly to
> the full mail list.
>

I'm in CEST (Central European zone). If we aim for the 3rd then let's stay
for late afternoon for me.

I let Ross, Randy and everyone else interested to express their preferences.


> > I'm going to add the missing file for the test next week, the tool needs
> a script to download 2023 data.
>
> That file is part of my code update, so you can get that for free.
>

Thanks!


David
>
> -Original Message-
> From: Marta Rybczynska 
> Sent: Wednesday, September 27, 2023 12:18 AM
> To: Reyna, David 
> Cc: yocto-secur...@lists.yoctoproject.org; OE-core <
> openembedded-core@lists.openembedded.org>;
> openembedded-architect...@lists.openembedded.org;
> yo...@lists.yoctoproject.org; MacLeod, Randy ;
> Richard Purdie ; Steve Sakoman <
> st...@sakoman.com>; Khem Raj ;
> mark.ha...@kernel.crashing.org; Ross Burton ; Joshua
> Watt 
> Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP
> needs
>
> Hi David,
> Thank you very much for the description and the offer to get a demo.
> As discussed yesterday in the call, there are some other people who
> seem interested.
>
> > PROPOSAL 1: If the full triage is too much to bite off to start with,
> perhaps using it to track and coordinate work will bring immediate benefit.
>
> This is the reason I want to test how much time it takes.
>
> > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully
> operational SRTool, so you can see all of the bells and whistles in action.
> I am available pretty much anytime between 10:00 am Pacific to 2:00 am
> Pacific.
>
> That would be nice. What about 11am Pacific on tomorrow (28 Sept or
> Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific
> would work very well for me too :P
>
> > PROPOSAL 3: I will start refreshing the YP SRTool repository with my
> current implementation level from Wind River (with the Wind River specific
> modules left out of course :-)
>
> That would be great. I'm going to add the missing file for the test
> next week, the tool needs a script to download 2023 data.
>
> Kind regards,
> Marta
>
> On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via
> lists.openembedded.org
>  wrote:
> >
> > Hi Marta,
> >
> > * SRTool: We might decide to use it again. It allows one to do much but
> requires constant commitment.
> >
> > There are many ways to use the SRTool.
> >   (a)  The original design was to perform 100% triage of incoming CVEs.
> This was a business requirement of Wind River, and we have used the SRTool
> successfully for 4-5 year now.
> >   (b)  The main limitation with the SRTool for Yocto Project was the
> lack of integration with Bugzilla (Ross ran out of time)
> >  * This is the crucial other half of the workflow
> >  * There is the automatic creation of appropriate defect records for
> investigation
> >  * There is also the automatic tracking of the overall CVE status,
> both CVEs in progress and the CVEs completed
> >  * Wind River has an extension for full integration with Jira, and
> that saves weeks of work for the CVE management
> >   (c) The guiding rule was that CVE management was in the SRTool, but
> specific defect work was also done in Jira/Bugzilla, for a clean separate
> of domains
> >   (d)  The SRTool has a user model
> >  * Together with Bugzilla, it is easy to track single people and
> even multiple people working on CVEs
> >   (e) The SRTool also has the built-on ability to look up the CVE status
> from other distributions (Red Hat, Debian, ...) so that one can get a peek
> of existing triages and resolutions
> >   (f) The SRTool is build like Toaster on top of Django, so development
> and debugging skills for Toaster immediate apply
> >   (g) Also with the Django base, it is very simple to add any number of
> modular extensions to support for example CVE Scanner integration
> >   (h) The SRTool also has report generation (in text, CSV, and Excel) in
> addition to email notification support.
> >   (i) There is also a "private" model for CVEs under embargo, with
> strict access control lists.
> >
> > PROPOSAL 1: If the full triage is too much to bite off to start with,
> perhaps using it to track and coordinate work will bring immediate benefit.
> >
> > 

[OE-core] [PATCH] devtool: modify: correctly handle multiple sources in SRC_URI

2023-09-27 Thread Julien Stephan
[YOCTO #15162]

When recipes such as bzip2 have several sources in SRC_URI, all the
sources are correctly extracted into devtool temporary workdir, but
currently, we only get back the primary source and all files declared
using "files://", then the devtool temporary workdir is deleted

Fix this by moving all remaining files from devtool temporary workdir
into actual WORKDIR (except "source-date-epoch", "recipe-sysroot",
and "recipe-sysroot-native") before deleting it

Here is the stack trace from devtool modify/build bzip2:

NOTE: bzip2: compiling from external source tree 
<...>/build/workspace/sources/bzip2
ERROR: bzip2-1.0.8-r0 do_install_ptest_base: 
ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368',
 1, None, None)
ERROR: Logfile of failure stored in: 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
Log data follows:
| DEBUG: Executing shell function do_install_ptest_base
| NOTE: make -j 16 
DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest
 install-ptest
| sed  -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
|../../../../../../workspace/sources/bzip2/Makefile.am  > 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
| cp ../../../../../../workspace/sources/bzip2/sample1.ref  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.ref  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.ref  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample1.bz2  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.bz2  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.bz2  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| ln -s /usr/bin/bzip2  
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
| cp: cannot stat 
'<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No 
such file or directory
| WARNING: 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189
 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
1.0.8/git/commons-compress 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
| WARNING: Backtrace (BB generated script):
|   #1: do_install_ptest, 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368,
 line 189
|   #2: do_install_ptest_base, 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368,
 line 158
|   #3: main, 
<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368,
 line 226
ERROR: Task 
(<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
  <...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base

Signed-off-by: Julien Stephan 
---
 scripts/lib/devtool/standard.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index d53fb810071..6c8ad7a6c8c 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -684,6 +684,14 @@ def _extract_source(srctree, keep_temp, devbranch, sync, 
config, basepath, works
 shutil.move(srcsubdir, srctree)
 symlink_oelocal_files_srctree(d,srctree)
 
+# In case SRC_URI contains multiple sources
+# they are extracted into the devtool temporary workdir
+# We need to move them into WORKDIR, otherwise they will be lost
+for path in os.listdir(os.path.join(tempdir, 'workdir')):
+if not path in ["source-date-epoch", "recipe-sysroot", 
"recipe-sysroot-native"]:
+workdir = d.getVar('WORKDIR')
+shutil.move(os.path.join(tempdir, 'workdir', path), 
workdir)
+
 if is_kernel_yocto:
 logger.info('Copying kernel config to srctree')
 shutil.copy2(os.path.join(tempdir, '.config'), srctree)
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188335): 
https://lists.openembedded.org/g/openembedded-core/message/188335
Mute This Topic: https://lists.openembedded.org/mt/101621289/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org

[OE-core] [dunfell][PATCH v4] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Colin McAllister
Add patch from libwebp 1.1.0 to fix CVE-2023-5129.

Signed-off-by: Colin McAllister 
---
 .../webp/files/CVE-2023-5129.patch| 364 ++
 meta/recipes-multimedia/webp/libwebp_1.1.0.bb |   1 +
 2 files changed, 365 insertions(+)
 create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch

diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
new file mode 100644
index 00..eb77e193c2
--- /dev/null
+++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
@@ -0,0 +1,364 @@
+From 12b11893edf6c201710ebeee7c84743a8573fad6 Mon Sep 17 00:00:00 2001
+From: Vincent Rabaud 
+Date: Thu, 7 Sep 2023 21:16:03 +0200
+Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
+
+First, BuildHuffmanTable is called to check if the data is valid.
+If it is and the table is not big enough, more memory is allocated.
+
+This will make sure that valid (but unoptimized because of unbalanced
+codes) streams are still decodable.
+
+Bug: chromium:1479274
+Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
+
+CVE: CVE-2023-5129
+Upstream-Status: Backport 
[https://github.com/webmproject/libwebp/commit/2af26267cdfcb63a88e5c74a85927a12d6ca1d76]
+Signed-off-by: Colin McAllister 
+---
+ src/dec/vp8l_dec.c| 46 ++-
+ src/dec/vp8li_dec.h   |  2 +-
+ src/utils/huffman_utils.c | 97 +++
+ src/utils/huffman_utils.h | 27 +--
+ 4 files changed, 129 insertions(+), 43 deletions(-)
+
+diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
+index 93615d4e..0d38314d 100644
+--- a/src/dec/vp8l_dec.c
 b/src/dec/vp8l_dec.c
+@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
+   int symbol;
+   int max_symbol;
+   int prev_code_len = DEFAULT_CODE_LENGTH;
+-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
++  HuffmanTables tables;
+ 
+-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
+- code_length_code_lengths,
+- NUM_CODE_LENGTH_CODES)) {
++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
++ code_length_code_lengths, 
NUM_CODE_LENGTH_CODES)) {
+ goto End;
+   }
+ 
+@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
+ int code_len;
+ if (max_symbol-- == 0) break;
+ VP8LFillBitWindow(br);
+-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
++p = _segment->start[VP8LPrefetchBits(br) & 
LENGTHS_TABLE_MASK];
+ VP8LSetBitPos(br, br->bit_pos_ + p->bits);
+ code_len = p->value;
+ if (code_len < kCodeLengthLiterals) {
+@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
+   ok = 1;
+ 
+  End:
++  VP8LHuffmanTablesDeallocate();
+   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
+   return ok;
+ }
+@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
+ // 'code_lengths' is pre-allocated temporary buffer, used for creating Huffman
+ // tree.
+ static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
+-   int* const code_lengths, HuffmanCode* const table) 
{
++   int* const code_lengths,
++   HuffmanTables* const table) {
+   int ok = 0;
+   int size = 0;
+   VP8LBitReader* const br = >br_;
+@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   VP8LMetadata* const hdr = >hdr_;
+   uint32_t* huffman_image = NULL;
+   HTreeGroup* htree_groups = NULL;
+-  HuffmanCode* huffman_tables = NULL;
+-  HuffmanCode* huffman_table = NULL;
++  HuffmanTables* huffman_tables = >huffman_tables_;
+   int num_htree_groups = 1;
+   int num_htree_groups_max = 1;
+   int max_alphabet_size = 0;
+@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   int* mapping = NULL;
+   int ok = 0;
+ 
++  // Check the table has been 0 initialized (through InitMetadata).
++  assert(huffman_tables->root.start == NULL);
++  assert(huffman_tables->curr_segment == NULL);
++
+   if (allow_recursion && VP8LReadBits(br, 1)) {
+ // use meta Huffman codes.
+ const int huffman_precision = VP8LReadBits(br, 3) + 2;
+@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+ 
+   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
+   sizeof(*code_lengths));
+-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * table_size,
+-sizeof(*huffman_tables));
+   htree_groups = VP8LHtreeGroupsNew(num_htree_groups);
+ 
+-  if (htree_groups == NULL || code_lengths == NULL || huffman_tables == NULL) 
{
++  if (htree_groups == NULL || code_lengths == NULL ||
++  !VP8LHuffmanTablesAllocate(num_htree_groups * table_size,
++ huffman_tables)) {
+ dec->status_ = 

[OE-core] [mickledore][PATCH v2] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Colin McAllister
Add patch for Libwebp 1.3.1 to fix CVE-2023-5129.

Signed-off-by: Colin McAllister 
---
 .../webp/files/CVE-2023-5129.patch| 364 ++
 meta/recipes-multimedia/webp/libwebp_1.3.1.bb |   4 +-
 2 files changed, 367 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch

diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
new file mode 100644
index 00..b246ed42f9
--- /dev/null
+++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
@@ -0,0 +1,364 @@
+From 6c928321f47ba69022cd4d814433f365dea63478 Mon Sep 17 00:00:00 2001
+From: Vincent Rabaud 
+Date: Thu, 7 Sep 2023 21:16:03 +0200
+Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
+
+First, BuildHuffmanTable is called to check if the data is valid.
+If it is and the table is not big enough, more memory is allocated.
+
+This will make sure that valid (but unoptimized because of unbalanced
+codes) streams are still decodable.
+
+Bug: chromium:1479274
+Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
+
+CVE: CVE-2023-5129
+Upstream-Status: Backport 
[https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a]
+Signed-off-by: Colin McAllister 
+---
+ src/dec/vp8l_dec.c| 46 ++-
+ src/dec/vp8li_dec.h   |  2 +-
+ src/utils/huffman_utils.c | 97 +++
+ src/utils/huffman_utils.h | 27 +--
+ 4 files changed, 129 insertions(+), 43 deletions(-)
+
+diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
+index c0ea0181..7995313f 100644
+--- a/src/dec/vp8l_dec.c
 b/src/dec/vp8l_dec.c
+@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
+   int symbol;
+   int max_symbol;
+   int prev_code_len = DEFAULT_CODE_LENGTH;
+-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
++  HuffmanTables tables;
+ 
+-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
+- code_length_code_lengths,
+- NUM_CODE_LENGTH_CODES)) {
++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
++ code_length_code_lengths, 
NUM_CODE_LENGTH_CODES)) {
+ goto End;
+   }
+ 
+@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
+ int code_len;
+ if (max_symbol-- == 0) break;
+ VP8LFillBitWindow(br);
+-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
++p = _segment->start[VP8LPrefetchBits(br) & 
LENGTHS_TABLE_MASK];
+ VP8LSetBitPos(br, br->bit_pos_ + p->bits);
+ code_len = p->value;
+ if (code_len < kCodeLengthLiterals) {
+@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
+   ok = 1;
+ 
+  End:
++  VP8LHuffmanTablesDeallocate();
+   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
+   return ok;
+ }
+@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
+ // 'code_lengths' is pre-allocated temporary buffer, used for creating Huffman
+ // tree.
+ static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
+-   int* const code_lengths, HuffmanCode* const table) 
{
++   int* const code_lengths,
++   HuffmanTables* const table) {
+   int ok = 0;
+   int size = 0;
+   VP8LBitReader* const br = >br_;
+@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   VP8LMetadata* const hdr = >hdr_;
+   uint32_t* huffman_image = NULL;
+   HTreeGroup* htree_groups = NULL;
+-  HuffmanCode* huffman_tables = NULL;
+-  HuffmanCode* huffman_table = NULL;
++  HuffmanTables* huffman_tables = >huffman_tables_;
+   int num_htree_groups = 1;
+   int num_htree_groups_max = 1;
+   int max_alphabet_size = 0;
+@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   int* mapping = NULL;
+   int ok = 0;
+ 
++  // Check the table has been 0 initialized (through InitMetadata).
++  assert(huffman_tables->root.start == NULL);
++  assert(huffman_tables->curr_segment == NULL);
++
+   if (allow_recursion && VP8LReadBits(br, 1)) {
+ // use meta Huffman codes.
+ const int huffman_precision = VP8LReadBits(br, 3) + 2;
+@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+ 
+   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
+   sizeof(*code_lengths));
+-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * table_size,
+-sizeof(*huffman_tables));
+   htree_groups = VP8LHtreeGroupsNew(num_htree_groups);
+ 
+-  if (htree_groups == NULL || code_lengths == NULL || huffman_tables == NULL) 
{
++  if (htree_groups == NULL || code_lengths == NULL ||
++  !VP8LHuffmanTablesAllocate(num_htree_groups * table_size,
++ huffman_tables)) {
+ 

[OE-core] [kirkstone][PATCH v4] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Colin McAllister
Add patch from libwebp 1.2.4 to fix CVE-2023-5129

Signed-off-by: Colin McAllister 
---
 .../webp/files/CVE-2023-5129.patch| 364 ++
 meta/recipes-multimedia/webp/libwebp_1.2.4.bb |   1 +
 2 files changed, 365 insertions(+)
 create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch

diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
new file mode 100644
index 00..356806ad87
--- /dev/null
+++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
@@ -0,0 +1,364 @@
+From 383b8b4eb6780d855e8a8177fbce96ab39dba6a5 Mon Sep 17 00:00:00 2001
+From: Vincent Rabaud 
+Date: Thu, 7 Sep 2023 21:16:03 +0200
+Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
+
+First, BuildHuffmanTable is called to check if the data is valid.
+If it is and the table is not big enough, more memory is allocated.
+
+This will make sure that valid (but unoptimized because of unbalanced
+codes) streams are still decodable.
+
+Bug: chromium:1479274
+Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
+
+CVE: CVE-2023-5129
+Upstream-Status: Backport 
[https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a]
+Signed-off-by: Colin McAllister 
+---
+ src/dec/vp8l_dec.c| 46 ++-
+ src/dec/vp8li_dec.h   |  2 +-
+ src/utils/huffman_utils.c | 97 +++
+ src/utils/huffman_utils.h | 27 +--
+ 4 files changed, 129 insertions(+), 43 deletions(-)
+
+diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
+index 13480551..186b0b2f 100644
+--- a/src/dec/vp8l_dec.c
 b/src/dec/vp8l_dec.c
+@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
+   int symbol;
+   int max_symbol;
+   int prev_code_len = DEFAULT_CODE_LENGTH;
+-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
++  HuffmanTables tables;
+ 
+-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
+- code_length_code_lengths,
+- NUM_CODE_LENGTH_CODES)) {
++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
++ code_length_code_lengths, 
NUM_CODE_LENGTH_CODES)) {
+ goto End;
+   }
+ 
+@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
+ int code_len;
+ if (max_symbol-- == 0) break;
+ VP8LFillBitWindow(br);
+-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
++p = _segment->start[VP8LPrefetchBits(br) & 
LENGTHS_TABLE_MASK];
+ VP8LSetBitPos(br, br->bit_pos_ + p->bits);
+ code_len = p->value;
+ if (code_len < kCodeLengthLiterals) {
+@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
+   ok = 1;
+ 
+  End:
++  VP8LHuffmanTablesDeallocate();
+   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
+   return ok;
+ }
+@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
+ // 'code_lengths' is pre-allocated temporary buffer, used for creating Huffman
+ // tree.
+ static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
+-   int* const code_lengths, HuffmanCode* const table) 
{
++   int* const code_lengths,
++   HuffmanTables* const table) {
+   int ok = 0;
+   int size = 0;
+   VP8LBitReader* const br = >br_;
+@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   VP8LMetadata* const hdr = >hdr_;
+   uint32_t* huffman_image = NULL;
+   HTreeGroup* htree_groups = NULL;
+-  HuffmanCode* huffman_tables = NULL;
+-  HuffmanCode* huffman_table = NULL;
++  HuffmanTables* huffman_tables = >huffman_tables_;
+   int num_htree_groups = 1;
+   int num_htree_groups_max = 1;
+   int max_alphabet_size = 0;
+@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+   int* mapping = NULL;
+   int ok = 0;
+ 
++  // Check the table has been 0 initialized (through InitMetadata).
++  assert(huffman_tables->root.start == NULL);
++  assert(huffman_tables->curr_segment == NULL);
++
+   if (allow_recursion && VP8LReadBits(br, 1)) {
+ // use meta Huffman codes.
+ const int huffman_precision = VP8LReadBits(br, 3) + 2;
+@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
xsize, int ysize,
+ 
+   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
+   sizeof(*code_lengths));
+-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * table_size,
+-sizeof(*huffman_tables));
+   htree_groups = VP8LHtreeGroupsNew(num_htree_groups);
+ 
+-  if (htree_groups == NULL || code_lengths == NULL || huffman_tables == NULL) 
{
++  if (htree_groups == NULL || code_lengths == NULL ||
++  !VP8LHuffmanTablesAllocate(num_htree_groups * table_size,
++ huffman_tables)) {
+ dec->status_ = 

Re: [OE-core] [langdale][kirkstone][PATCH] go-mod.bbclass: Allow network in do_compile

2023-09-27 Thread Bruce Ashfield
On Wed, Sep 27, 2023 at 9:34 AM Lukas Funke 
wrote:

> On 10.09.2023 23:26, Martin Jansa wrote:
> > On Sun, Mar 12, 2023 at 10:15 AM Martin Jansa via lists.openembedded.org
> >  wrote:
> >
> >> On Tue, Jan 3, 2023 at 5:03 PM Lukas Funke <
> >> lukas.funke-...@weidmueller.com> wrote:
> >>
> >>> Martin,
> >>>
> >>> first of all: thank you for testing the patches. As usual the corner
> >>> cases are the most tricky ones.
> >>>
> >>> tl;dr: I'm working on an updated patch series to address the reported
> >>> issues.
> >>>
> >>
> >> Hi Lukas, Stefan,
> >>
> >> and update on this series?
> >>
> >> It doesn't have to be perfect, other people can help with remaining
> corner
> >> cases and right now there is nothing for this in oe-core, so any version
> >> will be big improvement :) and it will make it easier for others to
> submit
> >> incremental improvements - I have some as well, but haven't sent them
> as I
> >> don't know what you've already updated locally, so I'm waiting for v2.
> >>
> >> Mickledore is already in feature freeze, but maybe RP will make an
> >> exception as this is new important functionality which isn't likely to
> >> break other existing code.
> >>
> >
> > Hello Lukas,
> >
> > any progress on updated patch series? Nanbield release is near and I
> don't
> > remember seeing the updated patch series in last couple months.
> >
> > Is there anything I can do to help? The last version looked reasonably
> well
> > and IMHO could be used as starting point for everybody to help fixing
> those
> > corner cases where it didn't work well.
> >
> > Regards,
>
> Hello Martin,
>
> I'm currently working on an update, but can't make any promises
> regarding the timeline.
>

Just FYI: on meta-virt master there is a reworked script that is used to
update the .inc files for go projects in the layer.

It might be helpful, it might not be!

Bruce




>
> Thanks for offering help! Reviewing and testing is always helpful when
> the updated series is on it's way.
>
> Regards
> Lukas
>
>
> >
> >
> >> Kind Regards,
> >>
> >>
> >> I've looked into the issues and would like to give some explanation.
> >>>
> >>> 1) the first module you mention ('gonum.org/v1/gonum
> >>> ') does not obey the go documentation for
> >>> resolving the modules source-code repository (see
> >>> https://go.dev/ref/mod#go-mod-download , Section 'Version control
> >>> systems'). The documentation states that there should be a html page,
> >>> queried by "?go-get=1", with a -tag which contains the original
> >>> URL to the source-code repository. For 'gonum' there is only a
> 404-page.
> >>> This page contains javascript-code that redirects to the actual gonum
> >>> package page. Unnecessary hard to process. I'll open an issue for that.
> >>> The second module 'code.cloudfoundry.org/clock
> >>> ' has a broken certificate. I
> >>> already opend an issue on github for this.
> >>>
> >>> I addressed this issue above by maintaining a list of modules and their
> >>> actual repo URLs inside the go-recipetool as an absolute fallback.
> Would
> >>> do you think about this solution?
> >>>
> >>
> >> Yes, that's what I was starting to do in:
> >>
> >>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=b973c7f17c8a613233a1a18de0bf6daa352c47d8
> >>
> >>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=61c6c9962b3b7d4c1cf6e6823de6c32b09998b00
> >>
> >>
> >>> 2) yes, my bad :)
> >>>
> >>
> >> as work around I was using
> >>
> >>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=5767819bfe96de29ab751d4a37a431a324f7e547
> >>
> >>
> >> 3) The problem is that some repositories have a prefix in their tags.
> >>> The tags usually only contain the semantic version string. I'm curretly
> >>> working on this issue.
> >>>
> >>> Best regards
> >>>
> >>> Lukas
> >>>
> >>> Am 22.12.2022 um 20:08 schrieb Martin Jansa via lists.openembedded.org
> :
>  On Thu, Dec 22, 2022 at 7:39 PM Vyacheslav Yurkov  >
>  wrote:
> 
>   On 22.12.2022 17:48, Bruce Ashfield wrote:
>   > On Thu, Dec 22, 2022 at 11:20 AM Richard Purdie
>   >  wrote:
>   >> This patch is not in master and is not a backport therefore
> not
>   >> eligible for kirkstone/langdale.
> 
>   My bad, the intention was to have it in all three branches:
> master,
>   kirkstone, and langdale.
> 
>   > 'nor should it go to master.
>   >
>   > If someone wants to allow go to fetch sources during builds, it
>   needs
>   > to be done in their own layers.
>   >
>   > Bruce
> 
>   Probably I misunderstood the outcome of the discussion in my
> first
>   link.
>   Bruce and Richard, you both suggested to have it in go-mod with
> the
>   warning. I agree that it breaks reproducibility, and is
> considered
>   a bad
>  

[OE-core][dunfell][PATCH] mdadm: Backport fix for CVE-2023-28736

2023-09-27 Thread Ashish Sharma via lists.openembedded.org
Signed-off-by: Ashish Sharma 
---
 .../mdadm/files/CVE-2023-28736.patch  | 77 +++
 meta/recipes-extended/mdadm/mdadm_4.1.bb  |  1 +
 2 files changed, 78 insertions(+)
 create mode 100644 meta/recipes-extended/mdadm/files/CVE-2023-28736.patch

diff --git a/meta/recipes-extended/mdadm/files/CVE-2023-28736.patch 
b/meta/recipes-extended/mdadm/files/CVE-2023-28736.patch
new file mode 100644
index 000..8e0a06cbc7b
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/CVE-2023-28736.patch
@@ -0,0 +1,77 @@
+From ced5fa8b170ad448f4076e24a10c731b5cfb36ce Mon Sep 17 00:00:00 2001
+From: Blazej Kucman 
+Date: Fri, 3 Dec 2021 15:31:15 +0100
+Subject: mdadm: block creation with long names
+
+This fixes buffer overflows in create_mddev(). It prohibits
+creation with not supported names for DDF and native. For IMSM,
+mdadm will do silent cut to 16 later.
+
+Signed-off-by: Mariusz Tkaczyk 
+Signed-off-by: Blazej Kucman 
+Signed-off-by: Jes Sorensen 
+---
+
+Upstream-Status: Backport from 
[https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/patch/?id=ced5fa8b170ad448f4076e24a10c731b5cfb36ce]
+CVE: CVE-2023-28736
+Signed-off-by: Ashish Sharma 
+
+ mdadm.8.in | 5 +
+ mdadm.c| 9 -
+ mdadm.h| 5 +
+ 3 files changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/mdadm.8.in b/mdadm.8.in
+index 28d773c2..68e100cb 100644
+--- a/mdadm.8.in
 b/mdadm.8.in
+@@ -2186,6 +2186,11 @@ is run, but will be created by
+ .I udev
+ once the array becomes active.
+ 
++The max length md-device name is limited to 32 characters.
++Different metadata types have more strict limitation
++(like IMSM where only 16 characters are allowed).
++For that reason, long name could be truncated or rejected, it depends on 
metadata policy.
++
+ As devices are added, they are checked to see if they contain RAID
+ superblocks or filesystems.  They are also checked to see if the variance in
+ device size exceeds 1%.
+diff --git a/mdadm.c b/mdadm.c
+index 91e67467..26299b2e 100644
+--- a/mdadm.c
 b/mdadm.c
+@@ -1359,9 +1359,16 @@ int main(int argc, char *argv[])
+   mdfd = open_mddev(devlist->devname, 1);
+   if (mdfd < 0)
+   exit(1);
+-  } else
++  } else {
++  char *bname = basename(devlist->devname);
++
++  if (strlen(bname) > MD_NAME_MAX) {
++  pr_err("Name %s is too long.\n", 
devlist->devname);
++  exit(1);
++  }
+   /* non-existent device is OK */
+   mdfd = open_mddev(devlist->devname, 0);
++  }
+   if (mdfd == -2) {
+   pr_err("device %s exists but is not an md array.\n", 
devlist->devname);
+   exit(1);
+diff --git a/mdadm.h b/mdadm.h
+index 54567396..c7268a71 100644
+--- a/mdadm.h
 b/mdadm.h
+@@ -1880,3 +1880,8 @@ enum r0layout {
+ #define INVALID_SECTORS 1
+ /* And another special number needed for --data_offset=variable */
+ #define VARIABLE_OFFSET 3
++
++/**
++ * This is true for native and DDF, IMSM allows 16.
++ */
++#define MD_NAME_MAX 32
+-- 
+cgit 
+
diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb 
b/meta/recipes-extended/mdadm/mdadm_4.1.bb
index bb77759cf97..5238a41df20 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
@@ -24,6 +24,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \

file://0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch \
file://include_sysmacros.patch \
file://0001-mdadm-skip-test-11spare-migration.patch \
+   file://CVE-2023-28736.patch \
"
 
 SRC_URI[md5sum] = "51bf3651bd73a06c413a2f964f299598"
-- 
2.24.4


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188330): 
https://lists.openembedded.org/g/openembedded-core/message/188330
Mute This Topic: https://lists.openembedded.org/mt/101618300/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] kernel-fitImage: Strip path component from dtb

2023-09-27 Thread Ninad Palsule
Machines that have added subdirectires to the KERNEL_DEVICETREE
recently, such as arm32 boards that were moved under subdirectories in
Linux 6.5, will have that subdirectory in the node name of the FIT. This
breaks existing systems that select a configuration in u-boot by it's
name.

Strip off the directory component from the device tree to preserve
compatibility.

Signed-off-by: Joel Stanley 
Signed-off-by: Ninad Palsule 
---
 meta/classes-recipe/kernel-fitimage.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass
index 13e8947f09..7e30a5d47e 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -599,6 +599,11 @@ fitimage_assemble() {
DTB_PATH="${KERNEL_OUTPUT_DIR}/$DTB"
fi
 
+   # Strip off the path component from the filename
+   if "${@'false' if 
oe.types.boolean(d.getVar('KERNEL_DTBVENDORED')) else 'true'}"; then
+   DTB=`basename $DTB`
+   fi
+
# Set the default dtb image if it exists in the 
devicetree.
if [ ${FIT_CONF_DEFAULT_DTB} = $DTB ];then
default_dtb_image=$(echo "$DTB" | tr '/' '_')
-- 
2.39.2


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



Re: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 2.35 branch

2023-09-27 Thread Peter Marko via lists.openembedded.org
-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Peter Marko via 
lists.openembedded.org
Sent: Wednesday, September 27, 2023 16:21
To: soumya.sa...@windriver.com
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 
2.35 branch

> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Soumya via 
> lists.openembedded.org
> Sent: Wednesday, September 27, 2023 9:46
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 
> 2.35 branch
>
> > From: Soumya Sambu 
> >
> > Adresses CVE-2023-4813, CVE-2023-4806
>
> Could you also add these to CVE_CHECK_IGNORE?
> Otherwise they will stay in cve-check reports since the recipe version did 
> not change.

Additionally, this fixes CVE-2023-5156

>
> Thanks,
> Peter

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



Re: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 2.35 branch

2023-09-27 Thread Soumya via lists.openembedded.org
Sure, will send v2.

Regards,
Soumya


From: Marko, Peter 
Sent: Wednesday, September 27, 2023 7:50 PM
To: Sambu, Soumya 
Cc: openembedded-core@lists.openembedded.org 

Subject: RE: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 
2.35 branch

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Soumya via 
lists.openembedded.org
Sent: Wednesday, September 27, 2023 9:46
To: openembedded-core@lists.openembedded.org
Subject: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 2.35 
branch

> From: Soumya Sambu 
>
> Adresses CVE-2023-4813, CVE-2023-4806

Could you also add these to CVE_CHECK_IGNORE?
Otherwise they will stay in cve-check reports since the recipe version did not 
change.

Thanks,
Peter

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



Re: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 2.35 branch

2023-09-27 Thread Peter Marko via lists.openembedded.org
-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Soumya via 
lists.openembedded.org
Sent: Wednesday, September 27, 2023 9:46
To: openembedded-core@lists.openembedded.org
Subject: [OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 2.35 
branch

> From: Soumya Sambu 
>
> Adresses CVE-2023-4813, CVE-2023-4806

Could you also add these to CVE_CHECK_IGNORE?
Otherwise they will stay in cve-check reports since the recipe version did not 
change.

Thanks,
Peter

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



Re: [OE-core] [PATCH 1/2] distcc: Fix groupname gid change warning

2023-09-27 Thread Richard Purdie
On Wed, 2023-09-27 at 06:07 -0700, JD Schroeder wrote:
> On Tue, Sep 12, 2023 at 06:03 AM, Ross Burton wrote:
> > On 1 Sep 2023, at 11:03, Alexandre Belloni via
> > lists.openembedded.org
> >  wrote:
> > > 
> > > Hello,
> > > 
> > > This fails on the autobuilders:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3449/steps/12/logs/stdio
> > > 
> > > ERROR: Nothing RPROVIDES 'distcc' (but /home/pokybuild/yocto-
> > > worker/reproducible/build/meta/recipes-
> > > core/packagegroups/packagegroup-self-hosted.bb,
> > > /home/pokybuild/yocto-worker/reproducible/build/meta/recipes-
> > > devtools/devel-config/distcc-config.bb RDEPENDS on or otherwise
> > > requires it)
> > > distcc was skipped: Recipe distcc, package distcc-server: system
> > > groupname "nogroup" does not have a static ID defined. Add
> > > nogroup to one of these files: /home/pokybuild/yocto-
> > > worker/reproducible/build/build-st/meta-selftest/files/static-
> > > group
> > The same problem would hit the ppp-dialin but that recipe doesn’t
> > get built in the AB in an environment that has static IPs.
> > 
> > Ross
> I'm seeing the the warnings being generated in a multi-config Yocto
> build environment. Is there another way to address and fix the
> warnings I am having with the distcc and ppp-dialin recipes (possibly
> during parsing) even if they aren't being built in the AB with static
> IPs?

It might help if you could describe how to reproduce the problem you're
seeing?

"nogroup" should already exist in the underlying base-passwd file so we
really need to understand why that isn't working. The patch appears
just to mask the real problem.

Cheers,

Richard

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



Re: [OE-core] [dunfell][PATCH v3] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Steve Sakoman
On Tue, Sep 26, 2023 at 2:22 PM Colin McAllister  wrote:
>
> Add patch from libwebp 1.1.0 to fix CVE-2023-5129.
>
> Signed-off-by: Colin McAllister 
> ---
>  .../webp/files/CVE-2023-5129.patch| 364 ++
>  meta/recipes-multimedia/webp/libwebp_1.1.0.bb |   1 +
>  2 files changed, 365 insertions(+)
>  create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
>
> diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
> b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
> new file mode 100644
> index 00..49eca4de5e
> --- /dev/null
> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
> @@ -0,0 +1,364 @@
> +From 12b11893edf6c201710ebeee7c84743a8573fad6 Mon Sep 17 00:00:00 2001
> +From: Vincent Rabaud 
> +Date: Thu, 7 Sep 2023 21:16:03 +0200
> +Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
> +
> +First, BuildHuffmanTable is called to check if the data is valid.
> +If it is and the table is not big enough, more memory is allocated.
> +
> +This will make sure that valid (but unoptimized because of unbalanced
> +codes) streams are still decodable.
> +
> +Bug: chromium:1479274
> +Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
> +
> +CVE: CVE-2023-5129
> +
> +Upstream-Status: Backport 
> [https://github.com/webmproject/libwebp/commit/2af26267cdfcb63a88e5c74a85927a12d6ca1d76]

Also missing Signed-off-by:

Thanks!

Steve

> +---
> + src/dec/vp8l_dec.c| 46 ++-
> + src/dec/vp8li_dec.h   |  2 +-
> + src/utils/huffman_utils.c | 97 +++
> + src/utils/huffman_utils.h | 27 +--
> + 4 files changed, 129 insertions(+), 43 deletions(-)
> +
> +diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
> +index 93615d4e..0d38314d 100644
> +--- a/src/dec/vp8l_dec.c
>  b/src/dec/vp8l_dec.c
> +@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
> +   int symbol;
> +   int max_symbol;
> +   int prev_code_len = DEFAULT_CODE_LENGTH;
> +-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
> ++  HuffmanTables tables;
> +
> +-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
> +- code_length_code_lengths,
> +- NUM_CODE_LENGTH_CODES)) {
> ++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
> ++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
> ++ code_length_code_lengths, 
> NUM_CODE_LENGTH_CODES)) {
> + goto End;
> +   }
> +
> +@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
> + int code_len;
> + if (max_symbol-- == 0) break;
> + VP8LFillBitWindow(br);
> +-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
> ++p = _segment->start[VP8LPrefetchBits(br) & 
> LENGTHS_TABLE_MASK];
> + VP8LSetBitPos(br, br->bit_pos_ + p->bits);
> + code_len = p->value;
> + if (code_len < kCodeLengthLiterals) {
> +@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
> +   ok = 1;
> +
> +  End:
> ++  VP8LHuffmanTablesDeallocate();
> +   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
> +   return ok;
> + }
> +@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
> + // 'code_lengths' is pre-allocated temporary buffer, used for creating 
> Huffman
> + // tree.
> + static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
> +-   int* const code_lengths, HuffmanCode* const 
> table) {
> ++   int* const code_lengths,
> ++   HuffmanTables* const table) {
> +   int ok = 0;
> +   int size = 0;
> +   VP8LBitReader* const br = >br_;
> +@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
> xsize, int ysize,
> +   VP8LMetadata* const hdr = >hdr_;
> +   uint32_t* huffman_image = NULL;
> +   HTreeGroup* htree_groups = NULL;
> +-  HuffmanCode* huffman_tables = NULL;
> +-  HuffmanCode* huffman_table = NULL;
> ++  HuffmanTables* huffman_tables = >huffman_tables_;
> +   int num_htree_groups = 1;
> +   int num_htree_groups_max = 1;
> +   int max_alphabet_size = 0;
> +@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
> xsize, int ysize,
> +   int* mapping = NULL;
> +   int ok = 0;
> +
> ++  // Check the table has been 0 initialized (through InitMetadata).
> ++  assert(huffman_tables->root.start == NULL);
> ++  assert(huffman_tables->curr_segment == NULL);
> ++
> +   if (allow_recursion && VP8LReadBits(br, 1)) {
> + // use meta Huffman codes.
> + const int huffman_precision = VP8LReadBits(br, 3) + 2;
> +@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, 
> int xsize, int ysize,
> +
> +   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
> +   sizeof(*code_lengths));
> +-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * 
> table_size,
> +-sizeof(*huffman_tables));
> +   htree_groups = 

Re: [OE-core] [mickledore][PATCH] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Steve Sakoman
On Tue, Sep 26, 2023 at 1:46 PM Colin McAllister  wrote:
>
> Add patch for Libwebp 1.3.1 to fix CVE-2023-5129.
>
> Signed-off-by: Colin McAllister 
> ---
>  .../webp/files/CVE-2023-5129.patch| 364 ++
>  meta/recipes-multimedia/webp/libwebp_1.3.1.bb |   4 +-
>  2 files changed, 367 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
>
> diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
> b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
> new file mode 100644
> index 00..930b2ae459
> --- /dev/null
> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
> @@ -0,0 +1,364 @@
> +From 6c928321f47ba69022cd4d814433f365dea63478 Mon Sep 17 00:00:00 2001
> +From: Vincent Rabaud 
> +Date: Thu, 7 Sep 2023 21:16:03 +0200
> +Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
> +
> +First, BuildHuffmanTable is called to check if the data is valid.
> +If it is and the table is not big enough, more memory is allocated.
> +
> +This will make sure that valid (but unoptimized because of unbalanced
> +codes) streams are still decodable.
> +
> +Bug: chromium:1479274
> +Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
> +
> +CVE: CVE-2023-5129
> +
> +Upstream-Status: Backport 
> [https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a]

Same issue here, missing your Signed-off-by:

Please send a V2

Thanks!

Steve

> +---
> + src/dec/vp8l_dec.c| 46 ++-
> + src/dec/vp8li_dec.h   |  2 +-
> + src/utils/huffman_utils.c | 97 +++
> + src/utils/huffman_utils.h | 27 +--
> + 4 files changed, 129 insertions(+), 43 deletions(-)
> +
> +diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
> +index c0ea0181..7995313f 100644
> +--- a/src/dec/vp8l_dec.c
>  b/src/dec/vp8l_dec.c
> +@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
> +   int symbol;
> +   int max_symbol;
> +   int prev_code_len = DEFAULT_CODE_LENGTH;
> +-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
> ++  HuffmanTables tables;
> +
> +-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
> +- code_length_code_lengths,
> +- NUM_CODE_LENGTH_CODES)) {
> ++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
> ++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
> ++ code_length_code_lengths, 
> NUM_CODE_LENGTH_CODES)) {
> + goto End;
> +   }
> +
> +@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
> + int code_len;
> + if (max_symbol-- == 0) break;
> + VP8LFillBitWindow(br);
> +-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
> ++p = _segment->start[VP8LPrefetchBits(br) & 
> LENGTHS_TABLE_MASK];
> + VP8LSetBitPos(br, br->bit_pos_ + p->bits);
> + code_len = p->value;
> + if (code_len < kCodeLengthLiterals) {
> +@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
> +   ok = 1;
> +
> +  End:
> ++  VP8LHuffmanTablesDeallocate();
> +   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
> +   return ok;
> + }
> +@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
> + // 'code_lengths' is pre-allocated temporary buffer, used for creating 
> Huffman
> + // tree.
> + static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
> +-   int* const code_lengths, HuffmanCode* const 
> table) {
> ++   int* const code_lengths,
> ++   HuffmanTables* const table) {
> +   int ok = 0;
> +   int size = 0;
> +   VP8LBitReader* const br = >br_;
> +@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
> xsize, int ysize,
> +   VP8LMetadata* const hdr = >hdr_;
> +   uint32_t* huffman_image = NULL;
> +   HTreeGroup* htree_groups = NULL;
> +-  HuffmanCode* huffman_tables = NULL;
> +-  HuffmanCode* huffman_table = NULL;
> ++  HuffmanTables* huffman_tables = >huffman_tables_;
> +   int num_htree_groups = 1;
> +   int num_htree_groups_max = 1;
> +   int max_alphabet_size = 0;
> +@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
> xsize, int ysize,
> +   int* mapping = NULL;
> +   int ok = 0;
> +
> ++  // Check the table has been 0 initialized (through InitMetadata).
> ++  assert(huffman_tables->root.start == NULL);
> ++  assert(huffman_tables->curr_segment == NULL);
> ++
> +   if (allow_recursion && VP8LReadBits(br, 1)) {
> + // use meta Huffman codes.
> + const int huffman_precision = VP8LReadBits(br, 3) + 2;
> +@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, 
> int xsize, int ysize,
> +
> +   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
> +   sizeof(*code_lengths));
> +-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * 
> table_size,
> +-

Re: [OE-core] [kirkstone][PATCH v3] libwebp: Fix CVE-2023-5129

2023-09-27 Thread Steve Sakoman
On Tue, Sep 26, 2023 at 2:25 PM Colin McAllister  wrote:
>
> Add patch from libwebp 1.2.4 to fix CVE-2023-5129
>
> Signed-off-by: Colin McAllister 
> ---
>  .../webp/files/CVE-2023-5129.patch| 364 ++
>  meta/recipes-multimedia/webp/libwebp_1.2.4.bb |   1 +
>  2 files changed, 365 insertions(+)
>  create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
>
> diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
> b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
> new file mode 100644
> index 00..401fa370d4
> --- /dev/null
> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
> @@ -0,0 +1,364 @@
> +From 383b8b4eb6780d855e8a8177fbce96ab39dba6a5 Mon Sep 17 00:00:00 2001
> +From: Vincent Rabaud 
> +Date: Thu, 7 Sep 2023 21:16:03 +0200
> +Subject: [PATCH 1/1] Fix OOB write in BuildHuffmanTable.
> +
> +First, BuildHuffmanTable is called to check if the data is valid.
> +If it is and the table is not big enough, more memory is allocated.
> +
> +This will make sure that valid (but unoptimized because of unbalanced
> +codes) streams are still decodable.
> +
> +Bug: chromium:1479274
> +Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
> +
> +CVE: CVE-2023-5129
> +
> +Upstream-Status: Backport 
> [https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a]

Missing your Signed-off-by: here in the patch file.

Please send a V4, sorry!

Steve

> +---
> + src/dec/vp8l_dec.c| 46 ++-
> + src/dec/vp8li_dec.h   |  2 +-
> + src/utils/huffman_utils.c | 97 +++
> + src/utils/huffman_utils.h | 27 +--
> + 4 files changed, 129 insertions(+), 43 deletions(-)
> +
> +diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
> +index 13480551..186b0b2f 100644
> +--- a/src/dec/vp8l_dec.c
>  b/src/dec/vp8l_dec.c
> +@@ -253,11 +253,11 @@ static int ReadHuffmanCodeLengths(
> +   int symbol;
> +   int max_symbol;
> +   int prev_code_len = DEFAULT_CODE_LENGTH;
> +-  HuffmanCode table[1 << LENGTHS_TABLE_BITS];
> ++  HuffmanTables tables;
> +
> +-  if (!VP8LBuildHuffmanTable(table, LENGTHS_TABLE_BITS,
> +- code_length_code_lengths,
> +- NUM_CODE_LENGTH_CODES)) {
> ++  if (!VP8LHuffmanTablesAllocate(1 << LENGTHS_TABLE_BITS, ) ||
> ++  !VP8LBuildHuffmanTable(, LENGTHS_TABLE_BITS,
> ++ code_length_code_lengths, 
> NUM_CODE_LENGTH_CODES)) {
> + goto End;
> +   }
> +
> +@@ -277,7 +277,7 @@ static int ReadHuffmanCodeLengths(
> + int code_len;
> + if (max_symbol-- == 0) break;
> + VP8LFillBitWindow(br);
> +-p = [VP8LPrefetchBits(br) & LENGTHS_TABLE_MASK];
> ++p = _segment->start[VP8LPrefetchBits(br) & 
> LENGTHS_TABLE_MASK];
> + VP8LSetBitPos(br, br->bit_pos_ + p->bits);
> + code_len = p->value;
> + if (code_len < kCodeLengthLiterals) {
> +@@ -300,6 +300,7 @@ static int ReadHuffmanCodeLengths(
> +   ok = 1;
> +
> +  End:
> ++  VP8LHuffmanTablesDeallocate();
> +   if (!ok) dec->status_ = VP8_STATUS_BITSTREAM_ERROR;
> +   return ok;
> + }
> +@@ -307,7 +308,8 @@ static int ReadHuffmanCodeLengths(
> + // 'code_lengths' is pre-allocated temporary buffer, used for creating 
> Huffman
> + // tree.
> + static int ReadHuffmanCode(int alphabet_size, VP8LDecoder* const dec,
> +-   int* const code_lengths, HuffmanCode* const 
> table) {
> ++   int* const code_lengths,
> ++   HuffmanTables* const table) {
> +   int ok = 0;
> +   int size = 0;
> +   VP8LBitReader* const br = >br_;
> +@@ -362,8 +364,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
> xsize, int ysize,
> +   VP8LMetadata* const hdr = >hdr_;
> +   uint32_t* huffman_image = NULL;
> +   HTreeGroup* htree_groups = NULL;
> +-  HuffmanCode* huffman_tables = NULL;
> +-  HuffmanCode* huffman_table = NULL;
> ++  HuffmanTables* huffman_tables = >huffman_tables_;
> +   int num_htree_groups = 1;
> +   int num_htree_groups_max = 1;
> +   int max_alphabet_size = 0;
> +@@ -372,6 +373,10 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int 
> xsize, int ysize,
> +   int* mapping = NULL;
> +   int ok = 0;
> +
> ++  // Check the table has been 0 initialized (through InitMetadata).
> ++  assert(huffman_tables->root.start == NULL);
> ++  assert(huffman_tables->curr_segment == NULL);
> ++
> +   if (allow_recursion && VP8LReadBits(br, 1)) {
> + // use meta Huffman codes.
> + const int huffman_precision = VP8LReadBits(br, 3) + 2;
> +@@ -434,16 +439,15 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, 
> int xsize, int ysize,
> +
> +   code_lengths = (int*)WebPSafeCalloc((uint64_t)max_alphabet_size,
> +   sizeof(*code_lengths));
> +-  huffman_tables = (HuffmanCode*)WebPSafeMalloc(num_htree_groups * 
> table_size,
> +-

Re: [OE-core] [PATCH v2] curl: Update from 8.2.1 to 8.3.0

2023-09-27 Thread Robert Joslyn via lists.openembedded.org

On 9/26/23 8:51 PM, Khem Raj wrote:

On Tue, Sep 26, 2023 at 7:55 PM Robert Joslyn
 wrote:

On 9/26/23 7:55 AM, Khem Raj wrote:

I am seeing a ptest failure on qemx86-64/glibc

Failed ptests:
{'curl': ['test_1474', 'curl']}

In looking at the test, it is marked as flaky with the comment:

# Because of the timing sensitivity (scheduling delays of 500 msec can cause
# the test to fail), this test is marked flaky to avoid it being run in
the CI
# builds which are often run on overloaded servers.

https://github.com/curl/curl/blob/curl-8_3_0/tests/data/test1474#L21

My server is pretty lightly loaded while running the tests, so that
could explain why I haven't seen it fail normally. I was able to induce
a failure by running a very heavy load while running that test on my
desktop (which is older and slower than my build server). If you'd like,
I can send a follow up patch to skip tests marked as flaky.


another run resulted in yet another failure

   test 0587...
FAIL: 587: protoc!
There was no content at all in the file log/2/server.input.
Server glitch? Total curl failure? Returned: 42

prior to this upgrade my test setup never saw curl failures and it has
same amount of load etc.


Test 587 is also marked flaky by upstream. There are 12 tests marked as 
flaky total, and since you've just hit two of them, I'm much more 
inclined to just skip them. Right before this version bump there was 
also an update to run the curl ptests in parallel, which could be 
contributing to the change in test behavior.


Thanks,

Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188321): 
https://lists.openembedded.org/g/openembedded-core/message/188321
Mute This Topic: https://lists.openembedded.org/mt/101543494/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] [langdale][kirkstone][PATCH] go-mod.bbclass: Allow network in do_compile

2023-09-27 Thread Lukas Funke

On 10.09.2023 23:26, Martin Jansa wrote:

On Sun, Mar 12, 2023 at 10:15 AM Martin Jansa via lists.openembedded.org
 wrote:


On Tue, Jan 3, 2023 at 5:03 PM Lukas Funke <
lukas.funke-...@weidmueller.com> wrote:


Martin,

first of all: thank you for testing the patches. As usual the corner
cases are the most tricky ones.

tl;dr: I'm working on an updated patch series to address the reported
issues.



Hi Lukas, Stefan,

and update on this series?

It doesn't have to be perfect, other people can help with remaining corner
cases and right now there is nothing for this in oe-core, so any version
will be big improvement :) and it will make it easier for others to submit
incremental improvements - I have some as well, but haven't sent them as I
don't know what you've already updated locally, so I'm waiting for v2.

Mickledore is already in feature freeze, but maybe RP will make an
exception as this is new important functionality which isn't likely to
break other existing code.



Hello Lukas,

any progress on updated patch series? Nanbield release is near and I don't
remember seeing the updated patch series in last couple months.

Is there anything I can do to help? The last version looked reasonably well
and IMHO could be used as starting point for everybody to help fixing those
corner cases where it didn't work well.

Regards,


Hello Martin,

I'm currently working on an update, but can't make any promises 
regarding the timeline.


Thanks for offering help! Reviewing and testing is always helpful when 
the updated series is on it's way.


Regards
Lukas






Kind Regards,


I've looked into the issues and would like to give some explanation.


1) the first module you mention ('gonum.org/v1/gonum
') does not obey the go documentation for
resolving the modules source-code repository (see
https://go.dev/ref/mod#go-mod-download , Section 'Version control
systems'). The documentation states that there should be a html page,
queried by "?go-get=1", with a -tag which contains the original
URL to the source-code repository. For 'gonum' there is only a 404-page.
This page contains javascript-code that redirects to the actual gonum
package page. Unnecessary hard to process. I'll open an issue for that.
The second module 'code.cloudfoundry.org/clock
' has a broken certificate. I
already opend an issue on github for this.

I addressed this issue above by maintaining a list of modules and their
actual repo URLs inside the go-recipetool as an absolute fallback. Would
do you think about this solution?



Yes, that's what I was starting to do in:

https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=b973c7f17c8a613233a1a18de0bf6daa352c47d8

https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=61c6c9962b3b7d4c1cf6e6823de6c32b09998b00



2) yes, my bad :)



as work around I was using

https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=5767819bfe96de29ab751d4a37a431a324f7e547


3) The problem is that some repositories have a prefix in their tags.

The tags usually only contain the semantic version string. I'm curretly
working on this issue.

Best regards

Lukas

Am 22.12.2022 um 20:08 schrieb Martin Jansa via lists.openembedded.org:

On Thu, Dec 22, 2022 at 7:39 PM Vyacheslav Yurkov 
wrote:

 On 22.12.2022 17:48, Bruce Ashfield wrote:
 > On Thu, Dec 22, 2022 at 11:20 AM Richard Purdie
 >  wrote:
 >> This patch is not in master and is not a backport therefore not
 >> eligible for kirkstone/langdale.

 My bad, the intention was to have it in all three branches: master,
 kirkstone, and langdale.

 > 'nor should it go to master.
 >
 > If someone wants to allow go to fetch sources during builds, it
 needs
 > to be done in their own layers.
 >
 > Bruce

 Probably I misunderstood the outcome of the discussion in my first
 link.
 Bruce and Richard, you both suggested to have it in go-mod with the
 warning. I agree that it breaks reproducibility, and is considered
 a bad
 practice in general (I'm aware of a few more build systems with
 the same
 shortcoming).

 My point is, until a proper solution is in place, it should be at
 least
 documented somewhere that this should be done in own layer/recipe.
 Any
 suggestions where this can be documented if not in OE-Core?


Have you tried the changes submitted by Lukas/Stefan in:
https://lists.openembedded.org/g/openembedded-architecture/message/1539
?

It's not perfect, I was testing it on
https://github.com/influxdata/telegraf/blob/master/go.mod and I've
found some corner cases where it failed.

But it seems like very good start and we should work with Lukas/Stefan
to get it merged in master. Then all branches could consume recipes
created in master and only the exceptions would need to have network
access (instead of the bbclass enabling it for every go-mod 

Re: [OE-core] [PATCH 1/2] distcc: Fix groupname gid change warning

2023-09-27 Thread JD Schroeder
On Tue, Sep 12, 2023 at 06:03 AM, Ross Burton wrote:

> 
> On 1 Sep 2023, at 11:03, Alexandre Belloni via lists.openembedded.org
>  wrote:
> 
>> 
>> Hello,
>> 
>> This fails on the autobuilders:
>> 
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3449/steps/12/logs/stdio
>> 
>> 
>> ERROR: Nothing RPROVIDES 'distcc' (but
>> /home/pokybuild/yocto-worker/reproducible/build/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb,
>> /home/pokybuild/yocto-worker/reproducible/build/meta/recipes-devtools/devel-config/distcc-config.bb
>> RDEPENDS on or otherwise requires it)
>> distcc was skipped: Recipe distcc, package distcc-server: system groupname
>> "nogroup" does not have a static ID defined. Add nogroup to one of these
>> files:
>> /home/pokybuild/yocto-worker/reproducible/build/build-st/meta-selftest/files/static-group
>> 
> 
> The same problem would hit the ppp-dialin but that recipe doesn’t get
> built in the AB in an environment that has static IPs.
> 
> Ross

I'm seeing the the warnings being generated in a multi-config Yocto build 
environment. Is there another way to address and fix the warnings I am having 
with the distcc and ppp-dialin recipes (possibly during parsing) even if they 
aren't being built in the AB with static IPs?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188319): 
https://lists.openembedded.org/g/openembedded-core/message/188319
Mute This Topic: https://lists.openembedded.org/mt/101074670/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Alexandre Belloni via lists.openembedded.org
On 27/09/2023 15:02:00+0200, Julien Stephan wrote:
> Le mer. 27 sept. 2023 à 14:59, Alexander Kanavin
>  a écrit :
> >
> > You need to scroll up. The failure is in lines 557 to 609.
> 
> Hmm stange ctrl-f didn't work. I can see it now. Thank you, I'll look at it
> 

By default the log is not fully downloaded, you have to click on the
looking glass before ctrl-f.

> Julien
> >
> > Alex
> >
> >
> > On Wed, 27 Sept 2023 at 14:48, Julien Stephan  wrote:
> > >
> > > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni
> > >  a écrit :
> > > >
> > > > Hello,
> > > >
> > > > I had a build were all the tests passed, then I had this failure:
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio
> > > >
> > >
> > > Hi Alexandre,
> > > I only see
> > >
> > >bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED
> > >
> > > but I can't see the actual error :( Is it possible to have it somewhere?
> > >
> > > Cheers
> > > Julien
> > >
> > > >
> > > >
> > > > --
> > > > Alexandre Belloni, co-owner and COO, Bootlin
> > > > Embedded Linux and Kernel engineering
> > > > https://bootlin.com
> > >
> > > 
> > >

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188318): 
https://lists.openembedded.org/g/openembedded-core/message/188318
Mute This Topic: https://lists.openembedded.org/mt/101570279/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Julien Stephan
Le mer. 27 sept. 2023 à 14:59, Alexander Kanavin
 a écrit :
>
> You need to scroll up. The failure is in lines 557 to 609.

Hmm stange ctrl-f didn't work. I can see it now. Thank you, I'll look at it

Julien
>
> Alex
>
>
> On Wed, 27 Sept 2023 at 14:48, Julien Stephan  wrote:
> >
> > Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni
> >  a écrit :
> > >
> > > Hello,
> > >
> > > I had a build were all the tests passed, then I had this failure:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio
> > >
> >
> > Hi Alexandre,
> > I only see
> >
> >bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED
> >
> > but I can't see the actual error :( Is it possible to have it somewhere?
> >
> > Cheers
> > Julien
> >
> > >
> > >
> > > --
> > > Alexandre Belloni, co-owner and COO, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188317): 
https://lists.openembedded.org/g/openembedded-core/message/188317
Mute This Topic: https://lists.openembedded.org/mt/101570279/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Alexander Kanavin
You need to scroll up. The failure is in lines 557 to 609.

Alex


On Wed, 27 Sept 2023 at 14:48, Julien Stephan  wrote:
>
> Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni
>  a écrit :
> >
> > Hello,
> >
> > I had a build were all the tests passed, then I had this failure:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio
> >
>
> Hi Alexandre,
> I only see
>
>bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED
>
> but I can't see the actual error :( Is it possible to have it somewhere?
>
> Cheers
> Julien
>
> >
> >
> > --
> > Alexandre Belloni, co-owner and COO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188316): 
https://lists.openembedded.org/g/openembedded-core/message/188316
Mute This Topic: https://lists.openembedded.org/mt/101570279/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Alexandre Belloni via lists.openembedded.org
On 27/09/2023 14:47:57+0200, Julien Stephan wrote:
> Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni
>  a écrit :
> >
> > Hello,
> >
> > I had a build were all the tests passed, then I had this failure:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio
> >
> 
> Hi Alexandre,
> I only see
> 
>bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED
> 
> but I can't see the actual error :( Is it possible to have it somewhere?
> 

You can scroll up or click on the looking glass on the top right.

Alternatively, you can download the log here:
https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/8276762/raw
(the button is also on the top right)


The assertion error is fairly large, that's why I didn't copy it.


> Cheers
> Julien
> 
> >
> >
> > --
> > Alexandre Belloni, co-owner and COO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188315): 
https://lists.openembedded.org/g/openembedded-core/message/188315
Mute This Topic: https://lists.openembedded.org/mt/101570279/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] gcc: depend on zstd

2023-09-27 Thread Sean Nyekjaer
Add zstd LTO support for target and nativesdk compiler.
This also brings gcc into sync with gcc-cross.

---
% x86_64-oe-linux-gcc -v
[...]
 Supported LTO compression algorithms: zlib zstd
 gcc version 12.2.0 (GCC)
% x86_64-oesdk-linux-gcc -v
[...]
 Supported LTO compression algorithms: zlib
 gcc version 12.2.0 (GCC)
---

Signed-off-by: Sean Nyekjaer 
---
 meta/recipes-devtools/gcc/gcc-13.2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-13.2.inc 
b/meta/recipes-devtools/gcc/gcc-13.2.inc
index d96f3171e4..359db1e278 100644
--- a/meta/recipes-devtools/gcc/gcc-13.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-13.2.inc
@@ -10,7 +10,7 @@ BINV = "13.2.0"
 
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
 
-DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
+DEPENDS =+ "mpfr gmp libmpc zlib zstd flex-native"
 NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native 
zstd-native"
 
 LICENSE = "GPL-3.0-with-GCC-exception & GPL-3.0-only"
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188314): 
https://lists.openembedded.org/g/openembedded-core/message/188314
Mute This Topic: https://lists.openembedded.org/mt/101616424/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Julien Stephan
Le mer. 27 sept. 2023 à 12:16, Alexandre Belloni
 a écrit :
>
> Hello,
>
> I had a build were all the tests passed, then I had this failure:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio
>

Hi Alexandre,
I only see

   bblock.BBLock.test_lock_single_recipe_all_tasks: FAILED

but I can't see the actual error :( Is it possible to have it somewhere?

Cheers
Julien

>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

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



[OE-core] [kirkstone][PATCH 2/3] bind: update to 9.18.19

2023-09-27 Thread Lee Chee Yang
From: Lee Chee Yang 

Notes for BIND 9.18.19
Security Fixes
Previously, sending a specially crafted message over the control channel
could cause the packet-parsing code to run out of available stack
memory, causing named to terminate unexpectedly. This has been fixed.
(CVE-2023-3341)

ISC would like to thank Eric Sesterhenn from X41 D-Sec GmbH for bringing
this vulnerability to our attention. [GL #4152]

A flaw in the networking code handling DNS-over-TLS queries could cause
named to terminate unexpectedly due to an assertion failure under
significant DNS-over-TLS query load. This has been fixed.
(CVE-2023-4236)

ISC would like to thank Robert Story from USC/ISI Root Server Operations
for bringing this vulnerability to our attention. [GL #4242]

Removed Features
The dnssec-must-be-secure option has been deprecated and will be removed
in a future release. [GL #4263]

Feature Changes
If the server command is specified, nsupdate now honors the nsupdate -v
option for SOA queries by sending both the UPDATE request and the
initial query over TCP. [GL #1181]

Bug Fixes
The value of the If-Modified-Since header in the statistics channel was
not being correctly validated for its length, potentially allowing an
authorized user to trigger a buffer overflow. Ensuring the statistics
channel is configured correctly to grant access exclusively to
authorized users is essential (see the statistics-channels block
definition and usage section). [GL #4124]

This issue was reported independently by Eric Sesterhenn of X41 D-Sec
GmbH and Cameron Whitehead.

The Content-Length header in the statistics channel was lacking proper
bounds checking. A negative or excessively large value could potentially
trigger an integer overflow and result in an assertion failure. [GL

This issue was reported by Eric Sesterhenn of X41 D-Sec GmbH.

Several memory leaks caused by not clearing the OpenSSL error stack were
fixed. [GL #4159]

This issue was reported by Eric Sesterhenn of X41 D-Sec GmbH.

The introduction of krb5-subdomain-self-rhs and ms-subdomain-self-rhs
UPDATE policies accidentally caused named to return SERVFAIL responses
to deletion requests for non-existent PTR and SRV records. This has been
fixed. [GL #4280]

The stale-refresh-time feature was mistakenly disabled when the server
cache was flushed by rndc flush. This has been fixed. [GL #4278]

BIND’s memory consumption has been improved by implementing dedicated
jemalloc memory arenas for sending buffers. This optimization ensures
that memory usage is more efficient and better manages the return of
memory pages to the operating system. [GL #4038]

Previously, partial writes in the TLS DNS code were not accounted for
correctly, which could have led to DNS message corruption. This has been
fixed. [GL #4255]

Known Issues
There are no new known issues with this release. See above for a list of
all known issues affecting this BIND 9 branch.

Notes for BIND 9.18.18
Feature Changes
When a primary server for a zone responds to an SOA query, but the
subsequent TCP connection required to transfer the zone is refused, that
server is marked as temporarily unreachable. This now also happens if
the TCP connection attempt times out, preventing too many zones from
queuing up on an unreachable server and allowing the refresh process to
move on to the next configured primary more quickly. [GL #4215]

The dialup and heartbeat-interval options have been deprecated and will
be removed in a future BIND 9 release. [GL #3700]

Bug Fixes
Processing already-queued queries received over TCP could cause an
assertion failure, when the server was reconfigured at the same time or
the cache was being flushed. This has been fixed. [GL #4200]

Setting dnssec-policy to insecure prevented zones containing resource
records with a TTL value larger than 86400 seconds (1 day) from being
loaded. This has been fixed by ignoring the TTL values in the zone and
using a value of 604800 seconds (1 week) as the maximum zone TTL in key
rollover timing calculations. [GL #4032]

Known Issues
There are no new known issues with this release. See above for a list of
all known issues affecting this BIND 9 branch.

Link to release notes:
https://bind9.readthedocs.io/en/v9.18.19/notes.html#notes-for-bind-9-18-19

Signed-off-by: Lee Chee Yang 
---
 .../0001-avoid-start-failure-with-bind-user.patch   | 0
 .../0001-named-lwresd-V-and-start-log-hide-build-options.patch  | 0
 .../bind-ensure-searching-for-json-headers-searches-sysr.patch  | 0
 meta/recipes-connectivity/bind/{bind-9.18.17 => bind}/bind9 | 0
 .../recipes-connectivity/bind/{bind-9.18.17 => bind}/conf.patch | 0
 .../bind/{bind-9.18.17 => bind}/generate-rndc-key.sh| 0
 .../init.d-add-support-for-read-only-rootfs.patch   | 0
 .../{bind-9.18.17 => bind}/make-etc-initd-bind-stop-work.patch  | 0
 .../bind/{bind-9.18.17 => bind}/named.service   | 0
 .../bind/{bind_9.18.17.bb => bind_9.18.19.bb}   | 2 +-
 10 

[OE-core] [kirkstone][PATCH 3/3] cups: Fix CVE-2023-4504

2023-09-27 Thread Lee Chee Yang
From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
---
 meta/recipes-extended/cups/cups.inc   |  1 +
 .../cups/cups/CVE-2023-4504.patch | 42 +++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-4504.patch

diff --git a/meta/recipes-extended/cups/cups.inc 
b/meta/recipes-extended/cups/cups.inc
index 4d0c52eab85..047ab338983 100644
--- a/meta/recipes-extended/cups/cups.inc
+++ b/meta/recipes-extended/cups/cups.inc
@@ -18,6 +18,7 @@ SRC_URI = 
"https://github.com/OpenPrinting/cups/releases/download/v${PV}/cups-${
file://CVE-2023-32324.patch \
file://CVE-2023-34241.patch \
   file://CVE-2023-32360.patch \
+  file://CVE-2023-4504.patch \
"
 
 UPSTREAM_CHECK_URI = "https://github.com/OpenPrinting/cups/releases;
diff --git a/meta/recipes-extended/cups/cups/CVE-2023-4504.patch 
b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
new file mode 100644
index 000..e52e43a209b
--- /dev/null
+++ b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
@@ -0,0 +1,42 @@
+CVE: CVE-2023-4504
+Upstream-Status: Backport 
[https://github.com/OpenPrinting/cups/commit/2431caddb7e6a87f04ac90b5c6366ad268b6ff31
 ]
+Signed-off-by: Lee Chee Yang 
+
+From 2431caddb7e6a87f04ac90b5c6366ad268b6ff31 Mon Sep 17 00:00:00 2001
+From: Zdenek Dohnal 
+Date: Wed, 20 Sep 2023 14:45:17 +0200
+Subject: [PATCH] raster-interpret.c: Fix CVE-2023-4504
+
+We didn't check for end of buffer if it looks there is an escaped
+character - check for NULL terminator there and if found, return NULL
+as return value and in `ptr`, because a lone backslash is not
+a valid PostScript character.
+---
+ cups/raster-interpret.c | 14 +-
+ 1 files changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/cups/raster-interpret.c b/cups/raster-interpret.c
+index 6fcf731b5..b8655c8c6 100644
+--- a/cups/raster-interpret.c
 b/cups/raster-interpret.c
+@@ -1116,7 +1116,19 @@ scan_ps(_cups_ps_stack_t *st,   /* I  - Stack */
+ 
+   cur ++;
+ 
+-if (*cur == 'b')
++ /*
++  * Return NULL if we reached NULL terminator, a lone backslash
++  * is not a valid character in PostScript.
++  */
++
++  if (!*cur)
++  {
++*ptr = NULL;
++
++return (NULL);
++  }
++
++  if (*cur == 'b')
+ *valptr++ = '\b';
+   else if (*cur == 'f')
+ *valptr++ = '\f';
-- 
2.37.3


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



[OE-core] [kirkstone][PATCH 1/3] xserver-xorg: ignore CVE-2022-3553 as it is XQuartz-specific

2023-09-27 Thread Lee Chee Yang
From: Ross Burton 

(cherry-pick from commit 769576f36aac9652525beec5c7e8a4d26632b844 )

Signed-off-by: Ross Burton 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Lee Chee Yang 
---
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc 
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 6b11c79be6e..ecb164ddf76 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -28,6 +28,8 @@ CVE_CHECK_IGNORE += "CVE-2011-4613"
 # impossible or difficult to exploit. There is currently no upstream patch
 # available for this flaw.
 CVE_CHECK_IGNORE += "CVE-2020-25697"
+# This is specific to XQuartz, which is the macOS X server port
+CVE_CHECK_IGNORE += "CVE-2022-3553"
 
 S = "${WORKDIR}/${XORG_PN}-${PV}"
 
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188310): 
https://lists.openembedded.org/g/openembedded-core/message/188310
Mute This Topic: https://lists.openembedded.org/mt/101615648/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] gcc: depend on zstd

2023-09-27 Thread Richard Purdie
On Wed, 2023-09-27 at 13:22 +0200, Sean Nyekjaer wrote:
> 
> > On 27 Sep 2023, at 13.17, Richard Purdie 
> >  wrote:
> > 
> > On Wed, 2023-09-27 at 12:49 +0200, Sean Nyekjaer wrote:
> > > Add zstd LTO support for the nativesdk compiler.
> > 
> > This is changing it for the target compiler as well? 
> > 
> > Perhaps also mention it brings it into sync with gcc-cross (assuming it
> > does?).
> > 
> > Cheers,
> > 
> > Richard
> > 
> 
> Hi Richard,
> 
> It looks like the target compiler(x86_64-oe-linux) already had zstd support.
> 
> ---
> % x86_64-oe-linux-gcc -v
> [...]
> Supported LTO compression algorithms: zlib zstd
> gcc version 12.2.0 (GCC)
> % x86_64-oesdk-linux-gcc -v
> [...]
> Supported LTO compression algorithms: zlib
> gcc version 12.2.0 (GCC)
> —
> 
> Or I’m wrong?

Sorry, I mean the on target compiler, i.e. if you boot an image with
gcc in it. I think it might be missing there. The compiler above is
what I'd refer to as the cross compiler.

I'd just like to be clear in the commit message what the current state
is and which ones are changing. I do agree we should bring them into
sync.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188309): 
https://lists.openembedded.org/g/openembedded-core/message/188309
Mute This Topic: https://lists.openembedded.org/mt/101614708/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] gcc: depend on zstd

2023-09-27 Thread Sean Nyekjaer


> On 27 Sep 2023, at 13.17, Richard Purdie  
> wrote:
> 
> On Wed, 2023-09-27 at 12:49 +0200, Sean Nyekjaer wrote:
>> Add zstd LTO support for the nativesdk compiler.
> 
> This is changing it for the target compiler as well? 
> 
> Perhaps also mention it brings it into sync with gcc-cross (assuming it
> does?).
> 
> Cheers,
> 
> Richard
> 

Hi Richard,

It looks like the target compiler(x86_64-oe-linux) already had zstd support.

---
% x86_64-oe-linux-gcc -v
[...]
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
% x86_64-oesdk-linux-gcc -v
[...]
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)
—

Or I’m wrong?

Br,
/Sean
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188308): 
https://lists.openembedded.org/g/openembedded-core/message/188308
Mute This Topic: https://lists.openembedded.org/mt/101614708/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] gcc: depend on zstd

2023-09-27 Thread Richard Purdie
On Wed, 2023-09-27 at 12:49 +0200, Sean Nyekjaer wrote:
> Add zstd LTO support for the nativesdk compiler.

This is changing it for the target compiler as well? 

Perhaps also mention it brings it into sync with gcc-cross (assuming it
does?).

Cheers,

Richard


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



Re: [OE-core] [PATCH V2] glibc: stable 2.38 branch updates.

2023-09-27 Thread Deepthi . Hemraj
Regression testing is done and below are the test results.

Before glibc update
Summary of test results:
213 FAIL
4805 PASS
16 XFAIL
4 XPASS
218 UNSUPPORTED

After glibc update
Summary of test results:
216 FAIL
4805 PASS
16 XFAIL
4 XPASS
218 UNSUPPORTED

*These are the newly added test cases*
PASS: io/tst-fcntl-lock-lfs
FAIL: nss/tst-nss-gai-hv2-canonname
PASS: resolv/tst-resolv-no-vc
*And below are new failures*
FAIL: nptl/tst-thread-affinity-sched
FAIL: malloc/tst-malloc_info-malloc-check

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



Re: [OE-core] [PATCH V2] binutils: stable 2.41 branch updates.

2023-09-27 Thread Deepthi . Hemraj
Regression testing is done and no regressions found.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188305): 
https://lists.openembedded.org/g/openembedded-core/message/188305
Mute This Topic: https://lists.openembedded.org/mt/101614741/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] binutils: stable 2.41 branch updates.

2023-09-27 Thread Hemraj, Deepthi via lists.openembedded.org
Below commits on binutils-2.41 stable branch are updated.
cb4c3555ac4 (HEAD -> binutils-2_41-branch, origin/binutils-2_41-branch) 
Automatic date update in version.in
6ffa5a420a0 aarch64: Remove unused function
b6f6a3ecd15 x86: restrict prefix use with .insn VEX/XOP/EVEX
60834ae1eb7 PR30794, PowerPC gold: internal error in add_output_section_to_load
951a6945b44 Updated Russian translation for the bfd directory
226f2e6b924 PR30724, cygwin ld performance regression since 014a602b86
8c05bf16a51 PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
31b78cc9917 gas: rework timestamp preservation on doc/asconfig.texi

Signed-off-by: Deepthi Hemraj 
---
 meta/recipes-devtools/binutils/binutils-2.41.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.41.inc 
b/meta/recipes-devtools/binutils/binutils-2.41.inc
index 7ab2926570..b4934c02a8 100644
--- a/meta/recipes-devtools/binutils/binutils-2.41.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.41.inc
@@ -18,7 +18,7 @@ SRCBRANCH ?= "binutils-2_41-branch"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
 
-SRCREV ?= "fd3cc73ee4a84df3ace3c0e470250a957e7d3468"
+SRCREV ?= "cb4c3555ac4cf8aaf0935cb6e4b09e6882436d21"
 BINUTILS_GIT_URI ?= 
"git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
 SRC_URI = "\
  ${BINUTILS_GIT_URI} \
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188304): 
https://lists.openembedded.org/g/openembedded-core/message/188304
Mute This Topic: https://lists.openembedded.org/mt/101614741/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] cups: fix CVE-2023-4504

2023-09-27 Thread Lee Chee Yang
From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
---
 meta/recipes-extended/cups/cups.inc   |  1 +
 .../cups/cups/CVE-2023-4504.patch | 42 +++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-extended/cups/cups/CVE-2023-4504.patch

diff --git a/meta/recipes-extended/cups/cups.inc 
b/meta/recipes-extended/cups/cups.inc
index 36feaddcf8..fa32c38549 100644
--- a/meta/recipes-extended/cups/cups.inc
+++ b/meta/recipes-extended/cups/cups.inc
@@ -15,6 +15,7 @@ SRC_URI = 
"${GITHUB_BASE_URI}/download/v${PV}/cups-${PV}-source.tar.gz \
file://0004-cups-fix-multilib-install-file-conflicts.patch \
file://volatiles.99_cups \
file://cups-volatiles.conf \
+   file://CVE-2023-4504.patch \
"
 
 GITHUB_BASE_URI = "https://github.com/OpenPrinting/cups/releases;
diff --git a/meta/recipes-extended/cups/cups/CVE-2023-4504.patch 
b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
new file mode 100644
index 00..e52e43a209
--- /dev/null
+++ b/meta/recipes-extended/cups/cups/CVE-2023-4504.patch
@@ -0,0 +1,42 @@
+CVE: CVE-2023-4504
+Upstream-Status: Backport 
[https://github.com/OpenPrinting/cups/commit/2431caddb7e6a87f04ac90b5c6366ad268b6ff31
 ]
+Signed-off-by: Lee Chee Yang 
+
+From 2431caddb7e6a87f04ac90b5c6366ad268b6ff31 Mon Sep 17 00:00:00 2001
+From: Zdenek Dohnal 
+Date: Wed, 20 Sep 2023 14:45:17 +0200
+Subject: [PATCH] raster-interpret.c: Fix CVE-2023-4504
+
+We didn't check for end of buffer if it looks there is an escaped
+character - check for NULL terminator there and if found, return NULL
+as return value and in `ptr`, because a lone backslash is not
+a valid PostScript character.
+---
+ cups/raster-interpret.c | 14 +-
+ 1 files changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/cups/raster-interpret.c b/cups/raster-interpret.c
+index 6fcf731b5..b8655c8c6 100644
+--- a/cups/raster-interpret.c
 b/cups/raster-interpret.c
+@@ -1116,7 +1116,19 @@ scan_ps(_cups_ps_stack_t *st,   /* I  - Stack */
+ 
+   cur ++;
+ 
+-if (*cur == 'b')
++ /*
++  * Return NULL if we reached NULL terminator, a lone backslash
++  * is not a valid character in PostScript.
++  */
++
++  if (!*cur)
++  {
++*ptr = NULL;
++
++return (NULL);
++  }
++
++  if (*cur == 'b')
+ *valptr++ = '\b';
+   else if (*cur == 'f')
+ *valptr++ = '\f';
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188303): 
https://lists.openembedded.org/g/openembedded-core/message/188303
Mute This Topic: https://lists.openembedded.org/mt/101614727/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] gcc: depend on zstd

2023-09-27 Thread Sean Nyekjaer
Add zstd LTO support for the nativesdk compiler.

---
% x86_64-oe-linux-gcc -v
[...]
 Supported LTO compression algorithms: zlib zstd
 gcc version 12.2.0 (GCC)
% x86_64-oesdk-linux-gcc -v
[...]
 Supported LTO compression algorithms: zlib
 gcc version 12.2.0 (GCC)
---

Signed-off-by: Sean Nyekjaer 
---
 meta/recipes-devtools/gcc/gcc-13.2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-13.2.inc 
b/meta/recipes-devtools/gcc/gcc-13.2.inc
index d96f3171e4..359db1e278 100644
--- a/meta/recipes-devtools/gcc/gcc-13.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-13.2.inc
@@ -10,7 +10,7 @@ BINV = "13.2.0"
 
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
 
-DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
+DEPENDS =+ "mpfr gmp libmpc zlib zstd flex-native"
 NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native 
zstd-native"
 
 LICENSE = "GPL-3.0-with-GCC-exception & GPL-3.0-only"
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188302): 
https://lists.openembedded.org/g/openembedded-core/message/188302
Mute This Topic: https://lists.openembedded.org/mt/101614708/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] multilib_script.bbclass: expand script name as well

2023-09-27 Thread Martin Jansa
* e.g. mozjs from meta-oe contains major version from PV in the script name
  but currently cannot use a variable there because it would be unexpanded
  in the varflag name as shown in bitbake -e (lib32-curl included for 
comparison)

env.lib32-curl:# $ALTERNATIVE_TARGET [2 operations]
env.lib32-curl-#   set oe-core/meta/conf/documentation.conf:66
env.lib32-curl-# [doc] "Used by the alternatives system to create default 
link locations for duplicated commands."
env.lib32-curl-#   set multilib_script.bbclass:37 
[__anon_40_oe_core_meta_classes_recipe_multilib_script_bbclass]
env.lib32-curl-# [curl-config] "${bindir}/curl-config-${MULTILIB_SUFFIX}"
env.lib32-curl-# pre-expansion value:
env.lib32-curl-#   "None"
--
env.lib32-mozjs-115:# $ALTERNATIVE_TARGET [2 operations]
env.lib32-mozjs-115-#   set oe-core/meta/conf/documentation.conf:66
env.lib32-mozjs-115-# [doc] "Used by the alternatives system to create 
default link locations for duplicated commands."
env.lib32-mozjs-115-#   set multilib_script.bbclass:37 
[__anon_40_oe_core_meta_classes_recipe_multilib_script_bbclass]
env.lib32-mozjs-115-# [js${MAJ_VER}-config] 
"${bindir}/js${MAJ_VER}-config-${MULTILIB_SUFFIX}"
env.lib32-mozjs-115-# pre-expansion value:
env.lib32-mozjs-115-#   "None"
--
env.lib32-mozjs-115-escript:# $ALTERNATIVE_TARGET [2 operations]
env.lib32-mozjs-115-escript-#   set oe-core/meta/conf/documentation.conf:66
env.lib32-mozjs-115-escript-# [doc] "Used by the alternatives system to 
create default link locations for duplicated commands."
env.lib32-mozjs-115-escript-#   set multilib_script.bbclass:38 
[__anon_41_oe_core_meta_classes_recipe_multilib_script_bbclass]
env.lib32-mozjs-115-escript-# [js115-config] 
"/usr/bin/js115-config-${MULTILIB_SUFFIX}"
env.lib32-mozjs-115-escript-# pre-expansion value:
env.lib32-mozjs-115-escript-#   "None"

Otherwise log.do_package shows that apply_update_alternative_renames first
renames the js115-config to js115-config.mozjs-115 (default ALTERNATIVE_TARGET 
suffix is '.${BPN}')
and multilibscript_rename later fails:

DEBUG: Executing python function apply_update_alternative_renames
NOTE: mozjs-115: Rename /usr/bin/js115-config -> /usr/bin/js115-config.mozjs-115
DEBUG: Python function apply_update_alternative_renames finished
DEBUG: Executing shell function multilibscript_rename
mv: cannot stat 
'BUILD/work/mach-oemllib32-linux-gnueabi/lib32-mozjs-115/115.2.0/package/usr/bin/js115-config':
 No such file or directory
WARNING: exit code 1 from a shell command.

I wonder if we actually need multilibscript_rename as 
apply_update_alternative_renames seems
to do the rename already.

Signed-off-by: Martin Jansa 
---
 meta/classes-recipe/multilib_script.bbclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/classes-recipe/multilib_script.bbclass 
b/meta/classes-recipe/multilib_script.bbclass
index 7011526254..e6f0249529 100644
--- a/meta/classes-recipe/multilib_script.bbclass
+++ b/meta/classes-recipe/multilib_script.bbclass
@@ -31,10 +31,11 @@ python () {
 for entry in (d.getVar("MULTILIB_SCRIPTS", False) or "").split():
 pkg, script = entry.split(":")
 epkg = d.expand(pkg)
-scriptname = os.path.basename(script)
+escript = d.expand(script)
+scriptname = os.path.basename(escript)
 d.appendVar("ALTERNATIVE:" + epkg, " " + scriptname + " ")
-d.setVarFlag("ALTERNATIVE_LINK_NAME", scriptname, script)
-d.setVarFlag("ALTERNATIVE_TARGET", scriptname, script + 
"-${MULTILIB_SUFFIX}")
-d.appendVar("multilibscript_rename",  "\n  mv ${PKGD}" + script + 
" ${PKGD}" + script + "-${MULTILIB_SUFFIX}")
-d.appendVar("FILES:" + epkg, " " + script + "-${MULTILIB_SUFFIX}")
+d.setVarFlag("ALTERNATIVE_LINK_NAME", scriptname, escript)
+d.setVarFlag("ALTERNATIVE_TARGET", scriptname, escript + 
"-${MULTILIB_SUFFIX}")
+d.appendVar("multilibscript_rename",  "\n  mv ${PKGD}" + escript + 
" ${PKGD}" + escript + "-${MULTILIB_SUFFIX}")
+d.appendVar("FILES:" + epkg, " " + escript + "-${MULTILIB_SUFFIX}")
 }
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188301): 
https://lists.openembedded.org/g/openembedded-core/message/188301
Mute This Topic: https://lists.openembedded.org/mt/101614693/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] glibc: stable 2.38 branch updates.

2023-09-27 Thread Hemraj, Deepthi via lists.openembedded.org
Below commits on glibc-2.38 stable branch are updated.
0e1ef6779a (HEAD -> release/2.38/master, origin/release/2.38/master) 
manual/jobs.texi: Add missing @item EPERM for getpgid
d94461bb86 string: Fix tester build with fortify enable with gcc < 12
63250e9c57 iconv: restore verbosity with unrecognized encoding names (bug 30694)
00ae4f10b5 getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
b25508dd77 CVE-2023-4527: Stack read overflow with large TCP responses in 
no- mode
89da8bc588 NEWS: Add the 2.38.1 bug list
d3ba6c1333 elf: Move l_init_called_next to old place of l_text_end in link map
750f19526a elf: Remove unused l_text_end field from struct link_map
a3189f66a5 elf: Always call destructors in reverse constructor order (bug 30785)
7ae211a01b elf: Do not run constructors for proxy objects
92201f16cb libio: Fix oversized __io_vtables
5bdef6f27c io: Fix record locking contants for powerpc64 with 
__USE_FILE_OFFSET64

Signed-off-by: Deepthi Hemraj 
---
 meta/recipes-core/glibc/glibc-version.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index a907444f50..f5ebbb2ee6 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
 SRCBRANCH ?= "release/2.38/master"
 PV = "2.38+git"
-SRCREV_glibc ?= "1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1"
+SRCREV_glibc ?= "0e1ef6779a90bc0f8a05bc367796df2793deecaa"
 SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188300): 
https://lists.openembedded.org/g/openembedded-core/message/188300
Mute This Topic: https://lists.openembedded.org/mt/101614685/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] binutils: stable 2.41 branch updates

2023-09-27 Thread Deepthi . Hemraj
Regression testing with binutils testing is performed and no regressions found

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188299): 
https://lists.openembedded.org/g/openembedded-core/message/188299
Mute This Topic: https://lists.openembedded.org/mt/101614455/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] binutils: stable 2.41 branch updates

2023-09-27 Thread Hemraj, Deepthi via lists.openembedded.org
Below commits on binutils-2.41 stable branch are updated.
cb4c3555ac4 (HEAD -> binutils-2_41-branch, origin/binutils-2_41-branch) 
Automatic date update in version.in
6ffa5a420a0 aarch64: Remove unused function
b6f6a3ecd15 x86: restrict prefix use with .insn VEX/XOP/EVEX
60834ae1eb7 PR30794, PowerPC gold: internal error in add_output_section_to_load
951a6945b44 Updated Russian translation for the bfd directory
226f2e6b924 PR30724, cygwin ld performance regression since 014a602b86
8c05bf16a51 PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
31b78cc9917 gas: rework timestamp preservation on doc/asconfig.texi

Signed-off-by: Deepthi Hemraj 
---
 meta/recipes-devtools/binutils/binutils-2.41.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.41.inc 
b/meta/recipes-devtools/binutils/binutils-2.41.inc
index 7ab2926570..b4934c02a8 100644
--- a/meta/recipes-devtools/binutils/binutils-2.41.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.41.inc
@@ -18,7 +18,7 @@ SRCBRANCH ?= "binutils-2_41-branch"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
 
-SRCREV ?= "fd3cc73ee4a84df3ace3c0e470250a957e7d3468"
+SRCREV ?= "cb4c3555ac4cf8aaf0935cb6e4b09e6882436d21"
 BINUTILS_GIT_URI ?= 
"git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
 SRC_URI = "\
  ${BINUTILS_GIT_URI} \
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188298): 
https://lists.openembedded.org/g/openembedded-core/message/188298
Mute This Topic: https://lists.openembedded.org/mt/101614455/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 v5 0/5] Add bblock helper scripts

2023-09-27 Thread Alexandre Belloni via lists.openembedded.org
Hello,

I had a build were all the tests passed, then I had this failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5812/steps/14/logs/stdio

On 25/09/2023 10:04:47+0200, Julien Stephan wrote:
> Hi all,
> 
> This is v5 for bblock script.
> 
> Improvement from v4:
> * Fix self test error reported by autobuilder
> * Allow to specify task with/without the "do_" prefix:
>   example: bblock bc -t compile,do_install
> * Fix test_lock_single_recipe_all_tasks
> * Fix getTaskSignatures: now retrieve all tasks and filter out the
> * setscene and nostamps ones
> 
> Limitations:
> * Silently does nothing if given task doesn't exist
> * Silently does nothing when resetting a recipe that doesn't exist
> 
> Improvement from v3:
> * Add self test
> * Add a new "info" level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK: this allows to
>   display a Note when recipe contains locked task(s)
> 
> Improvement from v2:
> * Add a function in bb.cooker to compute task signatures
> * Replace the findSigInfo function by the new created one. This has the
>   following advantages:
> * findSigInfo needs the task to be already built to get the siginfo
>   file, meaning we cannot lock a recipe on a fresh build
> * we can now generate the signatures for all available task of a given
>   recipe
> * Check if a given task is already locked. If so, don't duplicate
>   entry in bblock.conf
> 
> Limitations:
> * Needs to taint tasks that are locked, to display a warning
> * I may be still missing some checks on user input
> * Silently does nothing if given task doesn't exist
> * Silently does nothing when resetting a recipe that doesn't exist
> 
> I did some tests using qemux86-64 and qemuarm but I may be missing some
> corner cases.
> 
> Improvement from V1:
> * Signatures are now package architecture specific meaning that if you
>   switch MACHINE, the lock sig will not be taken into account
> * I added the -r option to unlock recipes
> * I added a -d option to display the current bblock.conf
> * Added an include directive for conf/bblock.conf inside bitbake.conf
> * Added -t option to specify the tasks to lock/unlock
> 
> Limitations:
> * I may be still missing some checks on user input
> * I need to find a way to get the list of tasks ( by default still lock
>   only the do_compile for now, unless -t is specified)
> * Do not check if a particular recipe/task is already locked when trying
>   to add lock. So entries may appear multiple times
> * We still need the signature of the tasks to be already computed before
>   locking. Need to find a way to generate it if missing
> 
> V3: https://lists.openembedded.org/g/openembedded-core/message/184932
> V2: https://lists.openembedded.org/g/openembedded-core/message/184697
> V1: https://lists.openembedded.org/g/openembedded-core/message/184584
> 
> My branch is available here [1]
> 
> Cheers
> Julien
> 
> [1]: https://git.yoctoproject.org/poky-contrib/commit/?h=jstephan/bblock
> 
> Julien Stephan (5):
>   bitbake.conf: include bblock.conf
>   bitbake: cooker: add a new function to retrieve task signatures
>   sstatesig: add a new info level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK
>   scripts/bblock: add a script to lock/unlock recipes
>   oeqa/selftest/bblock: add self test for bblock tool
> 
>  bitbake/lib/bb/command.py  |   6 +
>  bitbake/lib/bb/cooker.py   |  31 
>  bitbake/lib/bb/event.py|   8 +
>  meta/conf/bitbake.conf |   1 +
>  meta/lib/oe/sstatesig.py   |  18 ++-
>  meta/lib/oeqa/selftest/cases/bblock.py | 201 +
>  scripts/bblock | 184 ++
>  7 files changed, 448 insertions(+), 1 deletion(-)
>  create mode 100644 meta/lib/oeqa/selftest/cases/bblock.py
>  create mode 100755 scripts/bblock
> 
> --
> 2.41.0
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188297): 
https://lists.openembedded.org/g/openembedded-core/message/188297
Mute This Topic: https://lists.openembedded.org/mt/101570279/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] glibc: stable 2.38 branch updates.

2023-09-27 Thread Hemraj, Deepthi via lists.openembedded.org
Below commits on glibc-2.38 stable branch are updated.
0e1ef6779a (HEAD -> release/2.38/master, origin/release/2.38/master) 
manual/jobs.texi: Add missing @item EPERM for getpgid
d94461bb86 string: Fix tester build with fortify enable with gcc < 12
63250e9c57 iconv: restore verbosity with unrecognized encoding names (bug 30694)
00ae4f10b5 getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
b25508dd77 CVE-2023-4527: Stack read overflow with large TCP responses in 
no- mode
89da8bc588 NEWS: Add the 2.38.1 bug list
d3ba6c1333 elf: Move l_init_called_next to old place of l_text_end in link map
750f19526a elf: Remove unused l_text_end field from struct link_map
a3189f66a5 elf: Always call destructors in reverse constructor order (bug 30785)
7ae211a01b elf: Do not run constructors for proxy objects
92201f16cb libio: Fix oversized __io_vtables
5bdef6f27c io: Fix record locking contants for powerpc64 with 
__USE_FILE_OFFSET64

Signed-off-by: Deepthi Hemraj 
---
 meta/recipes-core/glibc/glibc-version.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index a907444f50..f5ebbb2ee6 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
 SRCBRANCH ?= "release/2.38/master"
 PV = "2.38+git"
-SRCREV_glibc ?= "1aed90c9c8f8be9f68b58e96b6e4cd0fc08eb2b1"
+SRCREV_glibc ?= "0e1ef6779a90bc0f8a05bc367796df2793deecaa"
 SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https"
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188296): 
https://lists.openembedded.org/g/openembedded-core/message/188296
Mute This Topic: https://lists.openembedded.org/mt/101614434/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] [Openembedded-architecture] [yocto] Security processes: YP needs

2023-09-27 Thread Reyna, David via lists.openembedded.org
Hi Marta!

> What about 11am Pacific on tomorrow (28 Sept or Oct 3)? 

Let us aim for October 3 so that I can prepare a full demo..

> I think that you have meant 10am to 2PM, otherwise 1am Pacific would work 
> very well for me too 

I actually did mean 2:00 am Pacific. I do work with our India team, so I am 
often up late to sync with them..

> As discussed yesterday in the call, there are some other people who seem 
> interested.

What time zone are you in? 
I believe Ross is in England (UTC)
I know that Randy is in Ottawa.

If anyone else wants to join, that would be great!. They should ping us and I 
can send the Zoom link. I do not want to send that link blindly to the full 
mail list.

> I'm going to add the missing file for the test next week, the tool needs a 
> script to download 2023 data.

That file is part of my code update, so you can get that for free.

David

-Original Message-
From: Marta Rybczynska  
Sent: Wednesday, September 27, 2023 12:18 AM
To: Reyna, David 
Cc: yocto-secur...@lists.yoctoproject.org; OE-core 
; 
openembedded-architect...@lists.openembedded.org; yo...@lists.yoctoproject.org; 
MacLeod, Randy ; Richard Purdie 
; Steve Sakoman ; Khem 
Raj ; mark.ha...@kernel.crashing.org; Ross Burton 
; Joshua Watt 
Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP needs

Hi David,
Thank you very much for the description and the offer to get a demo.
As discussed yesterday in the call, there are some other people who
seem interested.

> PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps 
> using it to track and coordinate work will bring immediate benefit.

This is the reason I want to test how much time it takes.

> PROPOSAL 2: I am happy to give you a live demo of Wind River's fully 
> operational SRTool, so you can see all of the bells and whistles in action. I 
> am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific.

That would be nice. What about 11am Pacific on tomorrow (28 Sept or
Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific
would work very well for me too :P

> PROPOSAL 3: I will start refreshing the YP SRTool repository with my current 
> implementation level from Wind River (with the Wind River specific modules 
> left out of course :-)

That would be great. I'm going to add the missing file for the test
next week, the tool needs a script to download 2023 data.

Kind regards,
Marta

On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via
lists.openembedded.org
 wrote:
>
> Hi Marta,
>
> * SRTool: We might decide to use it again. It allows one to do much but 
> requires constant commitment.
>
> There are many ways to use the SRTool.
>   (a)  The original design was to perform 100% triage of incoming CVEs. This 
> was a business requirement of Wind River, and we have used the SRTool 
> successfully for 4-5 year now.
>   (b)  The main limitation with the SRTool for Yocto Project was the lack of 
> integration with Bugzilla (Ross ran out of time)
>  * This is the crucial other half of the workflow
>  * There is the automatic creation of appropriate defect records for 
> investigation
>  * There is also the automatic tracking of the overall CVE status, both 
> CVEs in progress and the CVEs completed
>  * Wind River has an extension for full integration with Jira, and that 
> saves weeks of work for the CVE management
>   (c) The guiding rule was that CVE management was in the SRTool, but 
> specific defect work was also done in Jira/Bugzilla, for a clean separate of 
> domains
>   (d)  The SRTool has a user model
>  * Together with Bugzilla, it is easy to track single people and even 
> multiple people working on CVEs
>   (e) The SRTool also has the built-on ability to look up the CVE status from 
> other distributions (Red Hat, Debian, ...) so that one can get a peek of 
> existing triages and resolutions
>   (f) The SRTool is build like Toaster on top of Django, so development and 
> debugging skills for Toaster immediate apply
>   (g) Also with the Django base, it is very simple to add any number of 
> modular extensions to support for example CVE Scanner integration
>   (h) The SRTool also has report generation (in text, CSV, and Excel) in 
> addition to email notification support.
>   (i) There is also a "private" model for CVEs under embargo, with strict 
> access control lists.
>
> PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps 
> using it to track and coordinate work will bring immediate benefit.
>
> PROPOSAL 2: I am happy to give you a live demo of Wind River's fully 
> operational SRTool, so you can see all of the bells and whistles in action. I 
> am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific.
>
> PROPOSAL 3: I will start refreshing the YP SRTool repository with my current 
> implementation level from Wind River (with the Wind River specific modules 
> left out of course :-)
>
> David
>
> BTW, 

[OE-core][kirkstone][PATCH 1/1] glibc: Update to latest on stable 2.35 branch

2023-09-27 Thread Soumya via lists.openembedded.org
From: Soumya Sambu 

Adresses CVE-2023-4813, CVE-2023-4806

These are the complete list of changes this brings

* 73d4ce728a Document CVE-2023-4806 and CVE-2023-5156 in NEWS
* 17092c0311 Fix leak in getaddrinfo introduced by the fix for CVE-2023-4806 
[BZ #30843]*
* 762a747fae io: Fix record locking contants for powerpc64 with 
__USE_FILE_OFFSET64
* e3ccb230a9 getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
* 1b9087dcec gethosts: Return EAI_MEMORY on allocation failure
* f5f88f142a gaih_inet: Split result generation into its own function
* a6da106892 gaih_inet: split loopback lookup into its own function
* 8b70d97b08 gaih_inet: make gethosts into a function
* 9098deb96a gaih_inet: separate nss lookup loop into its own function
* ce64e72b7d gaih_inet: Split nscd lookup code into its own function.
* 4897bf7968 gaih_inet: Split simple gethostbyname into its own function
* 571c531b3b gaih_inet: make numeric lookup a separate routine
* 9aad91abe6 gaih_inet: Simplify service resolution
* d02808dee9 getaddrinfo: Fix leak with AI_ALL [BZ #28852]
* f366eaa608 gaih_inet: Simplify canon name resolution
* b126325fc7 nss: Sort tests and tests-container and put one test per line
* 6e867146ee Simplify allocations and fix merge and continue actions [BZ #28931]
* 59ee83b0c2 elf: Move l_init_called_next to old place of l_text_end in link map
* 34b07bdbdd elf: Remove unused l_text_end field from struct link_map
* 02a67e102f elf: Always call destructors in reverse constructor order (bug 
30785)
* aeea91fd15 elf: Do not run constructors for proxy objects
* 1d828d5855 elf: Introduce to _dl_call_fini

Signed-off-by: Soumya Sambu 
---
 meta/recipes-core/glibc/glibc-version.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index f23ceb5a25..c23a43576c 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
 SRCBRANCH ?= "release/2.35/master"
 PV = "2.35"
-SRCREV_glibc ?= "561e9dadc02f46a7ba2190c0a04259583479f6c9"
+SRCREV_glibc ?= "73d4ce728a59deb2fd18969e559769b3f590fac9"
 SRCREV_localedef ?= "794da69788cbf9bf57b59a852f9f11307663fa87"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188294): 
https://lists.openembedded.org/g/openembedded-core/message/188294
Mute This Topic: https://lists.openembedded.org/mt/101613417/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] [Openembedded-architecture] [yocto] Security processes: YP needs

2023-09-27 Thread Marta Rybczynska
Hi David,
Thank you very much for the description and the offer to get a demo.
As discussed yesterday in the call, there are some other people who
seem interested.

> PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps 
> using it to track and coordinate work will bring immediate benefit.

This is the reason I want to test how much time it takes.

> PROPOSAL 2: I am happy to give you a live demo of Wind River's fully 
> operational SRTool, so you can see all of the bells and whistles in action. I 
> am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific.

That would be nice. What about 11am Pacific on tomorrow (28 Sept or
Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific
would work very well for me too :P

> PROPOSAL 3: I will start refreshing the YP SRTool repository with my current 
> implementation level from Wind River (with the Wind River specific modules 
> left out of course :-)

That would be great. I'm going to add the missing file for the test
next week, the tool needs a script to download 2023 data.

Kind regards,
Marta

On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via
lists.openembedded.org
 wrote:
>
> Hi Marta,
>
> * SRTool: We might decide to use it again. It allows one to do much but 
> requires constant commitment.
>
> There are many ways to use the SRTool.
>   (a)  The original design was to perform 100% triage of incoming CVEs. This 
> was a business requirement of Wind River, and we have used the SRTool 
> successfully for 4-5 year now.
>   (b)  The main limitation with the SRTool for Yocto Project was the lack of 
> integration with Bugzilla (Ross ran out of time)
>  * This is the crucial other half of the workflow
>  * There is the automatic creation of appropriate defect records for 
> investigation
>  * There is also the automatic tracking of the overall CVE status, both 
> CVEs in progress and the CVEs completed
>  * Wind River has an extension for full integration with Jira, and that 
> saves weeks of work for the CVE management
>   (c) The guiding rule was that CVE management was in the SRTool, but 
> specific defect work was also done in Jira/Bugzilla, for a clean separate of 
> domains
>   (d)  The SRTool has a user model
>  * Together with Bugzilla, it is easy to track single people and even 
> multiple people working on CVEs
>   (e) The SRTool also has the built-on ability to look up the CVE status from 
> other distributions (Red Hat, Debian, ...) so that one can get a peek of 
> existing triages and resolutions
>   (f) The SRTool is build like Toaster on top of Django, so development and 
> debugging skills for Toaster immediate apply
>   (g) Also with the Django base, it is very simple to add any number of 
> modular extensions to support for example CVE Scanner integration
>   (h) The SRTool also has report generation (in text, CSV, and Excel) in 
> addition to email notification support.
>   (i) There is also a "private" model for CVEs under embargo, with strict 
> access control lists.
>
> PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps 
> using it to track and coordinate work will bring immediate benefit.
>
> PROPOSAL 2: I am happy to give you a live demo of Wind River's fully 
> operational SRTool, so you can see all of the bells and whistles in action. I 
> am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific.
>
> PROPOSAL 3: I will start refreshing the YP SRTool repository with my current 
> implementation level from Wind River (with the Wind River specific modules 
> left out of course :-)
>
> David
>
> BTW, I also support an extension to the SRTool that manages CVE scanning of 
> build images, with hooks to a  number existing CVE scanners (e.g. Trivy) in 
> addition to other vulnerability metrics. This is probably out of scope to YP 
> at this time, but it is perhaps something to grow in to.
>
> -Original Message-
> From: yo...@lists.yoctoproject.org  On Behalf 
> Of Marta Rybczynska via lists.yoctoproject.org
> Sent: Wednesday, September 13, 2023 4:52 AM
> To: yocto-secur...@lists.yoctoproject.org; OE-core 
> ; 
> openembedded-architect...@lists.openembedded.org; yo...@lists.yoctoproject.org
> Cc: Richard Purdie ; Steve Sakoman 
> ; Khem Raj ; 
> mark.ha...@kernel.crashing.org; Ross Burton ; Joshua 
> Watt 
> Subject: [yocto] Security processes: YP needs
>
> Hello,
> I've been working recently on collecting what works and what doesn't
> in YP security processes. The goal is to go forward and define an
> actionable strategy!
>
> Today, I'd like to share with you the summary of what I have heard as
> needs from several people (those in Cc:).
>
> I want the community to comment and tell us what you find important
> and what you'd like to see added or changed from this list.
>
> * CVEs: Visibility if YP is vulnerable or not
>
> People want to be able to check/look up a specific CVE; it might be a
> CVE unrelated to YP

[OE-core][PATCH] python3: add cpython to CVE_PRODUCT

2023-09-27 Thread Chen Qi via lists.openembedded.org
From: Chen Qi 

https://nvd.nist.gov/vuln/detail/CVE-2023-33595 uses 'cpython'.
Although it's currently the only one that uses cpython, let's add
cpython to CVE_PRODUCT, just in case.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/python/python3_3.11.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.11.5.bb 
b/meta/recipes-devtools/python/python3_3.11.5.bb
index 6c624c9d3d..8e023c7dfb 100644
--- a/meta/recipes-devtools/python/python3_3.11.5.bb
+++ b/meta/recipes-devtools/python/python3_3.11.5.bb
@@ -46,7 +46,7 @@ SRC_URI[sha256sum] = 
"85cd12e9cf1d6d5a45f17f7afe1cebe7ee628d3282281c492e86adf636
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar"
 UPSTREAM_CHECK_URI = "https://www.python.org/downloads/source/;
 
-CVE_PRODUCT = "python"
+CVE_PRODUCT = "python cpython"
 
 CVE_STATUS[CVE-2007-4559] = "disputed: Upstream consider this expected 
behaviour"
 CVE_STATUS[CVE-2019-18348] = "not-applicable-config: This is not exploitable 
when glibc has CVE-2016-10739 fixed"
-- 
2.40.0


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