date:20240326

Re: [OE-core][PATCH V2] ovmf: set CVE_PRODUCT and CVE_VERSION

2024-03-26 Thread Chen Qi via lists.openembedded.org


ping

On 3/6/24 14:54, Chen Qi via lists.openembedded.org wrote:

From: Chen Qi 

Set CVE_PRODUCT and CVE_VERSION for ovmf. NVD uses 'edk2' and the
version should be the date only. Here's an example:
https://nvd.nist.gov/vuln/detail/CVE-2023-45232

Signed-off-by: Chen Qi 
---
  meta/recipes-core/ovmf/ovmf_git.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
b/meta/recipes-core/ovmf/ovmf_git.bb
index 3dc031d3b6..5b1353b8e8 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -30,6 +30,9 @@ PV = "edk2-stable202308"
  SRCREV = "819cfc6b42a68790a23509e4fcc58ceb70e1965e"
  UPSTREAM_CHECK_GITTAGREGEX = "(?Pedk2-stable.*)"
  
+CVE_PRODUCT = "edk2"

+CVE_VERSION = "${@d.getVar('PV').split('stable')[1]}"
+
  inherit deploy
  
  PARALLEL_MAKE = ""







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

2024-03-26 Thread wangmy via lists.openembedded.org

From: Wang Mingyu 

0001-generate-glslang-pkg-config.patch
refreshed for 1.3.280.0

License-Update:
===
spirv-headers:License-Update: List all licenses in the root LICENSE file.
vulkan-volk:Copyright year updated to 2024.

Signed-off-by: Wang Mingyu 
---
 .../glslang/0001-generate-glslang-pkg-config.patch | 10 +-
 .../{glslang_1.3.275.0.bb => glslang_1.3.280.0.bb} |  2 +-
 ...headers_1.3.275.0.bb => spirv-headers_1.3.280.0.bb} |  4 ++--
 ...irv-tools_1.3.275.0.bb => spirv-tools_1.3.280.0.bb} |  2 +-
 ...eaders_1.3.275.0.bb => vulkan-headers_1.3.280.0.bb} |  2 +-
 ...-loader_1.3.275.0.bb => vulkan-loader_1.3.280.0.bb} |  4 ++--
 ...an-tools_1.3.275.0.bb => vulkan-tools_1.3.280.0.bb} |  4 ++--
 275.0.bb => vulkan-utility-libraries_1.3.280.0.bb} |  2 +-
 275.0.bb => vulkan-validation-layers_1.3.280.0.bb} |  4 ++--
 ...lkan-volk_1.3.275.0.bb => vulkan-volk_1.3.280.0.bb} |  4 ++--
 10 files changed, 19 insertions(+), 19 deletions(-)
 rename meta/recipes-graphics/glslang/{glslang_1.3.275.0.bb => 
glslang_1.3.280.0.bb} (96%)
 rename meta/recipes-graphics/spir/{spirv-headers_1.3.275.0.bb => 
spirv-headers_1.3.280.0.bb} (84%)
 rename meta/recipes-graphics/spir/{spirv-tools_1.3.275.0.bb => 
spirv-tools_1.3.280.0.bb} (96%)
 rename meta/recipes-graphics/vulkan/{vulkan-headers_1.3.275.0.bb => 
vulkan-headers_1.3.280.0.bb} (95%)
 rename meta/recipes-graphics/vulkan/{vulkan-loader_1.3.275.0.bb => 
vulkan-loader_1.3.280.0.bb} (95%)
 rename meta/recipes-graphics/vulkan/{vulkan-tools_1.3.275.0.bb => 
vulkan-tools_1.3.280.0.bb} (94%)
 rename meta/recipes-graphics/vulkan/{vulkan-utility-libraries_1.3.275.0.bb => 
vulkan-utility-libraries_1.3.280.0.bb} (95%)
 rename meta/recipes-graphics/vulkan/{vulkan-validation-layers_1.3.275.0.bb => 
vulkan-validation-layers_1.3.280.0.bb} (95%)
 rename meta/recipes-graphics/vulkan/{vulkan-volk_1.3.275.0.bb => 
vulkan-volk_1.3.280.0.bb} (89%)

diff --git 
a/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch 
b/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
index 316a57fa4a..e6bb6ec8e3 100644
--- 
a/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
+++ 
b/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
@@ -1,4 +1,4 @@
-From 4cede5edcff96134baf35953d58595c4aa5f1fc5 Mon Sep 17 00:00:00 2001
+From fc33f1cf032a15c07044ef932bc991c346d62d62 Mon Sep 17 00:00:00 2001
 From: Jose Quaresma 
 Date: Sun, 7 Feb 2021 01:30:39 +
 Subject: [PATCH] generate glslang pkg-config
@@ -15,12 +15,12 @@ Signed-off-by: Jose Quaresma 
  create mode 100644 glslang/glslang.pc.cmake.in
 
 diff --git a/glslang/CMakeLists.txt b/glslang/CMakeLists.txt
-index 37eecaad..6974935c 100644
+index e4690f09..8e660bc5 100644
 --- a/glslang/CMakeLists.txt
 +++ b/glslang/CMakeLists.txt
-@@ -251,6 +251,8 @@ if(PROJECT_IS_TOP_LEVEL)
- ")
- install(FILES "${CMAKE_CURRENT_BINARY_DIR}/glslangTargets.cmake" 
DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake)
+@@ -233,6 +233,8 @@ if(GLSLANG_ENABLE_INSTALL)
+ install(TARGETS MachineIndependent EXPORT glslang-targets)
+ install(TARGETS GenericCodeGen EXPORT glslang-targets)
  endif()
 +configure_file(${CMAKE_CURRENT_SOURCE_DIR}/glslang.pc.cmake.in 
${CMAKE_CURRENT_BINARY_DIR}/pkgconfig/glslang.pc @ONLY)
 +install(FILES ${CMAKE_CURRENT_BINARY_DIR}/pkgconfig/glslang.pc 
DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
diff --git a/meta/recipes-graphics/glslang/glslang_1.3.275.0.bb 
b/meta/recipes-graphics/glslang/glslang_1.3.280.0.bb
similarity index 96%
rename from meta/recipes-graphics/glslang/glslang_1.3.275.0.bb
rename to meta/recipes-graphics/glslang/glslang_1.3.280.0.bb
index 2fd1e72a26..637082c719 100644
--- a/meta/recipes-graphics/glslang/glslang_1.3.275.0.bb
+++ b/meta/recipes-graphics/glslang/glslang_1.3.280.0.bb
@@ -8,7 +8,7 @@ HOMEPAGE = 
"https://www.khronos.org/opengles/sdk/tools/Reference-Compiler;
 LICENSE = "BSD-3-Clause & BSD-2-Clause & MIT & Apache-2.0 & 
GPL-3-with-bison-exception"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=2a2b5acd7bc4844964cfda45fe807dc3"
 
-SRCREV = "a91631b260cba3f22858d6c6827511e636c2458a"
+SRCREV = "ee2f5d09eaf8f4e8d0d598bd2172fce290d4ca60"
 SRC_URI = 
"git://github.com/KhronosGroup/glslang.git;protocol=https;branch=main \
file://0001-generate-glslang-pkg-config.patch \
"
diff --git a/meta/recipes-graphics/spir/spirv-headers_1.3.275.0.bb 
b/meta/recipes-graphics/spir/spirv-headers_1.3.280.0.bb
similarity index 84%
rename from meta/recipes-graphics/spir/spirv-headers_1.3.275.0.bb
rename to meta/recipes-graphics/spir/spirv-headers_1.3.280.0.bb
index 598a8fc209..26bfd9c4fa 100644
--- a/meta/recipes-graphics/spir/spirv-headers_1.3.275.0.bb
+++ b/meta/recipes-graphics/spir/spirv-headers_1.3.280.0.bb
@@ -2,9 +2,9 @@ SUMMARY = "Machine-readable files for the SPIR-V Registry"
 SECTION = "graphics"
 HOMEPAGE = "https://www.khronos.org/registry/spir-v;

[OE-core] [PATCH v2] mesa: upgrade 24.0.2 -> 24.0.3

2024-03-26 Thread wangmy via lists.openembedded.org

From: Wang Mingyu 

0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
refreshed for 24.0.3

Signed-off-by: Wang Mingyu 
---
 ...Revert-meson-do-not-pull-in-clc-for-clover.patch | 13 +
 .../mesa/{mesa-gl_24.0.2.bb => mesa-gl_24.0.3.bb}   |  0
 meta/recipes-graphics/mesa/mesa.inc |  2 +-
 .../mesa/{mesa_24.0.2.bb => mesa_24.0.3.bb} |  0
 4 files changed, 6 insertions(+), 9 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_24.0.2.bb => mesa-gl_24.0.3.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_24.0.2.bb => mesa_24.0.3.bb} (100%)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
 
b/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
index f6d95c8982..1711e22585 100644
--- 
a/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
+++ 
b/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
@@ -1,4 +1,4 @@
-From fe4600de549549fbb3033fc1b37904ba6b3fe2af Mon Sep 17 00:00:00 2001
+From 051f41beda540f0ae77b341db01a6de83c9e938a Mon Sep 17 00:00:00 2001
 From: Markus Volk 
 Date: Fri, 8 Mar 2024 15:53:11 +0100
 Subject: [PATCH] Revert "meson: do not pull in clc for clover"
@@ -18,10 +18,10 @@ Signed-off-by: Markus Volk 
  2 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/meson.build b/meson.build
-index 25e92ea5f95..3956e19c08f 100644
+index 2db6185..741b5d1 100644
 --- a/meson.build
 +++ b/meson.build
-@@ -818,6 +818,7 @@ if _opencl != 'disabled'
+@@ -813,6 +813,7 @@ if _opencl != 'disabled'
  error('The Clover OpenCL state tracker requires rtti')
endif
  
@@ -29,7 +29,7 @@ index 25e92ea5f95..3956e19c08f 100644
with_gallium_opencl = true
with_opencl_icd = _opencl == 'icd'
  else
-@@ -842,7 +843,7 @@ if with_gallium_rusticl
+@@ -837,7 +838,7 @@ if with_gallium_rusticl
  endif
  
  dep_clc = null_dep
@@ -39,7 +39,7 @@ index 25e92ea5f95..3956e19c08f 100644
  endif
  
 diff --git a/src/compiler/meson.build b/src/compiler/meson.build
-index 8d73544c6d8..1dae56d1b2b 100644
+index 8d73544..1dae56d 100644
 --- a/src/compiler/meson.build
 +++ b/src/compiler/meson.build
 @@ -79,7 +79,7 @@ subdir('nir')
@@ -51,6 +51,3 @@ index 8d73544c6d8..1dae56d1b2b 100644
subdir('clc')
  endif
  if with_gallium
--- 
-2.44.0
-
diff --git a/meta/recipes-graphics/mesa/mesa-gl_24.0.2.bb 
b/meta/recipes-graphics/mesa/mesa-gl_24.0.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_24.0.2.bb
rename to meta/recipes-graphics/mesa/mesa-gl_24.0.3.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index a8088e6fb6..b08ec873a0 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -23,7 +23,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-Revert-meson-do-not-pull-in-clc-for-clover.patch \
 "
 
-SRC_URI[sha256sum] = 
"94e28a8edad06d8ed2b83eb53f253b9eb5aa62c3080f939702e1b3039b56c9e8"
+SRC_URI[sha256sum] = 
"77aec9a2a37b7d3596ea1640b3cc53d0b5d9b3b52abed89de07e3717e91bfdbe"
 
 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
 
diff --git a/meta/recipes-graphics/mesa/mesa_24.0.2.bb 
b/meta/recipes-graphics/mesa/mesa_24.0.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa_24.0.2.bb
rename to meta/recipes-graphics/mesa/mesa_24.0.3.bb
-- 
2.34.1


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

[OE-core][dunfell][PATCH v2] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

2024-03-26 Thread Vijay Anusuri via lists.openembedded.org

From: Vijay Anusuri 

Upstream-Status: Backport
[https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee287591a1
&
https://github.com/golang/go/commit/bf80213b121074f4ad9b449410a4d13bae5e9be0
&
https://github.com/golang/go/commit/3643147a29352ca2894fd5d0d2069bc4b4335a7e]

Signed-off-by: Vijay Anusuri 
---
 meta/recipes-devtools/go/go-1.14.inc  |   3 +
 .../go/go-1.14/CVE-2023-45289.patch   | 121 
 .../go/go-1.14/CVE-2023-45290.patch   | 271 ++
 .../go/go-1.14/CVE-2024-24785.patch   | 197 +
 4 files changed, 592 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45290.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2024-24785.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index 4fbf9d7590..69b65f3eb2 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -88,6 +88,9 @@ SRC_URI += "\
 file://CVE-2023-45287-pre2.patch \
 file://CVE-2023-45287-pre3.patch \
 file://CVE-2023-45287.patch \
+file://CVE-2023-45289.patch \
+file://CVE-2023-45290.patch \
+file://CVE-2024-24785.patch \
 "
 
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
new file mode 100644
index 00..13d3510504
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
@@ -0,0 +1,121 @@
+From 20586c0dbe03d144f914155f879fa5ee287591a1 Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Thu, 11 Jan 2024 11:31:57 -0800
+Subject: [PATCH] [release-branch.go1.21] net/http, net/http/cookiejar: avoid
+ subdomain matches on IPv6 zones
+
+When deciding whether to forward cookies or sensitive headers
+across a redirect, do not attempt to interpret an IPv6 address
+as a domain name.
+
+Avoids a case where a maliciously-crafted redirect to an
+IPv6 address with a scoped addressing zone could be
+misinterpreted as a within-domain redirect. For example,
+we could interpret "::1%.www.example.com" as a subdomain
+of "www.example.com".
+
+Thanks to Juho Nurminen of Mattermost for reporting this issue.
+
+Fixes CVE-2023-45289
+Fixes #65385
+For #65065
+
+Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2131938
+Reviewed-by: Tatiana Bradley 
+Reviewed-by: Roland Shoemaker 
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2173775
+Reviewed-by: Carlos Amedee 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/569239
+Reviewed-by: Carlos Amedee 
+Auto-Submit: Michael Knyszek 
+TryBot-Bypass: Michael Knyszek 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee287591a1]
+CVE: CVE-2023-45289
+Signed-off-by: Vijay Anusuri 
+---
+ src/net/http/client.go |  6 ++
+ src/net/http/client_test.go|  1 +
+ src/net/http/cookiejar/jar.go  |  7 +++
+ src/net/http/cookiejar/jar_test.go | 10 ++
+ 4 files changed, 24 insertions(+)
+
+diff --git a/src/net/http/client.go b/src/net/http/client.go
+index a496f1c..2031834 100644
+--- a/src/net/http/client.go
 b/src/net/http/client.go
+@@ -973,6 +973,12 @@ func isDomainOrSubdomain(sub, parent string) bool {
+   if sub == parent {
+   return true
+   }
++  // If sub contains a :, it's probably an IPv6 address (and is 
definitely not a hostname).
++  // Don't check the suffix in this case, to avoid matching the contents 
of a IPv6 zone.
++  // For example, "::1%.www.example.com" is not a subdomain of 
"www.example.com".
++  if strings.ContainsAny(sub, ":%") {
++  return false
++  }
+   // If sub is "foo.example.com" and parent is "example.com",
+   // that means sub must end in "."+parent.
+   // Do it without allocating.
+diff --git a/src/net/http/client_test.go b/src/net/http/client_test.go
+index 2b4f53f..442fe35 100644
+--- a/src/net/http/client_test.go
 b/src/net/http/client_test.go
+@@ -1703,6 +1703,7 @@ func TestShouldCopyHeaderOnRedirect(t *testing.T) {
+   {"cookie2", "http://foo.com/;, "http://bar.com/;, false},
+   {"authorization", "http://foo.com/;, "http://bar.com/;, false},
+   {"www-authenticate", "http://foo.com/;, "http://bar.com/;, 
false},
++  {"authorization", "http://foo.com/;, 
"http://[::1%25.foo.com]/;, false},
+ 
+   // But subdomains should work:
+   {"www-authenticate", "http://foo.com/;, "http://foo.com/;, 
true},
+diff --git a/src/net/http/cookiejar/jar.go b/src/net/http/cookiejar/jar.go
+index 9f19917..18cbfc2 100644
+--- a/src/net/http/cookiejar/jar.go

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

2024-03-26 Thread jason.lau via lists.openembedded.org

Hey!

Sorry for the late reply, I was on vacation for a week. 

>-Original Message-
>From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Steve Sakoman via
>lists.openembedded.org
>Sent: Wednesday, March 27, 2024 8:11 AM
>To: MacLeod, Randy 
>Cc: Liu, Haitao ; openembedded-
>c...@lists.openembedded.org
>Subject: Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen
>performac
>
>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.
>
>On Tue, Mar 26, 2024 at 11:34 AM Randy MacLeod via lists.openembedded.org
> wrote:
>>
>> On 2024-03-19 7:23 p.m., Steve Sakoman wrote:
>>
>> On Tue, Mar 19, 2024 at 11:45 AM Randy MacLeod
>>  wrote:
>>
>> Hi Haitao, et al,
>>
>>
>> Summary:
>>
>> I think we could bring these two commits back to kirkstone even though
>> upstream openssl mtc does not plan to do so, at least not without "very good
>reasons".
>>
>> but I have some comments and questions below that I'd like you to respond
>to before sending a v2.
>>
>> ../Randy
>>
>>
>>
>> Typo in the subject:
>>[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen
>> performac should be:
>>[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen
>> performance
>>
>> On 2024-03-18 2:55 a.m., jason.lau via lists.openembedded.org wrote:
>>
>> The ssh-keygen would take a long time to generate the entropy of a key
>>
>> It's best to be more specific.
>>
>> You mentioned in:
>>
>> https://github.com/openssl/openssl/issues/23766
>>
>> that "ssh-keygen (built with openssl3.0) is taking 1-2s to execute whereas in
>openssl3.1 it was hardly half a second"
>>
>> so you should mention that in the commit log.

I will add these comments into the V2 patch. 


>>
>> You should also include a link to the upstream issue you opened to explain
>that:
>>
>>"Performance fixes are in general not eligible for backports to stable 
>> release
>branches.
>> In specific cases an exception could be given by OTC but there would have
>to be very good reasons for such an exception."
>>
>> I saw that comment last week and wondered if we should push harder for
>> upstream to backport these commits but I understand your reluctance to do
>that when it might make sense to just backport here in oe-core.
>>
>> Note that the commits are only part of 3.2.0+:
>>
>> ❯ git tag --contains dd1d7bcb69994d81662e709b0ad838880b943870
>> openssl-3.2.0
>> openssl-3.2.0-alpha1
>> openssl-3.2.0-alpha2
>> openssl-3.2.0-beta1
>> openssl-3.2.1
>>
>> ❯ git tag --contains d2f6e66d2837bff1f5f7636bb2118e3a45c9df61
>> openssl-3.2.0
>> openssl-3.2.0-alpha1
>> openssl-3.2.0-alpha2
>> openssl-3.2.0-beta1
>> openssl-3.2.1
>>
>> so they'd also have to be back-ported to nanbield technically:
>>
>> https://git.openembedded.org/openembedded-core/tree/meta/recipes-
>conne
>> ctivity/openssl/openssl_3.1.4.bb?h=nanbield
>>
>> Steve,
>> Given that nanbield is a week or so away from EOL, is it worth doing that?
>>
>> I'm going to close down changes to nanbield in the next day or so, so
>> there probably isn't time to get such a change in.
>>
>> And I suspect that the kirkstone v2 patch won't make it through
>>
>> Haitao,
>>
>> Steve has NOT merged this to kirkstone:
>>
>> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/k
>> irkstone-nut
>>
>>   https://git.openembedded.org/openembedded-core/log/?h=kirkstone
>
>Correct, I've been waiting for V2
>
>Steve

I will sent the V2 Patch as soon as possible. 


>
>> Please reply to and/or deal with my comments and send a v2.
>>
>> Thanks!
>>
>> ../Randy
>>
>>
>> testing until after the nanbield final release is done, so I don't
>> have an issue with taking it.
>>
>> Steve
>>
>> Note that the original commits were from Nov 2, 2022 so they've had
>> some time to ummm, bake but the 3.2.0 release was 'only' on Nov 23, 2023:
>>https://www.openssl.org/source/old/3.2/index.html
>> so it's got 3 or 4 months of the public being able to test it.
>>
>> I've taken a look at the commits and haven't seen a problem with the
>backport.
>>
>> Haitao,
>> Did you have to adjust the patches at all? If so please explain what you did.
>>

HI Randy, 
I did not adjust the content of patches a lot. 

1. add a function definition for "BN_are_coprime()" in util/libcrypto.num to 
indicate that the function was introduced on openssl 3.1.1

   diff a/util/libcrypto.num b/util/libcrypto.num  (rejected hunks)
   @@ -5432,3 +5432,4 @@ RAND_set0_public? 3_1_0   
EXIST::FUNCTION:
RAND_set0_private   ?  3_1_0   EXIST::FUNCTION:
EVP_MD_CTX_dup  ?  3_1_0   EXIST::FUNCTION:
EVP_CIPHER_CTX_dup  ?  3_1_0   EXIST::FUNCTION:
   +BN_are_coprime  ?  3_1_0   EXIST::FUNCTION:

2. And the second patch could be applied directly without any modification. 


>> Your tests show

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

2024-03-26 Thread Steve Sakoman

On Tue, Mar 26, 2024 at 11:34 AM Randy MacLeod via
lists.openembedded.org
 wrote:
>
> On 2024-03-19 7:23 p.m., Steve Sakoman wrote:
>
> On Tue, Mar 19, 2024 at 11:45 AM Randy MacLeod
>  wrote:
>
> Hi Haitao, et al,
>
>
> Summary:
>
> I think we could bring these two commits back to kirkstone even though 
> upstream openssl mtc
> does not plan to do so, at least not without "very good reasons".
>
> but I have some comments and questions below that I'd like you to respond to 
> before sending a v2.
>
> ../Randy
>
>
>
> Typo in the subject:
>[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac
> should be:
>[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performance
>
> On 2024-03-18 2:55 a.m., jason.lau via lists.openembedded.org wrote:
>
> The ssh-keygen would take a long time to generate the entropy of a key
>
> It's best to be more specific.
>
> You mentioned in:
>
> https://github.com/openssl/openssl/issues/23766
>
> that "ssh-keygen (built with openssl3.0) is taking 1-2s to execute whereas in 
> openssl3.1 it was hardly half a second"
>
> so you should mention that in the commit log.
>
> You should also include a link to the upstream issue you opened to explain 
> that:
>
>"Performance fixes are in general not eligible for backports to stable 
> release branches.
> In specific cases an exception could be given by OTC but there would have 
> to be very good reasons for such an exception."
>
> I saw that comment last week and wondered if we should push harder for 
> upstream to backport these commits but
> I understand your reluctance to do that when it might make sense to just 
> backport here in oe-core.
>
> Note that the commits are only part of 3.2.0+:
>
> ❯ git tag --contains dd1d7bcb69994d81662e709b0ad838880b943870
> openssl-3.2.0
> openssl-3.2.0-alpha1
> openssl-3.2.0-alpha2
> openssl-3.2.0-beta1
> openssl-3.2.1
>
> ❯ git tag --contains d2f6e66d2837bff1f5f7636bb2118e3a45c9df61
> openssl-3.2.0
> openssl-3.2.0-alpha1
> openssl-3.2.0-alpha2
> openssl-3.2.0-beta1
> openssl-3.2.1
>
> so they'd also have to be back-ported to nanbield technically:
>
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssl/openssl_3.1.4.bb?h=nanbield
>
> Steve,
> Given that nanbield is a week or so away from EOL, is it worth doing that?
>
> I'm going to close down changes to nanbield in the next day or so, so
> there probably isn't time to get such a change in.
>
> And I suspect that the kirkstone v2 patch won't make it through
>
> Haitao,
>
> Steve has NOT merged this to kirkstone:
>   
> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut
>
>   https://git.openembedded.org/openembedded-core/log/?h=kirkstone

Correct, I've been waiting for V2

Steve

> Please reply to and/or deal with my comments and send a v2.
>
> Thanks!
>
> ../Randy
>
>
> testing until after the nanbield final release is done, so I don't
> have an issue with taking it.
>
> Steve
>
> Note that the original commits were from Nov 2, 2022 so they've had some time 
> to ummm, bake but
> the 3.2.0 release was 'only' on Nov 23, 2023:
>https://www.openssl.org/source/old/3.2/index.html
> so it's got 3 or 4 months of the public being able to test it.
>
> I've taken a look at the commits and haven't seen a problem with the backport.
>
> Haitao,
> Did you have to adjust the patches at all? If so please explain what you did.
>
> Your tests show that openssl is faster, have you tested for correctness at 
> all?
> Does it make sense to run: test/bntest.c ? Steve will likely run the ptests 
> of course.
>
> Do we need the oneline change: "Fix incorrect error branch in 
> ossl_bn_rsa_fips186_4_derive_prime()"
> from:
> openssl.git on master
> ❯ git log --oneline crypto/bn/bn_rsa_fips186_4.c
> da1c088f59 Copyright year updates
> 835b90a19c Fix incorrect error branch in ossl_bn_rsa_fips186_4_derive_prime()
> d2f6e66d28 Improve FIPS RSA keygen performance.
> dd1d7bcb69 Improve FIPS RSA keygen performance.
>
>
> Are there any other changes to the files touched by these commits that would 
> affect
> the correctness or performance of the code introduced?
>
> ../Randy
>
>
>
> The following commits have fixed the issue.
> https://github.com/openssl/openssl/commit/dd1d7bcb69994d81662e709b0ad838880b943870
> https://github.com/openssl/openssl/commit/d2f6e66d2837bff1f5f7636bb2118e3a45c9df61
>
> Signed-off-by: Haitao Liu 
> ---
>  ...-Improve-FIPS-RSA-keygen-performance.patch | 271 ++
>  ...-Improve-FIPS-RSA-keygen-performance.patch | 185 
>  .../openssl/openssl_3.0.13.bb |   2 +
>  3 files changed, 458 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/openssl/openssl/0001-Improve-FIPS-RSA-keygen-performance.patch
>  create mode 100644 
> meta/recipes-connectivity/openssl/openssl/0002-Improve-FIPS-RSA-keygen-performance.patch
>
> diff --git 
>

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

2024-03-26 Thread Randy MacLeod via lists.openembedded.org


On 2024-03-19 7:23 p.m., Steve Sakoman wrote:

On Tue, Mar 19, 2024 at 11:45 AM Randy MacLeod
  wrote:

Hi Haitao, et al,


Summary:

I think we could bring these two commits back to kirkstone even though upstream 
openssl mtc
does not plan to do so, at least not without "very good reasons".

but I have some comments and questions below that I'd like you to respond to 
before sending a v2.

../Randy



Typo in the subject:
[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac
should be:
[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performance

On 2024-03-18 2:55 a.m., jason.lau via lists.openembedded.org wrote:

The ssh-keygen would take a long time to generate the entropy of a key

It's best to be more specific.

You mentioned in:

https://github.com/openssl/openssl/issues/23766

that "ssh-keygen (built with openssl3.0) is taking 1-2s to execute whereas in 
openssl3.1 it was hardly half a second"

so you should mention that in the commit log.

You should also include a link to the upstream issue you opened to explain that:

"Performance fixes are in general not eligible for backports to stable 
release branches.
 In specific cases an exception could be given by OTC but there would have to be 
very good reasons for such an exception."

I saw that comment last week and wondered if we should push harder for upstream 
to backport these commits but
I understand your reluctance to do that when it might make sense to just 
backport here in oe-core.

Note that the commits are only part of 3.2.0+:

❯ git tag --contains dd1d7bcb69994d81662e709b0ad838880b943870
openssl-3.2.0
openssl-3.2.0-alpha1
openssl-3.2.0-alpha2
openssl-3.2.0-beta1
openssl-3.2.1

❯ git tag --contains d2f6e66d2837bff1f5f7636bb2118e3a45c9df61
openssl-3.2.0
openssl-3.2.0-alpha1
openssl-3.2.0-alpha2
openssl-3.2.0-beta1
openssl-3.2.1

so they'd also have to be back-ported to nanbield technically:

https://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssl/openssl_3.1.4.bb?h=nanbield

Steve,
Given that nanbield is a week or so away from EOL, is it worth doing that?

I'm going to close down changes to nanbield in the next day or so, so
there probably isn't time to get such a change in.

And I suspect that the kirkstone v2 patch won't make it through


Haitao,

Steve has NOT merged this to kirkstone:
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut

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


Please reply to and/or deal with my comments and send a v2.

Thanks!

../Randy



testing until after the nanbield final release is done, so I don't
have an issue with taking it.

Steve


Note that the original commits were from Nov 2, 2022 so they've had some time 
to ummm, bake but
the 3.2.0 release was 'only' on Nov 23, 2023:
https://www.openssl.org/source/old/3.2/index.html
so it's got 3 or 4 months of the public being able to test it.

I've taken a look at the commits and haven't seen a problem with the backport.

Haitao,
Did you have to adjust the patches at all? If so please explain what you did.

Your tests show that openssl is faster, have you tested for correctness at all?
Does it make sense to run: test/bntest.c ? Steve will likely run the ptests of 
course.

Do we need the oneline change: "Fix incorrect error branch in 
ossl_bn_rsa_fips186_4_derive_prime()"
from:
openssl.git on master
❯ git log --oneline crypto/bn/bn_rsa_fips186_4.c
da1c088f59 Copyright year updates
835b90a19c Fix incorrect error branch in ossl_bn_rsa_fips186_4_derive_prime()
d2f6e66d28 Improve FIPS RSA keygen performance.
dd1d7bcb69 Improve FIPS RSA keygen performance.


Are there any other changes to the files touched by these commits that would 
affect
the correctness or performance of the code introduced?

../Randy



The following commits have fixed the issue.
https://github.com/openssl/openssl/commit/dd1d7bcb69994d81662e709b0ad838880b943870
https://github.com/openssl/openssl/commit/d2f6e66d2837bff1f5f7636bb2118e3a45c9df61

Signed-off-by: Haitao Liu
---
  ...-Improve-FIPS-RSA-keygen-performance.patch | 271 ++
  ...-Improve-FIPS-RSA-keygen-performance.patch | 185 
  .../openssl/openssl_3.0.13.bb |   2 +
  3 files changed, 458 insertions(+)
  create mode 100644 
meta/recipes-connectivity/openssl/openssl/0001-Improve-FIPS-RSA-keygen-performance.patch
  create mode 100644 
meta/recipes-connectivity/openssl/openssl/0002-Improve-FIPS-RSA-keygen-performance.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl/0001-Improve-FIPS-RSA-keygen-performance.patch
 
b/meta/recipes-connectivity/openssl/openssl/0001-Improve-FIPS-RSA-keygen-performance.patch
new file mode 100644
index 00..aed0e1a5c1
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssl/openssl/0001-Improve-FIPS-RSA-keygen-performance.patch
@@ -0,0 +1,271 @@
+From a940dfa152707ba82f3efc2c147f6313c28f7662 Mon Sep 17 00:00:00 2001

[OE-core] OpenEmbedded Happy Hour March 27 5pm/1700 UTC

2024-03-26 Thread Denys Dmytriyenko

All,

A friendly reminder - our regular monthly OpenEmbedded Happy Hour 
is coming up tomorrow, on March 27 for Europe/Americas timezones 
@ 1700/5pm UTC (1pm ET/10am PT)

https://www.openembedded.org/wiki/Calendar
https://www.openembedded.org/wiki/Happy_Hours
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+March+27=20240327T17

Best regards,
Denys Dmytriyenko
OpenEmbedded Board of Directors

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197540): 
https://lists.openembedded.org/g/openembedded-core/message/197540
Mute This Topic: https://lists.openembedded.org/mt/105164525/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][RFC][PATCHv2] glib-2.0: update 2.78.4 -> 2.80.0

2024-03-26 Thread Alexander Kanavin

On Wed, 20 Mar 2024 at 12:43, Ross Burton  wrote:
> > and adding that depend (or using inherit gobject-introspection) caused 
> > circular dependency
>
> Indeed.  My branch has a glib-initial to break that cycle, but it wasn’t 
> quite working right (and upstream were still changing things).

I just took a look at this and ugh. Upstream should just merge g-i and
glib into one source tree, and then figure out the correct build
sequence.

I think we can avoid glib-initial by building and installing glib as
usual (with introspection turned off), then building g-i, then
building/installing only the introspection data from glib. This needs
confirmation that the introspection flag only affects those parts, and
not libraries themselves, and perhaps a new build flag
'introspection-only' or similar to avoid unneeded library builds.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197539): 
https://lists.openembedded.org/g/openembedded-core/message/197539
Mute This Topic: https://lists.openembedded.org/mt/105042037/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 v1 1/2] perf: fix build with latest kernel

2024-03-26 Thread Bruce Ashfield

On Tue, Mar 26, 2024 at 1:46 PM Bruce Ashfield 
wrote:

>
>
> On Mon, Mar 25, 2024 at 6:21 AM  wrote:
>
>> From: Max Krummenacher 
>>
>> Kernel commit 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for
>> perf_event programs") added with 6.9-rc1
>> tools/include/uapi/asm/bpf_perf_event.h
>> which for arc, arm64, loongarch, riscv and s390 includes headers from
>> the arch/${ARCH}/... directories.
>> Thus the build in OE fails as those headers are not present.
>>
>> Fix this by additioanly copying all files in arch/${ARCH}/include/.
>>
>> Fixes:
>> ERROR: perf-1.0-r0 do_compile: oe_runmake failed
>> | In file included from
>> work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/linux/bpf_perf_event.h:11,
>> |  from libbpf.c:36:
>> |
>> work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/asm/bpf_perf_event.h:2:10:
>> fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such
>> file or directory
>> | 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h"
>> |   |  ^~~~
>>
>> Signed-off-by: Max Krummenacher 
>> ---
>>  meta/recipes-kernel/perf/perf.bb | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/
>> perf.bb
>> index 4f26813de0..6408c65462 100644
>> --- a/meta/recipes-kernel/perf/perf.bb
>> +++ b/meta/recipes-kernel/perf/perf.bb
>> @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \
>>   tools/scripts \
>>   scripts/ \
>>   arch/arm64/tools \
>> + arch/${ARCH}/include \
>>
>
> We've always tried to stay within the tools/ source umbrella since we
> really
> don't want to copy any more of the kernel than we have to, since
> otherwise,
> we might as well go back to simplifying things and just building against
> the
> entire kernel source tree.
>
> I'd like to see if there's a way that we could limit this to the uapi (and
> hence
> use our uapi headers), and avoid needing to make the copy. If we need a
> copy, then being as specific as possible would be the goal.
>


I meant to also add that I'm not talking about the libc-headers for the
uapi bits, as they are not tracking the latest kernel by design. Although
it would be interesting to see how perf does treat the older uapi against
the new kernel, so we can document the tested combinations.

Bruce



>
> I'm not moving linux-yocto-dev to the latest -dev until next week, but I
> can
> look into this more then.
>
> Bruce
>
>
>
>>   arch/${ARCH}/Makefile \
>>  "
>>
>> --
>> 2.42.0
>>
>>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197538): 
https://lists.openembedded.org/g/openembedded-core/message/197538
Mute This Topic: https://lists.openembedded.org/mt/105135063/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 v1 1/2] perf: fix build with latest kernel

2024-03-26 Thread Bruce Ashfield

On Mon, Mar 25, 2024 at 6:21 AM  wrote:

> From: Max Krummenacher 
>
> Kernel commit 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for
> perf_event programs") added with 6.9-rc1
> tools/include/uapi/asm/bpf_perf_event.h
> which for arc, arm64, loongarch, riscv and s390 includes headers from
> the arch/${ARCH}/... directories.
> Thus the build in OE fails as those headers are not present.
>
> Fix this by additioanly copying all files in arch/${ARCH}/include/.
>
> Fixes:
> ERROR: perf-1.0-r0 do_compile: oe_runmake failed
> | In file included from
> work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/linux/bpf_perf_event.h:11,
> |  from libbpf.c:36:
> |
> work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/asm/bpf_perf_event.h:2:10:
> fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such
> file or directory
> | 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h"
> |   |  ^~~~
>
> Signed-off-by: Max Krummenacher 
> ---
>  meta/recipes-kernel/perf/perf.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/
> perf.bb
> index 4f26813de0..6408c65462 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \
>   tools/scripts \
>   scripts/ \
>   arch/arm64/tools \
> + arch/${ARCH}/include \
>

We've always tried to stay within the tools/ source umbrella since we really
don't want to copy any more of the kernel than we have to, since otherwise,
we might as well go back to simplifying things and just building against the
entire kernel source tree.

I'd like to see if there's a way that we could limit this to the uapi (and
hence
use our uapi headers), and avoid needing to make the copy. If we need a
copy, then being as specific as possible would be the goal.

I'm not moving linux-yocto-dev to the latest -dev until next week, but I
can
look into this more then.

Bruce



>   arch/${ARCH}/Makefile \
>  "
>
> --
> 2.42.0
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197537): 
https://lists.openembedded.org/g/openembedded-core/message/197537
Mute This Topic: https://lists.openembedded.org/mt/105135063/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 v1 2/2] perf: tests: fix qa error, missing perl

2024-03-26 Thread Richard Purdie

On Mon, 2024-03-25 at 11:20 +0100, Max Krummenacher wrote:
> From: Max Krummenacher 
> 
> Kernel commit 61d348f1e96f ("perf testsuite: Add common output checking
> helpers") added with 6.9-rc1 added addional testscripts written in perl.
> 
> Fixes:
> > ERROR: perf-1.0-r0 do_package_qa: QA Issue: 
> > /usr/libexec/perf-core/tests/shell/common/check_no_patterns_found.pl 
> > contained in package perf-tests requires /usr/bin/perl, but no providers 
> > found in RDEPENDS:perf-tests? [file-rdeps]
> 
> Signed-off-by: Max Krummenacher 
> ---
>  meta/recipes-kernel/perf/perf.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 6408c65462..4b6834e614 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -383,7 +383,7 @@ RDEPENDS:${PN} += "elfutils bash"
>  RDEPENDS:${PN}-archive =+ "bash"
>  RDEPENDS:${PN}-python =+ "bash python3 python3-modules 
> ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
>  RDEPENDS:${PN}-perl =+ "bash perl perl-modules"
> -RDEPENDS:${PN}-tests =+ "python3 bash"
> +RDEPENDS:${PN}-tests =+ "perl python3 bash"
>  
>  RSUGGESTS:${PN} += "${PN}-archive ${PN}-tests \
>  ${@bb.utils.contains('PACKAGECONFIG', 'perl', 
> '${PN}-perl', '', d)} \

Does perf avoid perl dependencies currently? Would it make more sense
to put that script in ${PN}-perl?

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197536): 
https://lists.openembedded.org/g/openembedded-core/message/197536
Mute This Topic: https://lists.openembedded.org/mt/105135067/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 06/34] glib-networking: upgrade 2.78.1 -> 2.80.0

2024-03-26 Thread Alexandre Belloni via lists.openembedded.org

This causes ptest failures:

Failed ptests:
{'glib-networking': ['glib-networking/connection-gnutls.test',
 'glib-networking/file-database-gnutls.test']}

(/usr/libexec/installed-tests/glib-networking/file-database-gnutls:400): 
GLib-Net-WARNING **: 10:09:00.679: Failed to load TLS database: System trust 
contains zero trusted certificates; please investigate your GnuTLS configuration
FAIL: glib-networking/file-database-gnutls.test (Child process killed by signal 
5)
Running test: glib-networking/connection-gnutls.test

(/usr/libexec/installed-tests/glib-networking/connection-gnutls:402): 
GLib-Net-WARNING **: 10:09:00.693: Failed to load TLS database: System trust 
contains zero trusted certificates; please investigate your GnuTLS configuration
FAIL: glib-networking/connection-gnutls.test (Child process killed by signal 5)
Running test: glib-networking/certificate-gnutls.test

I guess the ptests need ca-certificates.


On 26/03/2024 08:34:24+0800, wangmy via lists.openembedded.org wrote:
> From: Wang Mingyu 
> 
> Changelog:
> ===
> - Mark plugin functions as exports on Windows
> - GnuTLS: fix improper use of IP address in SNI extension
> - GnuTLS: major performance improvement: reduce unnecessary trust list 
> creation
> - OpenSSL: properly handle BIO_CTRL_EOF
> - GnuTLS: Add warning when system has no trusted certificates
> - OpenSSL: Fix bug when populating trust store
> - Fix license on dtls-connection.c test
> - Updated translations
> 
> Signed-off-by: Wang Mingyu 
> ---
>  .../{glib-networking_2.78.1.bb => glib-networking_2.80.0.bb}| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-core/glib-networking/{glib-networking_2.78.1.bb => 
> glib-networking_2.80.0.bb} (95%)
> 
> diff --git a/meta/recipes-core/glib-networking/glib-networking_2.78.1.bb 
> b/meta/recipes-core/glib-networking/glib-networking_2.80.0.bb
> similarity index 95%
> rename from meta/recipes-core/glib-networking/glib-networking_2.78.1.bb
> rename to meta/recipes-core/glib-networking/glib-networking_2.80.0.bb
> index 5060d9fd7a..c8a1355548 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.78.1.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.80.0.bb
> @@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=4fbd65380cdd255951079008b364516c \
>  SECTION = "libs"
>  DEPENDS = "glib-2.0-native glib-2.0"
>  
> -SRC_URI[archive.sha256sum] = 
> "e48f2ddbb049832cbb09230529c5e45daca9f0df0eda325f832f7379859bf09f"
> +SRC_URI[archive.sha256sum] = 
> "d8f4f1aab213179ae3351617b59dab5de6bcc9e785021eee178998ebd4bb3acf"
>  
>  # Upstream note that for the openssl backend, half the tests where this 
> backend don't return
>  # the expected error code or don't work as expected so default to gnutls
> -- 
> 2.34.1
> 

> 
> 
> 


-- 
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 (#197535): 
https://lists.openembedded.org/g/openembedded-core/message/197535
Mute This Topic: https://lists.openembedded.org/mt/105150499/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Status 26 March 2024 (WW13)

2024-03-26 Thread Stephen Jolley

Current Dev Position: YP 5.0 M4 - Final Release

Next Deadline: 1st April 2024 YP 5.0 M4 build

Next Team Meetings:

   -

   Bug Triage meeting Thursday March 28th at 7:30 am PST (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday March 26th at 8 am PST (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   YP 5.0 M3 has been released.
   -

   YP 4.0.17 is under review and due for release.
   -

   Steve is taking patches for Dunfell until around April 8 in preparation
   for an April 15 build. This will be the last release of dunfell.
   -

   There was a regression on beaglebone in 5.0 M3 where X11 wasn’t working
   but this has been fixed in master ready for the release.
   -

   A key worry now is the documentation for the release, especially given
   it is an LTS. There are emails on the docs list about this, help is much
   appreciated.
   -

   For M4, we are still hoping to transition to a different public hash
   equivalence server before release. We have stopped taking general point
   release upgrades to recipes unless there is a security or other key reason
   to take them. The key remaining fix needed before building is for the opkg
   lock issue.
   -

   The opkg lock issue is now understood but the best fix is still under
   discussion/ development.
   -

   One set of the problematic autobuilder failures was tracked down to a
   queued but  unmerged bitbake patch. There are other intermittent issues
   which still need to be root caused, at least one failure was also due to
   system load issues.
   -

   We continue to watch the NIST NVD (CVE database) issue and await further
   information about what the future holds there (https://nvd.nist.gov/  -
   “You will temporarily see delays in analysis efforts during this
   transition”)


Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: devtool, toaster, wic, oeqa,
   autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help
   is welcome in trying to better look after these components!
   -

   There are bugs identified as possible for newcomers to the project:
   https://wiki.yoctoproject.org/wiki/Newcomers
   -

   There are bugs that are currently unassigned for YP 5.0. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium+_5.0_Unassigned_Enhancements/Bugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.
   -

   Regarding bugs, even if you can’t fix a bug, submitting a failing test
   case that can reproduce the issue significantly improves the chances it
   might get fixed.


YP 5.0 Milestone Dates:

   -

   YP 5.0 M3 is released.
   -

   YP 5.0 M4 build date  2024/04/01
   -

   YP 5.0 M4 Release date 2024/04/30


Upcoming dot releases:

   -

   YP 4.0.17 is out of QA.
   -

   YP 4.3.4 build date 2024/03/25
   -

   YP 4.3.4 Release date 2024/04/05
   -

   YP 3.1.33 build date 2024/04/15
   -

   YP 3.1.33 Release date 2024/04/26
   -

   YP 4.0.18 build date 2024/04/22
   -

   YP 4.0.18 Release date 2024/05/03
   -

   YP 4.0.19 build date 2024/06/03
   -

   YP 4.0.19 Release date 2024/06/14


Tracking Metrics:

   -

   WDD 2703 (last week 2706) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

  Total patches found: 1156 (last week 1148)
  -

  Patches in the Pending State: 249 (22%) [last week 249 (22%)]
  -

   https://autobuilder.yocto.io/pub/non-release/patchmetrics/


The Yocto Project’s technical governance is through its Technical Steering
Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at:
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this
weekly status update, let us know!]

Thanks,



*Stephen K. Jolley*

*Yocto Project Program

Re: [OE-core][dunfell 11/12] linux-firmware: upgrade 20231211 -> 20240220

2024-03-26 Thread Bartosz Golaszewski

On Tue, Mar 26, 2024 at 11:56 AM Bartosz Golaszewski  wrote:
>
> On Wed, Mar 20, 2024 at 5:44 PM Steve Sakoman  wrote:
> >
> > From: Alexander Kanavin 
> >
> > License-Update: additional files
> >
> > Signed-off-by: Alexander Kanavin 
> > Signed-off-by: Richard Purdie 
> > (cherry picked from commit add81ef0299ea5260f9bdc59ffc8f5cc0e74276f)
> > Signed-off-by: Steve Sakoman 
> > ---
> >  ...{linux-firmware_20231211.bb => linux-firmware_20240220.bb} | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >  rename meta/recipes-kernel/linux-firmware/{linux-firmware_20231211.bb => 
> > linux-firmware_20240220.bb} (99%)
> >
> > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
> > b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> > similarity index 99%
> > rename from meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> > rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> > index 3f201d853f..873ba9cdf0 100644
> > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> > @@ -134,7 +134,7 @@ LIC_FILES_CHKSUM = 
> > "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
> >  "
> >  # WHENCE checksum is defined separately to ease overriding it if
> >  # class-devupstream is selected.
> > -WHENCE_CHKSUM  = "3113c4ea08e5171555f3bf49eceb5b07"
> > +WHENCE_CHKSUM  = "a344e6c28970fc7daafa81c10247aeb6"
> >
> >  # These are not common licenses, set NO_GENERIC_LICENSE for them
> >  # so that the license files will be copied from fetched source
> > @@ -212,7 +212,7 @@ SRC_URI:class-devupstream = 
> > "git://git.kernel.org/pub/scm/linux/kernel/git/firmw
> >  # Pin this to the 20220509 release, override this in local.conf
> >  SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
> >
> > -SRC_URI[sha256sum] = 
> > "96af7e4b5eabd37869cdb3dcbb7ab36911106d39b76e799fa1caab16a9dbe8bb"
> > +SRC_URI[sha256sum] = 
> > "bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7"
> >
> >  inherit allarch
> >
> > --
> > 2.34.1
> >
> >
>
> I already sent a patch upgrading linux-firmware to the most recent tag[1].
>
> Bart
>
> [1] https://lore.kernel.org/all/20240314100610.21815-1-b...@bgdev.pl/T/

Ah, nevermind, I didn't see this is for dunfell.

Bart

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197533): 
https://lists.openembedded.org/g/openembedded-core/message/197533
Mute This Topic: https://lists.openembedded.org/mt/105048447/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 11/12] linux-firmware: upgrade 20231211 -> 20240220

2024-03-26 Thread Bartosz Golaszewski

On Wed, Mar 20, 2024 at 5:44 PM Steve Sakoman  wrote:
>
> From: Alexander Kanavin 
>
> License-Update: additional files
>
> Signed-off-by: Alexander Kanavin 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit add81ef0299ea5260f9bdc59ffc8f5cc0e74276f)
> Signed-off-by: Steve Sakoman 
> ---
>  ...{linux-firmware_20231211.bb => linux-firmware_20240220.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-kernel/linux-firmware/{linux-firmware_20231211.bb => 
> linux-firmware_20240220.bb} (99%)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
> b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> similarity index 99%
> rename from meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> index 3f201d853f..873ba9cdf0 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb
> @@ -134,7 +134,7 @@ LIC_FILES_CHKSUM = 
> "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
>  "
>  # WHENCE checksum is defined separately to ease overriding it if
>  # class-devupstream is selected.
> -WHENCE_CHKSUM  = "3113c4ea08e5171555f3bf49eceb5b07"
> +WHENCE_CHKSUM  = "a344e6c28970fc7daafa81c10247aeb6"
>
>  # These are not common licenses, set NO_GENERIC_LICENSE for them
>  # so that the license files will be copied from fetched source
> @@ -212,7 +212,7 @@ SRC_URI:class-devupstream = 
> "git://git.kernel.org/pub/scm/linux/kernel/git/firmw
>  # Pin this to the 20220509 release, override this in local.conf
>  SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
>
> -SRC_URI[sha256sum] = 
> "96af7e4b5eabd37869cdb3dcbb7ab36911106d39b76e799fa1caab16a9dbe8bb"
> +SRC_URI[sha256sum] = 
> "bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7"
>
>  inherit allarch
>
> --
> 2.34.1
>
>

I already sent a patch upgrading linux-firmware to the most recent tag[1].

Bart

[1] https://lore.kernel.org/all/20240314100610.21815-1-b...@bgdev.pl/T/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197532): 
https://lists.openembedded.org/g/openembedded-core/message/197532
Mute This Topic: https://lists.openembedded.org/mt/105048447/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] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

2024-03-26 Thread Anuj Mittal

On Tue, 2024-03-26 at 13:09 +0530, Vijay Anusuri via
lists.openembedded.org wrote:
> +++ b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
> @@ -0,0 +1,121 @@
> +From 20586c0dbe03d144f914155f879fa5ee287591a1 Mon Sep 17 00:00:00
> 2001
> +From: Damien Neil 
> +Date: Thu, 11 Jan 2024 11:31:57 -0800
> +Subject: [PATCH] [release-branch.go1.21] net/http,
> net/http/cookiejar: avoid
> + subdomain matches on IPv6 zones
> +
> +When deciding whether to forward cookies or sensitive headers
> +across a redirect, do not attempt to interpret an IPv6 address
> +as a domain name.
> +
> +Avoids a case where a maliciously-crafted redirect to an
> +IPv6 address with a scoped addressing zone could be
> +misinterpreted as a within-domain redirect. For example,
> +we could interpret "::1%.www.example.com" as a subdomain
> +of "www.example.com".
> +
> +Thanks to Juho Nurminen of Mattermost for reporting this issue.
> +
> +Fixes CVE-2023-45289
> +Fixes #65385
> +For #65065
> +
> +Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599
> +Reviewed-on:
> https://team-review.git.corp.google.com/c/golang/go-private/+/2131938
> +Reviewed-by: Tatiana Bradley 
> +Reviewed-by: Roland Shoemaker 
> +Reviewed-on:
> https://team-review.git.corp.google.com/c/golang/go-private/+/2173775
> +Reviewed-by: Carlos Amedee 
> +Reviewed-on: https://go-review.googlesource.com/c/go/+/569239
> +Reviewed-by: Carlos Amedee 
> +Auto-Submit: Michael Knyszek 
> +TryBot-Bypass: Michael Knyszek 
> +
> +Upstream-Status: Backport
> [https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee
> 287591a1]
> +CVE: CVE-45289

Incorrect CVE number here ...

Thanks,

Anuj

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197531): 
https://lists.openembedded.org/g/openembedded-core/message/197531
Mute This Topic: https://lists.openembedded.org/mt/105154485/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 17/34] mesa: upgrade 24.0.2 -> 24.0.3

2024-03-26 Thread Alexander Kanavin

Don't forget the mesa-gl recipe in those updates.

Alex

On Tue, 26 Mar 2024 at 01:37, wangmy via lists.openembedded.org
 wrote:
>
> From: Wang Mingyu 
>
> 0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
> refreshed for 24.0.3
>
> Signed-off-by: Wang Mingyu 
> ---
>  ...Revert-meson-do-not-pull-in-clc-for-clover.patch | 13 +
>  meta/recipes-graphics/mesa/mesa.inc |  2 +-
>  .../mesa/{mesa_24.0.2.bb => mesa_24.0.3.bb} |  0
>  3 files changed, 6 insertions(+), 9 deletions(-)
>  rename meta/recipes-graphics/mesa/{mesa_24.0.2.bb => mesa_24.0.3.bb} (100%)
>
> diff --git 
> a/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
>  
> b/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
> index f6d95c8982..1711e22585 100644
> --- 
> a/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
> +++ 
> b/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
> @@ -1,4 +1,4 @@
> -From fe4600de549549fbb3033fc1b37904ba6b3fe2af Mon Sep 17 00:00:00 2001
> +From 051f41beda540f0ae77b341db01a6de83c9e938a Mon Sep 17 00:00:00 2001
>  From: Markus Volk 
>  Date: Fri, 8 Mar 2024 15:53:11 +0100
>  Subject: [PATCH] Revert "meson: do not pull in clc for clover"
> @@ -18,10 +18,10 @@ Signed-off-by: Markus Volk 
>   2 files changed, 3 insertions(+), 2 deletions(-)
>
>  diff --git a/meson.build b/meson.build
> -index 25e92ea5f95..3956e19c08f 100644
> +index 2db6185..741b5d1 100644
>  --- a/meson.build
>  +++ b/meson.build
> -@@ -818,6 +818,7 @@ if _opencl != 'disabled'
> +@@ -813,6 +813,7 @@ if _opencl != 'disabled'
>   error('The Clover OpenCL state tracker requires rtti')
> endif
>
> @@ -29,7 +29,7 @@ index 25e92ea5f95..3956e19c08f 100644
> with_gallium_opencl = true
> with_opencl_icd = _opencl == 'icd'
>   else
> -@@ -842,7 +843,7 @@ if with_gallium_rusticl
> +@@ -837,7 +838,7 @@ if with_gallium_rusticl
>   endif
>
>   dep_clc = null_dep
> @@ -39,7 +39,7 @@ index 25e92ea5f95..3956e19c08f 100644
>   endif
>
>  diff --git a/src/compiler/meson.build b/src/compiler/meson.build
> -index 8d73544c6d8..1dae56d1b2b 100644
> +index 8d73544..1dae56d 100644
>  --- a/src/compiler/meson.build
>  +++ b/src/compiler/meson.build
>  @@ -79,7 +79,7 @@ subdir('nir')
> @@ -51,6 +51,3 @@ index 8d73544c6d8..1dae56d1b2b 100644
> subdir('clc')
>   endif
>   if with_gallium
> ---
> -2.44.0
> -
> diff --git a/meta/recipes-graphics/mesa/mesa.inc 
> b/meta/recipes-graphics/mesa/mesa.inc
> index a8088e6fb6..b08ec873a0 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -23,7 +23,7 @@ SRC_URI = 
> "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
> file://0001-Revert-meson-do-not-pull-in-clc-for-clover.patch \
>  "
>
> -SRC_URI[sha256sum] = 
> "94e28a8edad06d8ed2b83eb53f253b9eb5aa62c3080f939702e1b3039b56c9e8"
> +SRC_URI[sha256sum] = 
> "77aec9a2a37b7d3596ea1640b3cc53d0b5d9b3b52abed89de07e3717e91bfdbe"
>
>  UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
>
> diff --git a/meta/recipes-graphics/mesa/mesa_24.0.2.bb 
> b/meta/recipes-graphics/mesa/mesa_24.0.3.bb
> similarity index 100%
> rename from meta/recipes-graphics/mesa/mesa_24.0.2.bb
> rename to meta/recipes-graphics/mesa/mesa_24.0.3.bb
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197530): 
https://lists.openembedded.org/g/openembedded-core/message/197530
Mute This Topic: https://lists.openembedded.org/mt/105150531/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 07/34] glslang: upgrade 1.3.275.0 -> 1.3.280.0

2024-03-26 Thread Alexander Kanavin

This and the spirv recipes should be updated in lockstep with vulkan
recipes to keep them all at the same version. Please note that this is
written in the comments in all those recipes.

Alex


On Tue, 26 Mar 2024 at 01:35, wangmy via lists.openembedded.org
 wrote:
>
> From: Wang Mingyu 
>
> 0001-generate-glslang-pkg-config.patch
> refreshed for 1.3.280.0.
>
> Changelog:
> ==
> * Add a new --abosute-path command-line option to output absolute paths in 
> error messages
> * Support GL_EXT_control_flow_attributes2
> * Support GL_ARB_shading_language_include
> * Fix HLSL built-in passthrough via inout
> * Enable -Wimplicit-fallthrough and fix warnings
> * Fix -Wmissing_field_initializer warnings
> * Document supported dependencies in known_good.json
> * Clear spirv vector before use
> * Emit debug info for accelerationStructure and rayQuery variables
> * Support NV_shader_atomic_fp16_vector
> * Support GL_EXT_expect_assume_support
> * Allow external control of whether glslang will be tested or installed
> * Improve debug source and line info
> * Support GL_KHR_shader_subgroup_rotate
> * Add SPIRV-Tools-opt dependency if ENABLE_OPT
> * Support EXT_shader_quad_control
> * Add OpAssumeTrueKHR and OpExpectKHR
> * Support GL_EXT_maximal_reconvergence
> * Remove generation of deprecated Target.cmake files
> * Fix array size of gl_SampleMask and gl_SampleMaskIn
> * Support GL_ARB_texture_multisample_extension
> * Emit DebugTypePointer when non-semantic debug info is enabled
>
> Signed-off-by: Wang Mingyu 
> ---
>  .../glslang/0001-generate-glslang-pkg-config.patch | 10 +-
>  .../{glslang_1.3.275.0.bb => glslang_1.3.280.0.bb} |  2 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
>  rename meta/recipes-graphics/glslang/{glslang_1.3.275.0.bb => 
> glslang_1.3.280.0.bb} (96%)
>
> diff --git 
> a/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
>  
> b/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
> index 316a57fa4a..e6bb6ec8e3 100644
> --- 
> a/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
> +++ 
> b/meta/recipes-graphics/glslang/glslang/0001-generate-glslang-pkg-config.patch
> @@ -1,4 +1,4 @@
> -From 4cede5edcff96134baf35953d58595c4aa5f1fc5 Mon Sep 17 00:00:00 2001
> +From fc33f1cf032a15c07044ef932bc991c346d62d62 Mon Sep 17 00:00:00 2001
>  From: Jose Quaresma 
>  Date: Sun, 7 Feb 2021 01:30:39 +
>  Subject: [PATCH] generate glslang pkg-config
> @@ -15,12 +15,12 @@ Signed-off-by: Jose Quaresma 
>   create mode 100644 glslang/glslang.pc.cmake.in
>
>  diff --git a/glslang/CMakeLists.txt b/glslang/CMakeLists.txt
> -index 37eecaad..6974935c 100644
> +index e4690f09..8e660bc5 100644
>  --- a/glslang/CMakeLists.txt
>  +++ b/glslang/CMakeLists.txt
> -@@ -251,6 +251,8 @@ if(PROJECT_IS_TOP_LEVEL)
> - ")
> - install(FILES "${CMAKE_CURRENT_BINARY_DIR}/glslangTargets.cmake" 
> DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake)
> +@@ -233,6 +233,8 @@ if(GLSLANG_ENABLE_INSTALL)
> + install(TARGETS MachineIndependent EXPORT glslang-targets)
> + install(TARGETS GenericCodeGen EXPORT glslang-targets)
>   endif()
>  +configure_file(${CMAKE_CURRENT_SOURCE_DIR}/glslang.pc.cmake.in 
> ${CMAKE_CURRENT_BINARY_DIR}/pkgconfig/glslang.pc @ONLY)
>  +install(FILES ${CMAKE_CURRENT_BINARY_DIR}/pkgconfig/glslang.pc 
> DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
> diff --git a/meta/recipes-graphics/glslang/glslang_1.3.275.0.bb 
> b/meta/recipes-graphics/glslang/glslang_1.3.280.0.bb
> similarity index 96%
> rename from meta/recipes-graphics/glslang/glslang_1.3.275.0.bb
> rename to meta/recipes-graphics/glslang/glslang_1.3.280.0.bb
> index 2fd1e72a26..637082c719 100644
> --- a/meta/recipes-graphics/glslang/glslang_1.3.275.0.bb
> +++ b/meta/recipes-graphics/glslang/glslang_1.3.280.0.bb
> @@ -8,7 +8,7 @@ HOMEPAGE = 
> "https://www.khronos.org/opengles/sdk/tools/Reference-Compiler;
>  LICENSE = "BSD-3-Clause & BSD-2-Clause & MIT & Apache-2.0 & 
> GPL-3-with-bison-exception"
>  LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=2a2b5acd7bc4844964cfda45fe807dc3"
>
> -SRCREV = "a91631b260cba3f22858d6c6827511e636c2458a"
> +SRCREV = "ee2f5d09eaf8f4e8d0d598bd2172fce290d4ca60"
>  SRC_URI = 
> "git://github.com/KhronosGroup/glslang.git;protocol=https;branch=main \
> file://0001-generate-glslang-pkg-config.patch \
> "
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197529): 
https://lists.openembedded.org/g/openembedded-core/message/197529
Mute This Topic: https://lists.openembedded.org/mt/105150498/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] oeqa/selftest/overlayfs: test read-only rootfs

2024-03-26 Thread Alexander Kanavin

Feature freeze perhaps? The patch is in abelloni/master-next and will
be handled later, possibly after the release is out. It's better to
not send it during the freeze period though to avoid adding to the
backlog.

Alex

On Tue, 26 Mar 2024 at 08:47, Vyacheslav Yurkov  wrote:
>
> Just checking if there's any feedback for the patch or something that
> stops it from being merged.
>
> Slava
>
> On 17.03.2024 20:33, Vyacheslav Yurkov via lists.openembedded.org wrote:
> > From: Baruch Siach 
> >
> > Use the read-only squashfs filesystem to test the read-only case.
> >
> > Signed-off-by: Baruch Siach 
> > Signed-off-by: Vyacheslav Yurkov 
> > ---
> >   meta-selftest/wic/overlayfs_etc.wks.in|  4 +--
> >   meta/lib/oeqa/selftest/cases/overlayfs.py | 34 +++
> >   2 files changed, 30 insertions(+), 8 deletions(-)
> >
> > diff --git a/meta-selftest/wic/overlayfs_etc.wks.in 
> > b/meta-selftest/wic/overlayfs_etc.wks.in
> > index 1e1e5836e7..066cd35b15 100644
> > --- a/meta-selftest/wic/overlayfs_etc.wks.in
> > +++ b/meta-selftest/wic/overlayfs_etc.wks.in
> > @@ -1,4 +1,4 @@
> >   part /boot --active --source bootimg-biosplusefi --ondisk sda 
> > --sourceparams="loader=grub-efi" --align 1024
> > -part / --source rootfs --ondisk sda --fstype=ext4 --use-uuid --align 1024
> > +part / --source rootfs --ondisk sda --fstype=${OVERLAYFS_ROOTFS_TYPE} 
> > --use-uuid --align 1024
> >   part --ondisk sda --fstype=ext4 --size=5 --align 1024
> > -bootloader --ptable gpt --timeout=1 --append="rootfstype=ext4 
> > console=ttyS0,115200 console=tty0 ${OVERLAYFS_INIT_OPTION}"
> > +bootloader --ptable gpt --timeout=1 
> > --append="rootfstype=${OVERLAYFS_ROOTFS_TYPE} console=ttyS0,115200 
> > console=tty0 ${OVERLAYFS_INIT_OPTION}"
> > diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
> > b/meta/lib/oeqa/selftest/cases/overlayfs.py
> > index cd0dc60c64..e31063567b 100644
> > --- a/meta/lib/oeqa/selftest/cases/overlayfs.py
> > +++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
> > @@ -353,6 +353,7 @@ EXTRA_IMAGE_FEATURES += "read-only-rootfs"
> >   # Image configuration for overlayfs-etc
> >   OVERLAYFS_ETC_MOUNT_POINT = "/data"
> >   OVERLAYFS_ETC_DEVICE = "/dev/sda3"
> > +OVERLAYFS_ROOTFS_TYPE = "ext4"
> >   """
> >
> >   self.write_config(config)
> > @@ -367,13 +368,17 @@ OVERLAYFS_ETC_DEVICE = "/dev/sda3"
> >
> >   @skipIfNotMachine("qemux86-64", "tests are qemux86-64 specific 
> > currently")
> >   def test_sbin_init_preinit(self):
> > -self.run_sbin_init(False)
> > +self.run_sbin_init(False, "ext4")
> >
> >   @skipIfNotMachine("qemux86-64", "tests are qemux86-64 specific 
> > currently")
> >   def test_sbin_init_original(self):
> > -self.run_sbin_init(True)
> > +self.run_sbin_init(True, "ext4")
> >
> > -def run_sbin_init(self, origInit):
> > +@skipIfNotMachine("qemux86-64", "tests are qemux86-64 specific 
> > currently")
> > +def test_sbin_init_read_only(self):
> > +self.run_sbin_init(True, "squashfs")
> > +
> > +def run_sbin_init(self, origInit, rootfsType):
> >   """
> >   Summary:   Confirm we can replace original init and mount overlay 
> > on top of /etc
> >   Expected:  Image is created successfully and /etc is mounted as 
> > an overlay
> > @@ -384,7 +389,9 @@ OVERLAYFS_ETC_DEVICE = "/dev/sda3"
> >
> >   args = {
> >   'OVERLAYFS_INIT_OPTION': "" if origInit else 
> > "init=/sbin/preinit",
> > -'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': int(origInit == True)
> > +'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': int(origInit == True),
> > +'OVERLAYFS_ROOTFS_TYPE': rootfsType,
> > +'OVERLAYFS_ETC_CREATE_MOUNT_DIRS': int(rootfsType == "ext4")
> >   }
> >
> >   self.write_config(config.format(**args))
> > @@ -437,7 +444,9 @@ IMAGE_INSTALL:append = " overlayfs-user"
> >
> >   args = {
> >   'OVERLAYFS_INIT_OPTION': "",
> > -'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': 1
> > +'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': 1,
> > +'OVERLAYFS_ROOTFS_TYPE': "ext4",
> > +'OVERLAYFS_ETC_CREATE_MOUNT_DIRS': 1
> >   }
> >
> >   self.write_config(config.format(**args))
> > @@ -463,10 +472,14 @@ IMAGE_INSTALL:append = " overlayfs-user"
> >   INIT_MANAGER = "systemd"
> >
> >   # enable overlayfs in the kernel
> > -KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
> > +KERNEL_EXTRA_FEATURES:append = " \
> > +features/overlayfs/overlayfs.scc \
> > +cfg/fs/squashfs.scc"
> >
> >   IMAGE_FSTYPES += "wic"
> >   OVERLAYFS_INIT_OPTION = "{OVERLAYFS_INIT_OPTION}"
> > +OVERLAYFS_ROOTFS_TYPE = "{OVERLAYFS_ROOTFS_TYPE}"
> > +OVERLAYFS_ETC_CREATE_MOUNT_DIRS = "{OVERLAYFS_ETC_CREATE_MOUNT_DIRS}"
> >   WKS_FILE = "overlayfs_etc.wks.in"
> >
> >   EXTRA_IMAGE_FEATURES += "read-only-rootfs"
> > @@ -477,4 +490,13 @@ OVERLAYFS_ETC_MOUNT_POINT = "/data"
> >   OVERLAYFS_ETC_FSTYPE =

Re: [OE-core] [PATCH] oeqa/selftest/overlayfs: test read-only rootfs

2024-03-26 Thread Vyacheslav Yurkov

Just checking if there's any feedback for the patch or something that 
stops it from being merged.


Slava

On 17.03.2024 20:33, Vyacheslav Yurkov via lists.openembedded.org wrote:

From: Baruch Siach 

Use the read-only squashfs filesystem to test the read-only case.

Signed-off-by: Baruch Siach 
Signed-off-by: Vyacheslav Yurkov 
---
  meta-selftest/wic/overlayfs_etc.wks.in|  4 +--
  meta/lib/oeqa/selftest/cases/overlayfs.py | 34 +++
  2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/meta-selftest/wic/overlayfs_etc.wks.in 
b/meta-selftest/wic/overlayfs_etc.wks.in
index 1e1e5836e7..066cd35b15 100644
--- a/meta-selftest/wic/overlayfs_etc.wks.in
+++ b/meta-selftest/wic/overlayfs_etc.wks.in
@@ -1,4 +1,4 @@
  part /boot --active --source bootimg-biosplusefi --ondisk sda 
--sourceparams="loader=grub-efi" --align 1024
-part / --source rootfs --ondisk sda --fstype=ext4 --use-uuid --align 1024
+part / --source rootfs --ondisk sda --fstype=${OVERLAYFS_ROOTFS_TYPE} 
--use-uuid --align 1024
  part --ondisk sda --fstype=ext4 --size=5 --align 1024
-bootloader --ptable gpt --timeout=1 --append="rootfstype=ext4 console=ttyS0,115200 
console=tty0 ${OVERLAYFS_INIT_OPTION}"
+bootloader --ptable gpt --timeout=1 --append="rootfstype=${OVERLAYFS_ROOTFS_TYPE} 
console=ttyS0,115200 console=tty0 ${OVERLAYFS_INIT_OPTION}"
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index cd0dc60c64..e31063567b 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -353,6 +353,7 @@ EXTRA_IMAGE_FEATURES += "read-only-rootfs"
  # Image configuration for overlayfs-etc
  OVERLAYFS_ETC_MOUNT_POINT = "/data"
  OVERLAYFS_ETC_DEVICE = "/dev/sda3"
+OVERLAYFS_ROOTFS_TYPE = "ext4"
  """
  
  self.write_config(config)

@@ -367,13 +368,17 @@ OVERLAYFS_ETC_DEVICE = "/dev/sda3"
  
  @skipIfNotMachine("qemux86-64", "tests are qemux86-64 specific currently")

  def test_sbin_init_preinit(self):
-self.run_sbin_init(False)
+self.run_sbin_init(False, "ext4")
  
  @skipIfNotMachine("qemux86-64", "tests are qemux86-64 specific currently")

  def test_sbin_init_original(self):
-self.run_sbin_init(True)
+self.run_sbin_init(True, "ext4")
  
-def run_sbin_init(self, origInit):

+@skipIfNotMachine("qemux86-64", "tests are qemux86-64 specific currently")
+def test_sbin_init_read_only(self):
+self.run_sbin_init(True, "squashfs")
+
+def run_sbin_init(self, origInit, rootfsType):
  """
  Summary:   Confirm we can replace original init and mount overlay on 
top of /etc
  Expected:  Image is created successfully and /etc is mounted as an 
overlay
@@ -384,7 +389,9 @@ OVERLAYFS_ETC_DEVICE = "/dev/sda3"
  
  args = {

  'OVERLAYFS_INIT_OPTION': "" if origInit else "init=/sbin/preinit",
-'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': int(origInit == True)
+'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': int(origInit == True),
+'OVERLAYFS_ROOTFS_TYPE': rootfsType,
+'OVERLAYFS_ETC_CREATE_MOUNT_DIRS': int(rootfsType == "ext4")
  }
  
  self.write_config(config.format(**args))

@@ -437,7 +444,9 @@ IMAGE_INSTALL:append = " overlayfs-user"
  
  args = {

  'OVERLAYFS_INIT_OPTION': "",
-'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': 1
+'OVERLAYFS_ETC_USE_ORIG_INIT_NAME': 1,
+'OVERLAYFS_ROOTFS_TYPE': "ext4",
+'OVERLAYFS_ETC_CREATE_MOUNT_DIRS': 1
  }
  
  self.write_config(config.format(**args))

@@ -463,10 +472,14 @@ IMAGE_INSTALL:append = " overlayfs-user"
  INIT_MANAGER = "systemd"
  
  # enable overlayfs in the kernel

-KERNEL_EXTRA_FEATURES:append = " features/overlayfs/overlayfs.scc"
+KERNEL_EXTRA_FEATURES:append = " \
+features/overlayfs/overlayfs.scc \
+cfg/fs/squashfs.scc"
  
  IMAGE_FSTYPES += "wic"

  OVERLAYFS_INIT_OPTION = "{OVERLAYFS_INIT_OPTION}"
+OVERLAYFS_ROOTFS_TYPE = "{OVERLAYFS_ROOTFS_TYPE}"
+OVERLAYFS_ETC_CREATE_MOUNT_DIRS = "{OVERLAYFS_ETC_CREATE_MOUNT_DIRS}"
  WKS_FILE = "overlayfs_etc.wks.in"
  
  EXTRA_IMAGE_FEATURES += "read-only-rootfs"

@@ -477,4 +490,13 @@ OVERLAYFS_ETC_MOUNT_POINT = "/data"
  OVERLAYFS_ETC_FSTYPE = "ext4"
  OVERLAYFS_ETC_DEVICE = "/dev/sda3"
  OVERLAYFS_ETC_USE_ORIG_INIT_NAME = "{OVERLAYFS_ETC_USE_ORIG_INIT_NAME}"
+
+ROOTFS_POSTPROCESS_COMMAND += "{OVERLAYFS_ROOTFS_TYPE}_rootfs"
+
+ext4_rootfs() {{
+}}
+
+squashfs_rootfs() {{
+mkdir -p ${{IMAGE_ROOTFS}}/data
+}}
  """






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

[OE-core][dunfell][PATCH] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

2024-03-26 Thread Vijay Anusuri via lists.openembedded.org

From: Vijay Anusuri 

Upstream-Status: Backport
[https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee287591a1
&
https://github.com/golang/go/commit/bf80213b121074f4ad9b449410a4d13bae5e9be0
&
https://github.com/golang/go/commit/3643147a29352ca2894fd5d0d2069bc4b4335a7e]

Signed-off-by: Vijay Anusuri 
---
 meta/recipes-devtools/go/go-1.14.inc  |   3 +
 .../go/go-1.14/CVE-2023-45289.patch   | 121 
 .../go/go-1.14/CVE-2023-45290.patch   | 271 ++
 .../go/go-1.14/CVE-2024-24785.patch   | 197 +
 4 files changed, 592 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-45290.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2024-24785.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index 4fbf9d7590..69b65f3eb2 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -88,6 +88,9 @@ SRC_URI += "\
 file://CVE-2023-45287-pre2.patch \
 file://CVE-2023-45287-pre3.patch \
 file://CVE-2023-45287.patch \
+file://CVE-2023-45289.patch \
+file://CVE-2023-45290.patch \
+file://CVE-2024-24785.patch \
 "
 
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
new file mode 100644
index 00..3bec62ab83
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2023-45289.patch
@@ -0,0 +1,121 @@
+From 20586c0dbe03d144f914155f879fa5ee287591a1 Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Thu, 11 Jan 2024 11:31:57 -0800
+Subject: [PATCH] [release-branch.go1.21] net/http, net/http/cookiejar: avoid
+ subdomain matches on IPv6 zones
+
+When deciding whether to forward cookies or sensitive headers
+across a redirect, do not attempt to interpret an IPv6 address
+as a domain name.
+
+Avoids a case where a maliciously-crafted redirect to an
+IPv6 address with a scoped addressing zone could be
+misinterpreted as a within-domain redirect. For example,
+we could interpret "::1%.www.example.com" as a subdomain
+of "www.example.com".
+
+Thanks to Juho Nurminen of Mattermost for reporting this issue.
+
+Fixes CVE-2023-45289
+Fixes #65385
+For #65065
+
+Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2131938
+Reviewed-by: Tatiana Bradley 
+Reviewed-by: Roland Shoemaker 
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2173775
+Reviewed-by: Carlos Amedee 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/569239
+Reviewed-by: Carlos Amedee 
+Auto-Submit: Michael Knyszek 
+TryBot-Bypass: Michael Knyszek 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/20586c0dbe03d144f914155f879fa5ee287591a1]
+CVE: CVE-45289
+Signed-off-by: Vijay Anusuri 
+---
+ src/net/http/client.go |  6 ++
+ src/net/http/client_test.go|  1 +
+ src/net/http/cookiejar/jar.go  |  7 +++
+ src/net/http/cookiejar/jar_test.go | 10 ++
+ 4 files changed, 24 insertions(+)
+
+diff --git a/src/net/http/client.go b/src/net/http/client.go
+index a496f1c..2031834 100644
+--- a/src/net/http/client.go
 b/src/net/http/client.go
+@@ -973,6 +973,12 @@ func isDomainOrSubdomain(sub, parent string) bool {
+   if sub == parent {
+   return true
+   }
++  // If sub contains a :, it's probably an IPv6 address (and is 
definitely not a hostname).
++  // Don't check the suffix in this case, to avoid matching the contents 
of a IPv6 zone.
++  // For example, "::1%.www.example.com" is not a subdomain of 
"www.example.com".
++  if strings.ContainsAny(sub, ":%") {
++  return false
++  }
+   // If sub is "foo.example.com" and parent is "example.com",
+   // that means sub must end in "."+parent.
+   // Do it without allocating.
+diff --git a/src/net/http/client_test.go b/src/net/http/client_test.go
+index 2b4f53f..442fe35 100644
+--- a/src/net/http/client_test.go
 b/src/net/http/client_test.go
+@@ -1703,6 +1703,7 @@ func TestShouldCopyHeaderOnRedirect(t *testing.T) {
+   {"cookie2", "http://foo.com/;, "http://bar.com/;, false},
+   {"authorization", "http://foo.com/;, "http://bar.com/;, false},
+   {"www-authenticate", "http://foo.com/;, "http://bar.com/;, 
false},
++  {"authorization", "http://foo.com/;, 
"http://[::1%25.foo.com]/;, false},
+ 
+   // But subdomains should work:
+   {"www-authenticate", "http://foo.com/;, "http://foo.com/;, 
true},
+diff --git a/src/net/http/cookiejar/jar.go b/src/net/http/cookiejar/jar.go
+index 9f19917..18cbfc2 100644
+--- a/src/net/http/cookiejar/jar.go
 b/src/net/http/cookiejar/jar.go
+@@

Re: [OE-core][PATCH V2] ovmf: set CVE_PRODUCT and CVE_VERSION

[OE-core] [PATCH v2] vulkan: upgrade 1.3.275.0 -> 1.3.280.0

[OE-core] [PATCH v2] mesa: upgrade 24.0.2 -> 24.0.3

[OE-core][dunfell][PATCH v2] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

[OE-core] OpenEmbedded Happy Hour March 27 5pm/1700 UTC

Re: [oe-core][RFC][PATCHv2] glib-2.0: update 2.78.4 -> 2.80.0

Re: [OE-core][Patch v1 1/2] perf: fix build with latest kernel

Re: [OE-core][Patch v1 1/2] perf: fix build with latest kernel

Re: [OE-core][Patch v1 2/2] perf: tests: fix qa error, missing perl

Re: [OE-Core] [PATCH 06/34] glib-networking: upgrade 2.78.1 -> 2.80.0

[OE-core] Yocto Project Status 26 March 2024 (WW13)

Re: [OE-core][dunfell 11/12] linux-firmware: upgrade 20231211 -> 20240220

Re: [OE-core][dunfell 11/12] linux-firmware: upgrade 20231211 -> 20240220

Re: [OE-core][dunfell][PATCH] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

Re: [OE-Core] [PATCH 17/34] mesa: upgrade 24.0.2 -> 24.0.3

Re: [OE-Core] [PATCH 07/34] glslang: upgrade 1.3.275.0 -> 1.3.280.0

Re: [OE-core] [PATCH] oeqa/selftest/overlayfs: test read-only rootfs

Re: [OE-core] [PATCH] oeqa/selftest/overlayfs: test read-only rootfs

[OE-core][dunfell][PATCH] go: Fix for CVE-2023-45289 CVE-2023-45290 & CVE-2024-24785

22 matches

Site Navigation

Mail list logo

Footer information