[OE-core][kirkstone][PATCH] go: Backport fix CVE-2024-24784 & CVE-2024-24785

2024-03-10 Thread Vivek Kumbhar via lists.openembedded.org
Backport fixes for :

CVE-2024-24784 - Upstream-Status: Backport from 
https://github.com/golang/go/commit/5330cd225ba54c7dc78c1b46dcdf61a4671a632c
CVE-2024-24785 - Upstream-Status: Backport from 
https://github.com/golang/go/commit/056b0edcb8c152152021eebf4cf42adbfbe77992

Signed-off-by: Vivek Kumbhar 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |   2 +
 .../go/go-1.18/CVE-2024-24784.patch   | 207 ++
 .../go/go-1.18/CVE-2024-24785.patch   | 196 +
 3 files changed, 405 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.18/CVE-2024-24784.patch
 create mode 100644 meta/recipes-devtools/go/go-1.18/CVE-2024-24785.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index e635445579..768961de2c 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -53,6 +53,8 @@ SRC_URI += "\
 file://CVE-2023-45287.patch \
 file://CVE-2023-45289.patch \
 file://CVE-2023-45290.patch \
+file://CVE-2024-24784.patch \
+file://CVE-2024-24785.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.18/CVE-2024-24784.patch 
b/meta/recipes-devtools/go/go-1.18/CVE-2024-24784.patch
new file mode 100644
index 00..d3fc6b0313
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.18/CVE-2024-24784.patch
@@ -0,0 +1,207 @@
+From 5330cd225ba54c7dc78c1b46dcdf61a4671a632c Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Wed, 10 Jan 2024 11:02:14 -0800
+Subject: [PATCH] [release-branch.go1.22] net/mail: properly handle special
+ characters in phrase and obs-phrase
+
+Fixes a couple of misalignments with RFC 5322 which introduce
+significant diffs between (mostly) conformant parsers.
+
+This change reverts the changes made in CL50911, which allowed certain
+special RFC 5322 characters to appear unquoted in the "phrase" syntax.
+It is unclear why this change was made in the first place, and created
+a divergence from comformant parsers. In particular this resulted in
+treating comments in display names incorrectly.
+
+Additionally properly handle trailing malformed comments in the group
+syntax.
+
+For #65083
+Fixed #65849
+
+Change-Id: I00dddc044c6ae3381154e43236632604c390f672
+Reviewed-on: https://go-review.googlesource.com/c/go/+/96
+Reviewed-by: Damien Neil 
+LUCI-TryBot-Result: Go LUCI 

+Reviewed-on: https://go-review.googlesource.com/c/go/+/566215
+Reviewed-by: Carlos Amedee 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/5330cd225ba54c7dc78c1b46dcdf61a4671a632c]
+CVE: CVE-2024-24784
+Signed-off-by: Vivek Kumbhar 
+---
+ src/net/mail/message.go  | 30 +++
+ src/net/mail/message_test.go | 40 ++--
+ 2 files changed, 46 insertions(+), 24 deletions(-)
+
+diff --git a/src/net/mail/message.go b/src/net/mail/message.go
+index 47bbf6c..84f48f0 100644
+--- a/src/net/mail/message.go
 b/src/net/mail/message.go
+@@ -231,7 +231,7 @@ func (a *Address) String() string {
+   // Add quotes if needed
+   quoteLocal := false
+   for i, r := range local {
+-  if isAtext(r, false, false) {
++  if isAtext(r, false) {
+   continue
+   }
+   if r == '.' {
+@@ -395,7 +395,7 @@ func (p *addrParser) parseAddress(handleGroup bool) 
([]*Address, error) {
+   if !p.consume('<') {
+   atext := true
+   for _, r := range displayName {
+-  if !isAtext(r, true, false) {
++  if !isAtext(r, true) {
+   atext = false
+   break
+   }
+@@ -430,7 +430,9 @@ func (p *addrParser) consumeGroupList() ([]*Address, 
error) {
+   // handle empty group.
+   p.skipSpace()
+   if p.consume(';') {
+-  p.skipCFWS()
++  if !p.skipCFWS() {
++  return nil, errors.New("mail: misformatted 
parenthetical comment")
++  }
+   return group, nil
+   }
+
+@@ -447,7 +449,9 @@ func (p *addrParser) consumeGroupList() ([]*Address, 
error) {
+   return nil, errors.New("mail: misformatted 
parenthetical comment")
+   }
+   if p.consume(';') {
+-  p.skipCFWS()
++  if !p.skipCFWS() {
++  return nil, errors.New("mail: misformatted 
parenthetical comment")
++  }
+   break
+   }
+   if !p.consume(',') {
+@@ -517,6 +521,12 @@ func (p *addrParser) consumePhrase() (phrase string, err 
error) {
+   var words []string
+   var isPrevEncoded bool
+   for {
++  // obs-phrase allows CFWS after one word
++  if len(words) > 0 {
++   

Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-5.0_M3.rc1)

2024-03-10 Thread Jing Hui Tham
Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-5.0_M3.rc1. 
We are planning to execute following tests for this cycle:
 
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
 
Runtime auto test for following platforms:
1. MinnowBoard Turbot - 32bit
2. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors)
3. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors)
4. Meteor Lake-P (14th Generation Intel(r) Core(tm) Processors)
5. Beaglebone

 
ETA for completion Thursday, 14 March 2024.
 
Best regards,
Jing Hui


> -Original Message-
> From: yo...@lists.yoctoproject.org  On Behalf
> Of Pokybuild User
> Sent: Friday, March 8, 2024 11:24 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [yocto] QA notification for completed autobuilder build (yocto-
> 5.0_M3.rc1)
> 
> 
> A build flagged for QA (yocto-5.0_M3.rc1) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-5.0_M3.rc1
> 
> 
> Build URL:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6661
> 
> Build hash information:
> 
> bitbake: 0a33b560233b983456178541603ab96fea22238b
> meta-agl: 403545c205c30df24e39ee03d6f188aca998b3f7
> meta-arm: aba9250494f62360c1ec8021f81922c005d92b82
> meta-aws: eb351722d71f5de128455b9f5bfdabfce5d2c725
> meta-clang: eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52
> meta-intel: 9ed54a13803e42ca40589d6ce02c76f3162f6b73
> meta-mingw: acbba477893ef87388effc4679b7f40ee49fc852
> meta-openembedded: a0237019f5b5c003fd0c6fd4486859214e24be01
> meta-virtualization: e7f9c2dd2f9f4ac95942b69c05ed8f5d0494edbf
> oecore: bc793fa9d1fe24c102d91e97b7002b6e637cbfa5
> poky: b5624ee5643d881afa004571a096a189ab5389b5
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

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

2024-03-10 Thread Anuj Mittal
On Thu, 2024-03-07 at 16:08 -0800, Meenali Gupta via
lists.openembedded.org wrote:
> From: Meenali Gupta 
> 
> A flaw was found in Expat (libexpat). If XML_DTD is undefined at
> compile time, a recursive XML Entity
> Expansion condition can be triggered. This issue may lead to a
> condition where data is expanded exponentially,
> which will quickly consume system resources and cause a denial of
> service.
> 
> Signed-off-by: Meenali Gupta 
> ---
>  .../expat/expat/CVE-2023-52426.patch  | 429
> ++
>  meta/recipes-core/expat/expat_2.5.0.bb    |   1 +
>  2 files changed, 430 insertions(+)
>  create mode 100644 meta/recipes-core/expat/expat/CVE-2023-
> 52426.patch
> 
> diff --git a/meta/recipes-core/expat/expat/CVE-2023-52426.patch
> b/meta/recipes-core/expat/expat/CVE-2023-52426.patch
> new file mode 100644
> index 00..b78a8ee0dc
> --- /dev/null
> +++ b/meta/recipes-core/expat/expat/CVE-2023-52426.patch
> @@ -0,0 +1,429 @@
> +From 0f075ec8ecb5e43f8fdca5182f8cca4703da0404 Mon Sep 17 00:00:00
> 2001
> +From: Sebastian Pipping 
> +Date: Thu, 26 Oct 2023 00:43:22 +0200
> +Subject: [PATCH] lib|xmlwf|cmake: Extend scope of billion laughs
> attack
> + protection
> +
> +.. from "defined(XML_DTD)" to "defined(XML_DTD) || XML_GE==1".
> +
> +CVE: CVE-2023-52426
> +Upstream-Status: Backport
> [https://github.com/libexpat/libexpat/commit/0f075ec8ecb5e43f8fdca518
> 2f8cca4703da0404]

The PR that this commit is part of includes other commits as well. Is
there any reason why only this is included or required? 

I didn't check in detail but as an example, it seems this commit uses
EXPAT_GE which was introduced in an earlier commit in that PR:

https://github.com/libexpat/libexpat/pull/777/commits/daa89e42c005cc7f4f7af9eee271ae0723d30300

So, is this supposed to work as intended?

Thanks,

Anuj

> +
> +Signed-off-by: Meenali Gupta 
> +---
> + CMakeLists.txt |  8 -
> + lib/expat.h    |  8 +++--
> + lib/internal.h |  2 +-
> + lib/libexpat.def.cmake |  4 +--
> + lib/xmlparse.c | 71 ++-
> ---
> + xmlwf/xmlwf.c  | 18 ++-
> + 6 files changed, 62 insertions(+), 49 deletions(-)
> +
> +diff --git a/CMakeLists.txt b/CMakeLists.txt
> +index 2b4c13c..183c5c2 100644
> +--- a/CMakeLists.txt
>  b/CMakeLists.txt
> +@@ -381,7 +381,13 @@ if(EXPAT_SHARED_LIBS)
> + endif()
> + endmacro()
> +
> +-    _expat_def_file_toggle(EXPAT_DTD _EXPAT_COMMENT_DTD)
> ++if(EXPAT_DTD OR EXPAT_GE)
> ++    set(_EXPAT_DTD_OR_GE TRUE)
> ++    else()
> ++    set(_EXPAT_DTD_OR_GE FALSE)
> ++    endif()
> ++
> ++    _expat_def_file_toggle(_EXPAT_DTD_OR_GE
> _EXPAT_COMMENT_DTD_OR_GE)
> + _expat_def_file_toggle(EXPAT_ATTR_INFO
> _EXPAT_COMMENT_ATTR_INFO)
> +
> +
> configure_file("${CMAKE_CURRENT_SOURCE_DIR}/lib/libexpat.def.cmake"
> "${CMAKE_CURRENT_BINARY_DIR}/lib/libexpat.def")
> +diff --git a/lib/expat.h b/lib/expat.h
> +index 1c83563..33c94af 100644
> +--- a/lib/expat.h
>  b/lib/expat.h
> +@@ -1038,13 +1038,15 @@ typedef struct {
> + XMLPARSEAPI(const XML_Feature *)
> + XML_GetFeatureList(void);
> +
> +-#ifdef XML_DTD
> +-/* Added in Expat 2.4.0. */
> ++#if defined(XML_DTD) || XML_GE == 1
> ++/* Added in Expat 2.4.0 for XML_DTD defined and
> ++ * added in Expat 2.6.0 for XML_GE == 1. */
> + XMLPARSEAPI(XML_Bool)
> + XML_SetBillionLaughsAttackProtectionMaximumAmplification(
> + XML_Parser parser, float maximumAmplificationFactor);
> +
> +-/* Added in Expat 2.4.0. */
> ++/* Added in Expat 2.4.0 for XML_DTD defined and
> ++ * added in Expat 2.6.0 for XML_GE == 1. */
> + XMLPARSEAPI(XML_Bool)
> + XML_SetBillionLaughsAttackProtectionActivationThreshold(
> + XML_Parser parser, unsigned long long
> activationThresholdBytes);
> +diff --git a/lib/internal.h b/lib/internal.h
> +index e09f533..1851925 100644
> +--- a/lib/internal.h
>  b/lib/internal.h
> +@@ -154,7 +154,7 @@ extern "C" {
> + void _INTERNAL_trim_to_complete_utf8_characters(const char *from,
> + const char
> **fromLimRef);
> +
> +-#if defined(XML_DTD)
> ++#if defined(XML_DTD) || XML_GE == 1
> + unsigned long long testingAccountingGetCountBytesDirect(XML_Parser
> parser);
> + unsigned long long
> testingAccountingGetCountBytesIndirect(XML_Parser parser);
> + const char *unsignedCharToPrintable(unsigned char c);
> +diff --git a/lib/libexpat.def.cmake b/lib/libexpat.def.cmake
> +index cf434a2..61a4f00 100644
> +--- a/lib/libexpat.def.cmake
>  b/lib/libexpat.def.cmake
> +@@ -75,5 +75,5 @@ EXPORTS
> +   XML_SetHashSalt @67
> + ; internal @68 removed with version 2.3.1
> + ; added with version 2.4.0
> +-@_EXPAT_COMMENT_DTD@
> XML_SetBillionLaughsAttackProtectionActivationThreshold @69
> +-@_EXPAT_COMMENT_DTD@
> XML_SetBillionLaughsAttackProtectionMaximumAmplification @70
> ++@_EXPAT_COMMENT_DTD_OR_GE@
> 

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-10 Thread Steve Sakoman
On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield  wrote:
>
> On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
> lists.openembedded.org
>  wrote:
> >
> > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
> >  wrote:
> > >
> > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > > lists.openembedded.org 
> > > > wrote:
> > > > >
> > > > > I did fire up a test of Kevin's patch:
> > > > >
> > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > > >
> > > > > Let's see what happens.
> > > >
> > > > I can confirm that this patch fixes the parted ptest issues and does
> > > > not trigger any other ptest issues.
> > > >
> > > > However since there is a kirkstone release build scheduled for next
> > > > Tuesday, the current plan of record is to revert the previous
> > > > linux-yocto 5.15 version bump series for the release build.
> > > >
> > > > I will then wait for a patch from Bruce that fixes the problem before
> > > > reapplying it post release.
> > >
> > > If it takes a few more days it may be better to slip that release (when
> > > QA are likely testing M3 anyway) in order to resolve this rather than
> > > reverting a load of things we'll only then end up reapplying.
> > >
> >
> > I'll be working on it over the weekend, along with some other kernel
> > items that I didn't get to as I worked on this today and some meta-virt
> > things.
>
> Steve: Here's my latest queue:
>
> https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone
>
> It passed the parted and util-linux ptests locally.

Thanks Bruce!

I'll grab the patches and run an a-full on the autobuilder.

Steve

> > --
> > - 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 (#196908): 
https://lists.openembedded.org/g/openembedded-core/message/196908
Mute This Topic: https://lists.openembedded.org/mt/104794844/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/3] linux-yocto: for-test-only: fix parted ptest

2024-03-10 Thread Bruce Ashfield
On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie
>  wrote:
> >
> > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote:
> > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via
> > > lists.openembedded.org 
> > > wrote:
> > > >
> > > > I did fire up a test of Kevin's patch:
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373
> > > >
> > > > Let's see what happens.
> > >
> > > I can confirm that this patch fixes the parted ptest issues and does
> > > not trigger any other ptest issues.
> > >
> > > However since there is a kirkstone release build scheduled for next
> > > Tuesday, the current plan of record is to revert the previous
> > > linux-yocto 5.15 version bump series for the release build.
> > >
> > > I will then wait for a patch from Bruce that fixes the problem before
> > > reapplying it post release.
> >
> > If it takes a few more days it may be better to slip that release (when
> > QA are likely testing M3 anyway) in order to resolve this rather than
> > reverting a load of things we'll only then end up reapplying.
> >
>
> I'll be working on it over the weekend, along with some other kernel
> items that I didn't get to as I worked on this today and some meta-virt
> things.

Steve: Here's my latest queue:

https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone

It passed the parted and util-linux ptests locally.

Bruce

>
> Bruce
>
> > Cheers,
> >
> > Richard
> >
> >
>
>
> --
> - 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 (#196907): 
https://lists.openembedded.org/g/openembedded-core/message/196907
Mute This Topic: https://lists.openembedded.org/mt/104794844/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] [REGRESSION] linux (git/curl-native) and autorev

2024-03-10 Thread Richard Purdie
On Sun, 2024-03-10 at 09:05 -0700, Bruce Ashfield wrote:
> On Sun, Mar 10, 2024 at 11:52 AM Richard Purdie
>  wrote:
> > 
> > On Sun, 2024-03-10 at 06:20 -0700, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Sun, 2024-03-10 at 13:31 +0100, Max wrote:
> > > > Am Samstag, dem 09.03.2024 um 13:04 -0800 schrieb Bruce
> > > > Ashfield:
> > > > > On Sat, Mar 9, 2024 at 12:58 PM  wrote:
> > > > > > 
> > > > > > From: Max Krummenacher 
> > > > > > 
> > > > > > Hello
> > > > > > 
> > > > > > If one builds a kernel using AUTOREV invoking bitbake only
> > > > > > works
> > > > > > once.
> > > > > > Any subsequent bitbake invocation fails parsing the meta
> > > > > > data.
> > > > > > 
> > > > > > Reproducable with:
> > > > > > - latest poky, b5624ee564
> > > > > > - Kernel with SRCREV = "AUTOREV", e.g. in local.conf
> > > > > >   `SRCREV_machine:pn-linux-yocto:forcevariable =
> > > > > > "${AUTOREV}"`
> > > > > > - bitbake virtual/kernel; bitbake virtual/kernel
> > > > > > 
> > > > > > On the second invocation parsing fails when the fetcher
> > > > > > tries
> > > > > > to
> > > > > > evaluate the latest SRCREV:
> > > > > > 
> > > > > > > ERROR: ExpansionError during parsing meta/recipes-
> > > > > > > kernel/linux/linux-yocto_6.6.bb
> > > > > > > Traceback (most recent call last):
> > > > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1245, in
> > > > > > > srcrev_internal_helper(ud= > > > > > > 0x7f8e26f5f290>, d= > > > > > > 0x7f8e26195890>, name='machine'):
> > > > > > >  d.setVar("__BBAUTOREV_ACTED_UPON", True)
> > > > > > >     >    srcrev = ud.method.latest_revision(ud, d,
> > > > > > > name)
> > > > > > > 
> > > > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1667, in
> > > > > > > Git.latest_revision(ud= > > > > > > 0x7f8e26f5f290>, d= > > > > > > 0x7f8e26195890>, name='machine'):
> > > > > > >  except KeyError:
> > > > > > >     >    revs[key] = rev =
> > > > > > > self._latest_revision(ud,
> > > > > > > d,
> > > > > > > name)
> > > > > > >  return rev
> > > > > > >   File "bitbake/lib/bb/fetch2/git.py", line 850, in
> > > > > > > Git._latest_revision(ud= > > > > > > 0x7f8e26f5f290>, d= > > > > > > 0x7f8e26195890>, name='machine'):
> > > > > > > 
> > > > > > >     >    output = self._lsremote(ud, d, "")
> > > > > > >  # Tags of the form ^{} may not work, need to
> > > > > > > fallback to other form
> > > > > > >   File "bitbake/lib/bb/fetch2/git.py", line 833, in
> > > > > > > Git._lsremote(ud= > > > > > > 0x7f8e26f5f290>, d= > > > > > > 0x7f8e26195890>, search=''):
> > > > > > >  bb.fetch2.check_network_access(d,
> > > > > > > cmd,
> > > > > > > repourl)
> > > > > > >     >    output = runfetchcmd(cmd, d, True)
> > > > > > >  if not output:
> > > > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 957, in
> > > > > > > runfetchcmd(cmd='export PSEUDO_DISABLED=1; export
> > > > > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus";
> > > > > > > export
> > > > > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > > > > linux/usr/bin:scripts:build/tmp/work/qemux86_64-poky-
> > > > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > > > native/usr/bin/x86_64-poky-
> > > > > > > linux:build/tmp/work/qemux86_64-
> > > > > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-
> > > > > > > poky-
> > > > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-
> > > > > > > linux/linux-
> > > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > > native/usr/bin:build/tmp/work/qemux86_64-poky-
> > > > > > > linux/linux-
> > > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > > native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > > native/bin:bitbake/bin:build/tmp/hosttools"; export
> > > > > > > HOME="/home/krm"; git -c gc.autoDetach=false -c
> > > > > > > core.pager=cat
> > > > > > > -c safe.bareRepository=all ls-remote
> > > > > > > https://git.yoctoproject.org/linux-yocto.git ',
> > > > > > > d=,
> > > > > > > quiet=True, cleanup=[], log=None, workdir=None):
> > > > > > > 
> > > > > > >     >    raise FetchError(error_message)
> > > > > > > 
> > > > > > > bb.data_smart.ExpansionError: Failure expanding variable
> > > > > > > fetcher_hashes_dummyfunc[vardepvalue], expression was
> > > > > > > ${@bb.fetch.get_hashvalue(d)} which triggered exception
> > > > > > > FetchError: Fetcher failure: Fetch command export
> > > > > > > PSEUDO_DISABLED=1; export
> > > > > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus";
> > > > > > > export
> > > > > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > > > > linux/usr/bin:scripts:/var/home/krm/build/poky/build/tmp/
> > > > > > > work
> > > > > > > /q
> > > > > > > 

Re: [oe-core][PATCH] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Markus Volk
On Sun, Mar 10 2024 at 10:29:32 AM -07:00:00, Alexander Kanavin 
 wrote:

I think you can first add the needed file with a separate DIY patch?


Or maybe convert the recipe to use git? Like this we wouldn't need to 
patch at all:




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196905): 
https://lists.openembedded.org/g/openembedded-core/message/196905
Mute This Topic: https://lists.openembedded.org/mt/104845249/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] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Alexander Kanavin
On Sun, 10 Mar 2024 at 18:03, Markus Volk  wrote:
>
> On Sun, Mar 10 2024 at 08:56:21 AM -07:00:00, Markus Volk  
> wrote:
>
> I'll do some tesing with this patches included in vala and will send a patch 
> for it.
>
>
> The problem I have with creating the backport patches:
>  vapi/metadata/Gtk-4.0.metadata should be patched and that file is not 
> included in the tarball version of vala

I think you can first add the needed file with a separate DIY patch?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196904): 
https://lists.openembedded.org/g/openembedded-core/message/196904
Mute This Topic: https://lists.openembedded.org/mt/104845249/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] Final nanbield release build on March 25, 2024

2024-03-10 Thread Steve Sakoman
On Sun, Mar 10, 2024 at 6:54 AM Martin Jansa  wrote:
>
> Hi Steve,
>
> I'm not using nanbield, but does
> https://wiki.yoctoproject.org/wiki/Releases need to be updated? It
> says "Support for 7 months (until May 2024)" so I was expecting final
> call for dunfell (which says "Long Term Support (until Apr. 2024¹))
> before nanbield.

I work to the release schedule that Stephen sends out each week, the
most recent being:

Upcoming dot releases:

YP 4.3.3 was released.
YP 3.1.32 is in QA.
YP 3.1.32 Release date 2024/03/15
YP 4.0.17 build date 2024/03/11
YP 4.0.17 Release date 2024/03/22
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

So the final nanbield release comes before the final dunfell release.

I will send out a similar final call for dunfell patches.

Steve
> On Sun, Mar 10, 2024 at 5:11 PM Steve Sakoman  wrote:
> >
> > If you have any patches you would like to submit for nanbield before
> > it goes EOL, please do so now!
> >
> > I'll be taking patches until around March 18 in preparation for a
> > March 25 build.
> >
> > Steve
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196903): 
https://lists.openembedded.org/g/openembedded-core/message/196903
Mute This Topic: https://lists.openembedded.org/mt/104846319/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] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Markus Volk
On Sun, Mar 10 2024 at 08:56:21 AM -07:00:00, Markus Volk 
 wrote:
I'll do some tesing with this patches included in vala and will send 
a patch for it.


The problem I have with creating the backport patches:
vapi/metadata/Gtk-4.0.metadata should be patched and that file is not 
included in the tarball version of vala



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196902): 
https://lists.openembedded.org/g/openembedded-core/message/196902
Mute This Topic: https://lists.openembedded.org/mt/104845249/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] Final nanbield release build on March 25, 2024

2024-03-10 Thread Martin Jansa
Hi Steve,

I'm not using nanbield, but does
https://wiki.yoctoproject.org/wiki/Releases need to be updated? It
says "Support for 7 months (until May 2024)" so I was expecting final
call for dunfell (which says "Long Term Support (until Apr. 2024¹))
before nanbield.

Regards,

On Sun, Mar 10, 2024 at 5:11 PM Steve Sakoman  wrote:
>
> If you have any patches you would like to submit for nanbield before
> it goes EOL, please do so now!
>
> I'll be taking patches until around March 18 in preparation for a
> March 25 build.
>
> Steve
>
> 
>

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



[OE-core] Final nanbield release build on March 25, 2024

2024-03-10 Thread Steve Sakoman
If you have any patches you would like to submit for nanbield before
it goes EOL, please do so now!

I'll be taking patches until around March 18 in preparation for a
March 25 build.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196900): 
https://lists.openembedded.org/g/openembedded-core/message/196900
Mute This Topic: https://lists.openembedded.org/mt/104846319/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] [REGRESSION] linux (git/curl-native) and autorev

2024-03-10 Thread Bruce Ashfield
On Sun, Mar 10, 2024 at 11:52 AM Richard Purdie
 wrote:
>
> On Sun, 2024-03-10 at 06:20 -0700, Richard Purdie via
> lists.openembedded.org wrote:
> > On Sun, 2024-03-10 at 13:31 +0100, Max wrote:
> > > Am Samstag, dem 09.03.2024 um 13:04 -0800 schrieb Bruce Ashfield:
> > > > On Sat, Mar 9, 2024 at 12:58 PM  wrote:
> > > > >
> > > > > From: Max Krummenacher 
> > > > >
> > > > > Hello
> > > > >
> > > > > If one builds a kernel using AUTOREV invoking bitbake only
> > > > > works
> > > > > once.
> > > > > Any subsequent bitbake invocation fails parsing the meta data.
> > > > >
> > > > > Reproducable with:
> > > > > - latest poky, b5624ee564
> > > > > - Kernel with SRCREV = "AUTOREV", e.g. in local.conf
> > > > >   `SRCREV_machine:pn-linux-yocto:forcevariable = "${AUTOREV}"`
> > > > > - bitbake virtual/kernel; bitbake virtual/kernel
> > > > >
> > > > > On the second invocation parsing fails when the fetcher tries
> > > > > to
> > > > > evaluate the latest SRCREV:
> > > > >
> > > > > > ERROR: ExpansionError during parsing meta/recipes-
> > > > > > kernel/linux/linux-yocto_6.6.bb
> > > > > > Traceback (most recent call last):
> > > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1245, in
> > > > > > srcrev_internal_helper(ud= > > > > > 0x7f8e26f5f290>, d= > > > > > 0x7f8e26195890>, name='machine'):
> > > > > >  d.setVar("__BBAUTOREV_ACTED_UPON", True)
> > > > > > >srcrev = ud.method.latest_revision(ud, d, name)
> > > > > >
> > > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1667, in
> > > > > > Git.latest_revision(ud= > > > > > 0x7f8e26f5f290>, d= > > > > > 0x7f8e26195890>, name='machine'):
> > > > > >  except KeyError:
> > > > > > >revs[key] = rev = self._latest_revision(ud,
> > > > > > d,
> > > > > > name)
> > > > > >  return rev
> > > > > >   File "bitbake/lib/bb/fetch2/git.py", line 850, in
> > > > > > Git._latest_revision(ud= > > > > > 0x7f8e26f5f290>, d= > > > > > 0x7f8e26195890>, name='machine'):
> > > > > >
> > > > > > >output = self._lsremote(ud, d, "")
> > > > > >  # Tags of the form ^{} may not work, need to
> > > > > > fallback to other form
> > > > > >   File "bitbake/lib/bb/fetch2/git.py", line 833, in
> > > > > > Git._lsremote(ud= > > > > > 0x7f8e26f5f290>, d= > > > > > 0x7f8e26195890>, search=''):
> > > > > >  bb.fetch2.check_network_access(d, cmd,
> > > > > > repourl)
> > > > > > >output = runfetchcmd(cmd, d, True)
> > > > > >  if not output:
> > > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 957, in
> > > > > > runfetchcmd(cmd='export PSEUDO_DISABLED=1; export
> > > > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus";
> > > > > > export
> > > > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > > > linux/usr/bin:scripts:build/tmp/work/qemux86_64-poky-
> > > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-
> > > > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-
> > > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/bin:bitbake/bin:build/tmp/hosttools"; export
> > > > > > HOME="/home/krm"; git -c gc.autoDetach=false -c
> > > > > > core.pager=cat
> > > > > > -c safe.bareRepository=all ls-remote
> > > > > > https://git.yoctoproject.org/linux-yocto.git ',
> > > > > > d=,
> > > > > > quiet=True, cleanup=[], log=None, workdir=None):
> > > > > >
> > > > > > >raise FetchError(error_message)
> > > > > >
> > > > > > bb.data_smart.ExpansionError: Failure expanding variable
> > > > > > fetcher_hashes_dummyfunc[vardepvalue], expression was
> > > > > > ${@bb.fetch.get_hashvalue(d)} which triggered exception
> > > > > > FetchError: Fetcher failure: Fetch command export
> > > > > > PSEUDO_DISABLED=1; export
> > > > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus";
> > > > > > export
> > > > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > > > linux/usr/bin:scripts:/var/home/krm/build/poky/build/tmp/work
> > > > > > /q
> > > > > > emux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-
> > > > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-
> > > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > > 

[OE-core][nanbield 5/5] kernel.bbclass: Set pkg-config variables for building modules

2024-03-10 Thread Steve Sakoman
From: Munehisa Kamata 

The pkg-config workaround has been applied for kernel image building, but
not for module building. So pkg-config variables are different between
do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger
rebuilding of a few host tools at the later task.

Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even
trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt
host tools such as certs/extract-cert or objtool (on x86). This eventually
creates an inconsistent set of kernel binaries.

Here is the repro steps:

 - Check out nanbield on x86
   - The unexpected rebuild happens on kirkstone or possibly earlier

 - Ensure that pahole is available (e.g. via meta-oe)

 - Set KERNEL_DEBUG to "True" to properly set up PAHOLE
   e.g.
   $ export KERNEL_DEBUG="True"
   $ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} 
KERNEL_DEBUG"

 - Enable CONFIG_DEBUG_INFO_BTF=y
   e.g.
   $ bitbake -c menuconfig virtual/kernel
-> Kernel hacking
  -> Compile-time checks and compiler options
-> Generate BTF typeinfo

 - Build the kernel
   e.g.
   $ bitbake virtual/kernel

The BTF information in the resulting bzImage and kernel modules are
inconsistent, because the module's BTF information is generated using the
"second" vmlinux that doesn't have the identical BTF to the "first" vmlinux.
These modules can't be loaded at runtime due to the BTF mismatch.

This also leads to a build-id mismatch between the installed bzImage and
vmlinux since the bzImage is created from the first vmlinux, but the
installed vmlinux is the second one.

  $ eu-readelf -n 
tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*}
 | grep "Build ID"
   Build ID: 4a0d62ee7fef0244950f0f604253729875bea493
   Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9

To avoid the unexpected rebuilding that results in such inconsistency, set
the same pkg-config variables when building kernel and modules. For kernel
5.19 and above, simply set the HOSTPKG_CONFIG in the make command line.

Signed-off-by: Munehisa Kamata 
Signed-off-by: Richard Purdie 
(cherry picked from commit cd2072e5d953af981339427028e19083257e6a92)
Signed-off-by: Steve Sakoman 
---
 meta/classes-recipe/kernel.bbclass | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass 
b/meta/classes-recipe/kernel.bbclass
index 16b85dbca4..2ff2dff9e2 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -239,6 +239,8 @@ KERNEL_EXTRA_ARGS ?= ""
 EXTRA_OEMAKE += ' CC="${KERNEL_CC}" LD="${KERNEL_LD}" 
OBJCOPY="${KERNEL_OBJCOPY}" STRIP="${KERNEL_STRIP}"'
 EXTRA_OEMAKE += ' HOSTCC="${BUILD_CC}" HOSTCFLAGS="${BUILD_CFLAGS}" 
HOSTLDFLAGS="${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}"'
 EXTRA_OEMAKE += ' HOSTCXX="${BUILD_CXX}" HOSTCXXFLAGS="${BUILD_CXXFLAGS}"'
+# Only for newer kernels (5.19+), native pkg-config variables are set for 
older kernels when building kernel and modules
+EXTRA_OEMAKE += ' HOSTPKG_CONFIG="pkg-config-native"'
 
 KERNEL_ALT_IMAGETYPE ??= ""
 
@@ -356,9 +358,6 @@ kernel_do_compile() {
export PKG_CONFIG_LIBDIR="$PKG_CONFIG_DIR"
export PKG_CONFIG_SYSROOT_DIR=""
 
-   # for newer kernels (5.19+) there's a dedicated variable
-   export HOSTPKG_CONFIG="pkg-config-native"
-
if [ "${KERNEL_DEBUG_TIMESTAMPS}" != "1" ]; then
# kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may 
not
# be set
@@ -408,6 +407,13 @@ addtask transform_kernel after do_compile before do_install
 
 do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+
+   # setup native pkg-config variables (kconfig scripts call pkg-config 
directly, cannot generically be overriden to pkg-config-native)
+   export PKG_CONFIG_DIR="${STAGING_DIR_NATIVE}${libdir_native}/pkgconfig"
+   export 
PKG_CONFIG_PATH="$PKG_CONFIG_DIR:${STAGING_DATADIR_NATIVE}/pkgconfig"
+   export PKG_CONFIG_LIBDIR="$PKG_CONFIG_DIR"
+   export PKG_CONFIG_SYSROOT_DIR=""
+
if [ "${KERNEL_DEBUG_TIMESTAMPS}" != "1" ]; then
# kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may 
not
# be set
-- 
2.34.1


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



[OE-core][nanbield 4/5] linux-yocto/6.1: update CVE exclusions

2024-03-10 Thread Steve Sakoman
From: Bruce Ashfield 

Data pulled from: https://github.com/nluedtke/linux_kernel_cves

1/1 [
Author: Nicholas Luedtke
Email: nicholas.lued...@uwalumni.com
Subject: Update 9Feb24
Date: Fri, 9 Feb 2024 18:02:45 -0500

]

Signed-off-by: Bruce Ashfield 
Signed-off-by: Steve Sakoman 
---
 .../linux/cve-exclusion_6.1.inc   | 104 --
 1 file changed, 93 insertions(+), 11 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc 
b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
index 45fcc7b260..cb48e4d88d 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_6.1.inc
@@ -1,9 +1,9 @@
 
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2024-01-18 21:10:06.148505+00:00 for version 6.1.73
+# Generated at 2024-02-21 02:22:41.710563+00:00 for version 6.1.78
 
 python check_kernel_cve_status_version() {
-this_version = "6.1.73"
+this_version = "6.1.78"
 kernel_version = d.getVar("LINUX_VERSION")
 if kernel_version != this_version:
 bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
@@ -3668,6 +3668,10 @@ CVE_STATUS[CVE-2021-3348] = "fixed-version: Fixed from 
version 5.11rc6"
 
 CVE_STATUS[CVE-2021-33624] = "fixed-version: Fixed from version 5.13rc7"
 
+CVE_STATUS[CVE-2021-33630] = "fixed-version: Fixed from version 5.4rc1"
+
+CVE_STATUS[CVE-2021-33631] = "cpe-stable-backport: Backported in 6.1.4"
+
 CVE_STATUS[CVE-2021-33655] = "fixed-version: Fixed from version 5.19rc6"
 
 CVE_STATUS[CVE-2021-33656] = "fixed-version: Fixed from version 5.12rc1"
@@ -4420,7 +4424,7 @@ CVE_STATUS[CVE-2022-3636] = "fixed-version: Fixed from 
version 5.19rc1"
 
 CVE_STATUS[CVE-2022-3640] = "fixed-version: Fixed from version 6.1rc4"
 
-# CVE-2022-36402 has no known resolution
+CVE_STATUS[CVE-2022-36402] = "cpe-stable-backport: Backported in 6.1.50"
 
 # CVE-2022-3642 has no known resolution
 
@@ -4958,7 +4962,7 @@ CVE_STATUS[CVE-2023-35824] = "cpe-stable-backport: 
Backported in 6.1.28"
 
 CVE_STATUS[CVE-2023-35826] = "cpe-stable-backport: Backported in 6.1.28"
 
-# CVE-2023-35827 needs backporting (fixed from 6.1.59)
+CVE_STATUS[CVE-2023-35827] = "cpe-stable-backport: Backported in 6.1.59"
 
 CVE_STATUS[CVE-2023-35828] = "cpe-stable-backport: Backported in 6.1.28"
 
@@ -5032,7 +5036,7 @@ CVE_STATUS[CVE-2023-4015] = "cpe-stable-backport: 
Backported in 6.1.43"
 
 CVE_STATUS[CVE-2023-40283] = "cpe-stable-backport: Backported in 6.1.45"
 
-# CVE-2023-40791 needs backporting (fixed from 6.5rc6)
+CVE_STATUS[CVE-2023-40791] = "fixed-version: only affects 6.3rc1 onwards"
 
 CVE_STATUS[CVE-2023-4128] = "cpe-stable-backport: Backported in 6.1.45"
 
@@ -5100,9 +5104,15 @@ CVE_STATUS[CVE-2023-4611] = "fixed-version: only affects 
6.4rc1 onwards"
 
 CVE_STATUS[CVE-2023-4623] = "cpe-stable-backport: Backported in 6.1.53"
 
-# CVE-2023-46813 needs backporting (fixed from 6.1.60)
+CVE_STATUS[CVE-2023-46343] = "cpe-stable-backport: Backported in 6.1.60"
+
+CVE_STATUS[CVE-2023-46813] = "cpe-stable-backport: Backported in 6.1.60"
 
-# CVE-2023-46862 needs backporting (fixed from 6.6)
+CVE_STATUS[CVE-2023-46838] = "cpe-stable-backport: Backported in 6.1.75"
+
+CVE_STATUS[CVE-2023-46862] = "cpe-stable-backport: Backported in 6.1.61"
+
+# CVE-2023-47233 has no known resolution
 
 CVE_STATUS[CVE-2023-4732] = "fixed-version: Fixed from version 5.14rc1"
 
@@ -5110,10 +5120,14 @@ CVE_STATUS[CVE-2023-4881] = "cpe-stable-backport: 
Backported in 6.1.54"
 
 CVE_STATUS[CVE-2023-4921] = "cpe-stable-backport: Backported in 6.1.54"
 
-# CVE-2023-50431 has no known resolution
+CVE_STATUS[CVE-2023-50431] = "cpe-stable-backport: Backported in 6.1.75"
 
 CVE_STATUS[CVE-2023-5090] = "cpe-stable-backport: Backported in 6.1.62"
 
+CVE_STATUS[CVE-2023-51042] = "cpe-stable-backport: Backported in 6.1.47"
+
+CVE_STATUS[CVE-2023-51043] = "cpe-stable-backport: Backported in 6.1.40"
+
 CVE_STATUS[CVE-2023-5158] = "cpe-stable-backport: Backported in 6.1.57"
 
 CVE_STATUS[CVE-2023-51779] = "cpe-stable-backport: Backported in 6.1.70"
@@ -5128,11 +5142,13 @@ CVE_STATUS[CVE-2023-51782] = "cpe-stable-backport: 
Backported in 6.1.69"
 
 CVE_STATUS[CVE-2023-5197] = "cpe-stable-backport: Backported in 6.1.56"
 
+CVE_STATUS[CVE-2023-52340] = "cpe-stable-backport: Backported in 6.1.73"
+
 CVE_STATUS[CVE-2023-5345] = "cpe-stable-backport: Backported in 6.1.56"
 
 CVE_STATUS[CVE-2023-5633] = "fixed-version: only affects 6.2 onwards"
 
-# CVE-2023-5717 needs backporting (fixed from 6.1.60)
+CVE_STATUS[CVE-2023-5717] = "cpe-stable-backport: Backported in 6.1.60"
 
 CVE_STATUS[CVE-2023-5972] = "fixed-version: only affects 6.2rc1 onwards"
 
@@ -5146,8 +5162,12 @@ CVE_STATUS[CVE-2023-6121] = "cpe-stable-backport: 
Backported in 6.1.65"
 
 CVE_STATUS[CVE-2023-6176] = "cpe-stable-backport: Backported in 6.1.54"
 
+CVE_STATUS[CVE-2023-6200] = "fixed-version: only 

[OE-core][nanbield 3/5] linux-yocto/6.1: update to v6.1.78

2024-03-10 Thread Steve Sakoman
From: Bruce Ashfield 

Updating linux-yocto/6.1 to the latest korg -stable release that comprises
the following commits:

8b4118fabd6e Linux 6.1.78
1296c110c5a0 netfilter: nft_set_rbtree: skip end interval element from gc
d89a80e4827d net: stmmac: xgmac: fix a typo of register name in DPP safety 
handling
7b430fb92440 ALSA: usb-audio: Sort quirk table entries
06040fadbfef net: stmmac: xgmac: use #define for string constants
499e6e9f0737 clocksource: Skip watchdog check for large watchdog intervals
492e0aba0884 block: treat poll queue enter similarly to timeouts
cf3d57ad6ff8 f2fs: add helper to check compression level
9f74b3d7183a RDMA/irdma: Fix support for 64k pages
4675661672e3 vhost: use kzalloc() instead of kmalloc() followed by memset()
d8712c6c6a38 Revert "ASoC: amd: Add new dmi entries for acp5x platform"
fbd77ce1d174 io_uring/net: fix sr->len for IORING_OP_RECV with MSG_WAITALL 
and buffers
08249dc3d9c1 Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping 
ATKBD_CMD_GETID
315075ac739c Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU
a94d303bea6b hrtimer: Report offline hrtimer enqueue
8b380ad970d0 usb: host: xhci-plat: Add support for 
XHCI_SG_TRB_CACHE_SIZE_QUIRK
f2cf6db28545 usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK
041cb58f54f5 USB: serial: cp210x: add ID for IMST iM871A-USB
36ef5b7b4f0a USB: serial: option: add Fibocom FM101-GL variant
234099ab7f8a USB: serial: qcserial: add new usb-id for Dell Wireless DW5826e
39fbca505fe6 ALSA: usb-audio: add quirk for RODE NT-USB+
2552f6b1bd64 ALSA: usb-audio: Add a quirk for Yamaha YIT-W12TX transmitter
b8259a502320 ALSA: usb-audio: Add delay quirk for MOTU M Series 2nd revision
82761993d429 mtd: parsers: ofpart: add workaround for #size-cells 0
b478e414cf85 fs: dlm: don't put dlm_local_addrs on heap
e5dc63f01e02 blk-iocost: Fix an UBSAN shift-out-of-bounds warning
1ebd75cefaac scsi: core: Move scsi_host_busy() out of host lock if it is 
for per-command
ec1bedd79758 fs/ntfs3: Fix an NULL dereference bug
a442ff5405d7 netfilter: nft_set_pipapo: remove scratch_aligned pointer
fac3478d5b87 netfilter: nft_set_pipapo: add helper to release pcpu scratch 
area
3eaab7d565be netfilter: nft_set_pipapo: store index in scratch maps
181dade25130 netfilter: nft_ct: reject direction for ct id
efdd665ce1a1 drm/amd/display: Implement bounds check for stream encoder 
creation in DCN301
a060da32357a netfilter: nft_compat: restrict match/target protocol to u16
8762bcc92719 netfilter: nft_compat: reject unused compat flag
e79ef7966ee9 netfilter: nft_compat: narrow down revision to unsigned 8-bits
69d66d493b1f selftests: cmsg_ipv6: repeat the exact packet
4e2c4846b250 ppp_async: limit MRU to 64K
e0e09186d882 af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
3d3a5b31b435 tipc: Check the bearer type before calling 
tipc_udp_nl_bearer_add()
cf6b97e1830e rxrpc: Fix response to PING RESPONSE ACKs to a dead call
05a4d0e16615 drm/i915/gvt: Fix uninitialized variable in handle_mmio()
54538752216b inet: read sk->sk_family once in inet_recv_error()
3fa78ee0e381 hwmon: (coretemp) Fix bogus core_id to attr name mapping
9bce69419271 hwmon: (coretemp) Fix out-of-bounds memory access
a3156be201cf hwmon: (aspeed-pwm-tacho) mutex for tach reading
406574668634 octeontx2-pf: Fix a memleak otx2_sq_init
cbf2e1660259 atm: idt77252: fix a memleak in open_card_ubr0
e37cde7a5716 tunnels: fix out of bounds access when building IPv6 PMTU error
90fe47743a2b selftests: net: avoid just another constant wait
7f484179c53a selftests: net: cut more slack for gro fwd tests.
466ceebe48cb net: atlantic: Fix DMA mapping for PTP hwts ring
0193e0660cc6 netdevsim: avoid potential loop in nsim_dev_trap_report_work()
bcabbf8ab5c6 wifi: mac80211: fix waiting for beacons logic
e42ff0844fe4 net: stmmac: xgmac: fix handling of DPP safety error for DMA 
channels
fb8bfc6ea3cd drm/msm/dpu: check for valid hw_pp in 
dpu_encoder_helper_phys_cleanup
42939a1ea6d4 drm/msm/dp: return correct Colorimetry for 
DP_TEST_DYNAMIC_RANGE_CEA case
d2b7e247f368 drm/msms/dp: fixed link clock divider bits be over written in 
BPC unknown case
cbc53148cc09 cifs: failure to add channel on iface should bump up weight
0430bfcd4665 phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
296fb308f4f8 dmaengine: fix is_slave_direction() return false when 
DMA_DEV_TO_DEV
ed3bb52a05d3 phy: renesas: rcar-gen3-usb2: Fix returning wrong error code
25ab4d72eb7c dmaengine: fsl-qdma: Fix a memory leak related to the queue 
command DMA
13535ae76655 dmaengine: fsl-qdma: Fix a memory leak related to the status 
queue DMA
908939b8e81a dmaengine: ti: k3-udma: Report short packet errors
a1d7ca71ba1a dmaengine: fsl-dpaa2-qdma: Fix the size of dma pools
78327acd4cdc 

[OE-core][nanbield 0/5] Patch review

2024-03-10 Thread Steve Sakoman
Please review this set of changes for nanbield and have comments back by
end of day Tuesday, March 12

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6663

The following changes since commit 82dd61aade02456621cd2958b2fbb56236062789:

  multilib_global.bbclass: fix parsing error with no kernel module split 
(2024-02-14 07:09:08 -1000)

are available in the Git repository at:

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

Bruce Ashfield (2):
  linux-yocto/6.1: update to v6.1.78
  linux-yocto/6.1: update CVE exclusions

Dhairya Nagodra (1):
  glibc: Remove duplicate entry for CVE-2023-4527

Munehisa Kamata (1):
  kernel.bbclass: Set pkg-config variables for building modules

Tim Orling (1):
  vim: upgrade v9.0.2130 -> v9.0.2190

 meta/classes-recipe/kernel.bbclass|  12 +-
 meta/recipes-core/glibc/glibc-version.inc |   1 -
 .../linux/cve-exclusion_6.1.inc   | 104 --
 .../linux/linux-yocto-rt_6.1.bb   |   6 +-
 .../linux/linux-yocto-tiny_6.1.bb |   6 +-
 meta/recipes-kernel/linux/linux-yocto_6.1.bb  |  28 ++---
 meta/recipes-support/vim/vim.inc  |   4 +-
 7 files changed, 124 insertions(+), 37 deletions(-)

-- 
2.34.1


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



[OE-core][nanbield 2/5] vim: upgrade v9.0.2130 -> v9.0.2190

2024-03-10 Thread Steve Sakoman
From: Tim Orling 

This is the latest/last of the 9.0.z upgrades, since 9.1 is now
released.

CVE: CVE-2024-22667
(includes the patch for .2142 
https://github.com/vim/vim/commit/b39b240c386a5a29241415541f1c99e2e6b8ce47)

Changes:
https://github.com/vim/vim/compare/v9.0.2130...v9.0.2190

Signed-off-by: Tim Orling 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-support/vim/vim.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 6b440d8947..906aa53a16 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -19,8 +19,8 @@ SRC_URI = 
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://no-path-adjust.patch \
"
 
-PV .= ".2130"
-SRCREV = "075ad7047457debfeef13442c01e74088b461092"
+PV .= ".2190"
+SRCREV = "6a950da86d7a6eb09d5ebeab17657986420d07ac"
 
 # Do not consider .z in x.y.z, as that is updated with every commit
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.\d+)\.0"
-- 
2.34.1


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



[OE-core][nanbield 1/5] glibc: Remove duplicate entry for CVE-2023-4527

2024-03-10 Thread Steve Sakoman
From: Dhairya Nagodra 

Signed-off-by: Dhairya Nagodra 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/glibc/glibc-version.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index 212f960cb5..ee89762ae6 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -11,7 +11,6 @@ CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable 
branch updates"
 CVE_STATUS[CVE-2023-4911] = "fixed-version: Fixed in stable branch updates"
 CVE_STATUS[CVE-2023-4806] = "fixed-version: Fixed in stable branch updates"
 CVE_STATUS[CVE-2023-5156] = "fixed-version: Fixed in stable branch updates"
-CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates"
 CVE_STATUS[CVE-2023-0687] = "fixed-version: Fixed in stable branch updates"
 CVE_STATUS[CVE-2023-6246] = "fixed-version: Fixed in stable branch updates"
 CVE_STATUS[CVE-2023-6779] = "fixed-version: Fixed in stable branch updates"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196894): 
https://lists.openembedded.org/g/openembedded-core/message/196894
Mute This Topic: https://lists.openembedded.org/mt/104846126/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] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Markus Volk
On Sun, Mar 10 2024 at 08:48:39 AM -07:00:00, Richard Purdie 
 wrote:

Given where we are with release that does look preferable to an
experimental GTK verison...


I'll do some tesing with this patches included in vala and will send a 
patch for it.
But I guess because of this blog post, that gtk 4.14 can be considered 
as almost ready




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196892): 
https://lists.openembedded.org/g/openembedded-core/message/196892
Mute This Topic: https://lists.openembedded.org/mt/104845249/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] [REGRESSION] linux (git/curl-native) and autorev

2024-03-10 Thread Richard Purdie
On Sun, 2024-03-10 at 06:20 -0700, Richard Purdie via
lists.openembedded.org wrote:
> On Sun, 2024-03-10 at 13:31 +0100, Max wrote:
> > Am Samstag, dem 09.03.2024 um 13:04 -0800 schrieb Bruce Ashfield:
> > > On Sat, Mar 9, 2024 at 12:58 PM  wrote:
> > > > 
> > > > From: Max Krummenacher 
> > > > 
> > > > Hello
> > > > 
> > > > If one builds a kernel using AUTOREV invoking bitbake only
> > > > works
> > > > once.
> > > > Any subsequent bitbake invocation fails parsing the meta data.
> > > > 
> > > > Reproducable with:
> > > > - latest poky, b5624ee564
> > > > - Kernel with SRCREV = "AUTOREV", e.g. in local.conf
> > > >   `SRCREV_machine:pn-linux-yocto:forcevariable = "${AUTOREV}"`
> > > > - bitbake virtual/kernel; bitbake virtual/kernel
> > > > 
> > > > On the second invocation parsing fails when the fetcher tries
> > > > to
> > > > evaluate the latest SRCREV:
> > > > 
> > > > > ERROR: ExpansionError during parsing meta/recipes-
> > > > > kernel/linux/linux-yocto_6.6.bb
> > > > > Traceback (most recent call last):
> > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1245, in
> > > > > srcrev_internal_helper(ud= > > > > 0x7f8e26f5f290>, d= > > > > 0x7f8e26195890>, name='machine'):
> > > > >  d.setVar("__BBAUTOREV_ACTED_UPON", True)
> > > > >     >    srcrev = ud.method.latest_revision(ud, d, name)
> > > > > 
> > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1667, in
> > > > > Git.latest_revision(ud= > > > > 0x7f8e26f5f290>, d= > > > > 0x7f8e26195890>, name='machine'):
> > > > >  except KeyError:
> > > > >     >    revs[key] = rev = self._latest_revision(ud,
> > > > > d,
> > > > > name)
> > > > >  return rev
> > > > >   File "bitbake/lib/bb/fetch2/git.py", line 850, in
> > > > > Git._latest_revision(ud= > > > > 0x7f8e26f5f290>, d= > > > > 0x7f8e26195890>, name='machine'):
> > > > > 
> > > > >     >    output = self._lsremote(ud, d, "")
> > > > >  # Tags of the form ^{} may not work, need to
> > > > > fallback to other form
> > > > >   File "bitbake/lib/bb/fetch2/git.py", line 833, in
> > > > > Git._lsremote(ud= > > > > 0x7f8e26f5f290>, d= > > > > 0x7f8e26195890>, search=''):
> > > > >  bb.fetch2.check_network_access(d, cmd,
> > > > > repourl)
> > > > >     >    output = runfetchcmd(cmd, d, True)
> > > > >  if not output:
> > > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 957, in
> > > > > runfetchcmd(cmd='export PSEUDO_DISABLED=1; export
> > > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus";
> > > > > export
> > > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > > linux/usr/bin:scripts:build/tmp/work/qemux86_64-poky-
> > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-
> > > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-
> > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > native/bin:bitbake/bin:build/tmp/hosttools"; export
> > > > > HOME="/home/krm"; git -c gc.autoDetach=false -c
> > > > > core.pager=cat
> > > > > -c safe.bareRepository=all ls-remote
> > > > > https://git.yoctoproject.org/linux-yocto.git ',
> > > > > d=,
> > > > > quiet=True, cleanup=[], log=None, workdir=None):
> > > > > 
> > > > >     >    raise FetchError(error_message)
> > > > > 
> > > > > bb.data_smart.ExpansionError: Failure expanding variable
> > > > > fetcher_hashes_dummyfunc[vardepvalue], expression was
> > > > > ${@bb.fetch.get_hashvalue(d)} which triggered exception
> > > > > FetchError: Fetcher failure: Fetch command export
> > > > > PSEUDO_DISABLED=1; export
> > > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus";
> > > > > export
> > > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > > linux/usr/bin:scripts:/var/home/krm/build/poky/build/tmp/work
> > > > > /q
> > > > > emux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-
> > > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-
> > > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > > yocto/6.6.20+git/recipe-sysroot-
> > > > > native/bin:bitbake/bin:build/tmp/hosttools"; export
> > > > > 

Re: [oe-core][PATCH] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Richard Purdie
On Sun, 2024-03-10 at 08:19 -0700, Markus Volk wrote:
> another way to fix this would probably be to backport this to vala:
> https://gitlab.gnome.org/GNOME/vala/-/commit/e0c4ea8c4a0bbf859b5341a7465b395892789d9e

Given where we are with release that does look preferable to an
experimental GTK verison...

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196890): 
https://lists.openembedded.org/g/openembedded-core/message/196890
Mute This Topic: https://lists.openembedded.org/mt/104845249/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] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Markus Volk

another way to fix this would probably be to backport this to vala:


On Sun, Mar 10 2024 at 08:19:11 AM -07:00:00, Markus Volk 
 wrote:

vala has been updated to 0.56.15 and this version requires gtk 4.14

Update to gtk 4.14 prerelease to fix compile of vala programs that 
would

otherwise fail with:
/usr/src/debug/granite/7.4.0/lib/libgranite-7.so.7.4.0.p/Widgets/DatePicker.c:248:
(.text+0x6b8): undefined reference to `gtk_calendar_get_year'

- remove ffmpeg PACKAGECONFIG as the ffmpeg backend has been removed

Overview of Changes in 4.13.9, 02-03-2024
=

Note: The new renderers and dmabuf support are using graphics drivers
in different ways than the old gl renderer, and trigger new driver 
bugs,
(see for example  
and

). Therefore, it is
recommended to use the latest mesa release (24.x) with the new 
renderers.


* GtkEditable:
 - Fix preconditions to be not too strict

* GtkEmojiChooser:
 - Support search in the locale as well as in English

* GtkIconTheme:
 - Make gtk_icon_paintable_new_for_file support symbolics

* GtkVideo:
 - Fix a problem with cursor handling that could lead to crashes

* Accessibility:
 - Fix GetCharacterAtOffset implementation
 - Add a Terminal role
 - Make TextCaretMoved match gtk3
 - Support multiple levels of GtkEditable delegates

* GSK:
 - Make the node parser more flexible for text nodes
 - Change the way font scaling is handled to avoid clipping
 - Fix handling of missing glyphs in the new renderers

* X11:
 - Don't claim to support shadows without a compositor

* Wayland:
 - Fix handling of output scales

* Tools:
 - Add a compare command to gtk4-rendernode-tool

* Build:
 - Fix some ubsan complaints

* Translation updates:
 Basque
 British English
 Catalan
 Finnish
 Galician
 Georgian
 Hebrew
 Indonesian
 Kazakh
 Latvian
 Lithuanian
 Persian
 Polish
 Russian
 Slovenian
 Spanish
 Turkish
 Ukrainian

Overview of Changes in 4.13.8, 20-02-2024
=

* Accessibility:
 - Add a GtkAccessibleText interface for allowing 3rd party
   text widgets (notably vte) to be accessible
 - Avoid duplicate accessible descriptions
 - Fix GetAccessibleAtPoint

* GSK:
 - Avoid offscreens for disjoint containers
 - Don't use the gpu renderers with llvmpipe
 - Fix various rendering issues found by tests
 - Allow unnormalized node bounds again
 - Fix a broken case of rounded-rect intersection
 - Fix handling of external textures in gpu renderers
 - Make gpu renderers work with WGL on Windows

* build:
 - Allow building without dmabuf support on (old) Linux

* X11:
 - Fix monitor enter/leave signals

* Translation updates:
 Basque
 Brazilian Portuguese
 Catalan
 Czech
 Galician
 Georgian
 Hebrew
 Lithuanian
 Persian
 Russian
 Turkish
 Ukrainian

Overview of Changes in 4.13.7, 11-02-2024
=

* GtkFileChooser:
 - Speed up opening

* GtkCalendar:
 - Add some missing setters and getters

* Accessibility:
 - Add socket support for webkit accessibility
 - Implement AT-SPI text for GtkText
 - Implement AT-SPI component generically
 - Add an announce API

* GSK:
 - Make the ngl renderer work on macOS
 - Fix a crash in the vulkan renderer
 - Make nodeparser allow aliases for fonts again
 - Implement cache eviction for glyph and texture caches
 - Fix ngl shaders to work on GL < 4.0
 - Require GL 3.3 for the ngl renderer
 - Fix problems with scaled shadows
 - Fix problems with holes for underlaid subsurfaces
 - Improve handling of scales and glyph cache efficiency

* Media:
 - Support dmabufs in the gstreamer backend. This allows
   zero-copy video playback on Wayland when paired with
   hardware video decoding
 - Drop the experimental ffmpeg backend. It hasn't been
   building for a year

* Wayland:
 - Commit empty frames if and double-buffered state is pending
 - Fix monitor size information when using mutter without
   the scale-monitor-framebuffer setting
 - Clear the current tablet on tab leave, fixing a crash

* macOS:
 - Propagate unhandled input events back to the OS

* Tools:
 - Make the crash handling in gtk4-node-editor more robust

* Translation updates
 Galician
 Georgian
 Occitan
 Turkish

Overview of Changes in 4.13.6, 25-01-2024
=

This release changes the ngl renderer to be the default renderer.

The intent of this change is to get wider testing and verify that
the new renderers are production-ready. If significant problems
show up, we will revert this change for 4.14.

You can still override the renderer choice using the GSK_RENDERER
environment variable.

Since ngl can handle fractional scaling much better than the old gl
renderer, we allow fractional scaling by default with gl now. If you
are using the old gl renderer (e.g. because your system is 

[oe-core][PATCH] gtk4: update 4.12.5 -> 4.13.9

2024-03-10 Thread Markus Volk
vala has been updated to 0.56.15 and this version requires gtk 4.14

Update to gtk 4.14 prerelease to fix compile of vala programs that would
otherwise fail with:
/usr/src/debug/granite/7.4.0/lib/libgranite-7.so.7.4.0.p/Widgets/DatePicker.c:248:
(.text+0x6b8): undefined reference to `gtk_calendar_get_year'

- remove ffmpeg PACKAGECONFIG as the ffmpeg backend has been removed

Overview of Changes in 4.13.9, 02-03-2024
=

Note: The new renderers and dmabuf support are using graphics drivers
in different ways than the old gl renderer, and trigger new driver bugs,
(see for example https://gitlab.gnome.org/GNOME/gtk/-/issues/6418 and
https://gitlab.gnome.org/GNOME/gtk/-/issues/6388). Therefore, it is
recommended to use the latest mesa release (24.x) with the new renderers.

* GtkEditable:
 - Fix preconditions to be not too strict

* GtkEmojiChooser:
 - Support search in the locale as well as in English

* GtkIconTheme:
 - Make gtk_icon_paintable_new_for_file support symbolics

* GtkVideo:
 - Fix a problem with cursor handling that could lead to crashes

* Accessibility:
 - Fix GetCharacterAtOffset implementation
 - Add a Terminal role
 - Make TextCaretMoved match gtk3
 - Support multiple levels of GtkEditable delegates

* GSK:
 - Make the node parser more flexible for text nodes
 - Change the way font scaling is handled to avoid clipping
 - Fix handling of missing glyphs in the new renderers

* X11:
 - Don't claim to support shadows without a compositor

* Wayland:
 - Fix handling of output scales

* Tools:
 - Add a compare command to gtk4-rendernode-tool

* Build:
 - Fix some ubsan complaints

* Translation updates:
 Basque
 British English
 Catalan
 Finnish
 Galician
 Georgian
 Hebrew
 Indonesian
 Kazakh
 Latvian
 Lithuanian
 Persian
 Polish
 Russian
 Slovenian
 Spanish
 Turkish
 Ukrainian

Overview of Changes in 4.13.8, 20-02-2024
=

* Accessibility:
 - Add a GtkAccessibleText interface for allowing 3rd party
   text widgets (notably vte) to be accessible
 - Avoid duplicate accessible descriptions
 - Fix GetAccessibleAtPoint

* GSK:
 - Avoid offscreens for disjoint containers
 - Don't use the gpu renderers with llvmpipe
 - Fix various rendering issues found by tests
 - Allow unnormalized node bounds again
 - Fix a broken case of rounded-rect intersection
 - Fix handling of external textures in gpu renderers
 - Make gpu renderers work with WGL on Windows

* build:
 - Allow building without dmabuf support on (old) Linux

* X11:
 - Fix monitor enter/leave signals

* Translation updates:
 Basque
 Brazilian Portuguese
 Catalan
 Czech
 Galician
 Georgian
 Hebrew
 Lithuanian
 Persian
 Russian
 Turkish
 Ukrainian

Overview of Changes in 4.13.7, 11-02-2024
=

* GtkFileChooser:
 - Speed up opening

* GtkCalendar:
 - Add some missing setters and getters

* Accessibility:
 - Add socket support for webkit accessibility
 - Implement AT-SPI text for GtkText
 - Implement AT-SPI component generically
 - Add an announce API

* GSK:
 - Make the ngl renderer work on macOS
 - Fix a crash in the vulkan renderer
 - Make nodeparser allow aliases for fonts again
 - Implement cache eviction for glyph and texture caches
 - Fix ngl shaders to work on GL < 4.0
 - Require GL 3.3 for the ngl renderer
 - Fix problems with scaled shadows
 - Fix problems with holes for underlaid subsurfaces
 - Improve handling of scales and glyph cache efficiency

* Media:
 - Support dmabufs in the gstreamer backend. This allows
   zero-copy video playback on Wayland when paired with
   hardware video decoding
 - Drop the experimental ffmpeg backend. It hasn't been
   building for a year

* Wayland:
 - Commit empty frames if and double-buffered state is pending
 - Fix monitor size information when using mutter without
   the scale-monitor-framebuffer setting
 - Clear the current tablet on tab leave, fixing a crash

* macOS:
 - Propagate unhandled input events back to the OS

* Tools:
 - Make the crash handling in gtk4-node-editor more robust

* Translation updates
 Galician
 Georgian
 Occitan
 Turkish

Overview of Changes in 4.13.6, 25-01-2024
=

This release changes the ngl renderer to be the default renderer.

The intent of this change is to get wider testing and verify that
the new renderers are production-ready. If significant problems
show up, we will revert this change for 4.14.

You can still override the renderer choice using the GSK_RENDERER
environment variable.

Since ngl can handle fractional scaling much better than the old gl
renderer, we allow fractional scaling by default with gl now. If you
are using the old gl renderer (e.g. because your system is limited to
GLES2), you can disable fractional scaling by setting the GDK_DEBUG
environment variable to include the gl-no-fractional key.

* GtkColumnView:
 - Fix infinite loops in dispose
 - Fix problems with weak ref cycles in 

Re: [OE-core] [PATCH] ptest: test for PTEST_ENABLED instead of DISTRO_FEATURES

2024-03-10 Thread Martin Jansa
On Sun, Mar 10, 2024 at 3:11 PM Robert P. J. Day  wrote:
>
> On Sun, 10 Mar 2024, Alexander Kanavin wrote:
>
> > On Sat, 9 Mar 2024 at 11:29, Robert P. J. Day  wrote:
> > > As ptest.bbclass defines the more intuitive ptest-related variable:
> > >
> > >   PTEST_ENABLED =
> > > "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
> > >
> > > modify a number of obvious recipe ptest checks to use that simpler
> > > form.
> >
> > I disagree. When someone reads a recipe, and sees a variable, the
> > questions that typically come up are:
> >
> > - where is it set
> > - how is it set
> > - what needs to be done to change it.
> >
> > DISTRO_FEATURES wins all three, as it's commonly known and understood 
> > facility.
>
>   then what is the point of defining PTEST_ENABLED in the first place?
> and using a mixture of both throughout the code base?

I've used PTEST_ENABLED few times to disable ptest support in specific
recipe while it's "by default" enabled through DISTRO_FEATURES.

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



[OE-core] OE-core CVE metrics for nanbield on Sun 10 Mar 2024 04:00:01 AM HST

2024-03-10 Thread Steve Sakoman
Branch: nanbield

New this week: 0 CVEs

Removed this week: 2 CVEs
CVE-2023-3164 (CVSS3: 5.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 *
CVE-2023-38559 (CVSS3: 5.5 MEDIUM): ghostscript 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38559 *

Full list:  Found 117 unpatched CVEs
CVE-2019-14899 (CVSS3: 7.4 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 *
CVE-2021-3714 (CVSS3: 5.9 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-36402 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36402 *
CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
CVE-2023-3019 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 *
CVE-2023-3397 (CVSS3: 6.3 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3397 *
CVE-2023-3640 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 *
CVE-2023-39189 (CVSS3: 6.0 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-39189 *
CVE-2023-39192 (CVSS3: 6.0 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-39192 *
CVE-2023-39193 (CVSS3: 6.0 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-39193 *
CVE-2023-39928 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-39928 *
CVE-2023-4001 (CVSS3: 6.8 MEDIUM): grub:grub-efi:grub-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4001 *
CVE-2023-4010 (CVSS3: 4.6 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 *
CVE-2023-42363 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 *
CVE-2023-42364 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 *
CVE-2023-42365 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 *
CVE-2023-42366 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 *
CVE-2023-42753 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42753 *
CVE-2023-42754 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42754 *
CVE-2023-42756 (CVSS3: 4.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42756 *
CVE-2023-4623 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4623 *
CVE-2023-46407 (CVSS3: 5.5 MEDIUM): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-46407 *
CVE-2023-46838 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-46838 *
CVE-2023-47470 (CVSS3: 7.8 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-47470 *
CVE-2023-48795 (CVSS3: 5.9 MEDIUM): openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-48795 *
CVE-2023-4921 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4921 *
CVE-2023-49292 (CVSS3: 4.8 MEDIUM): 
go:go-binary-native:go-cross-core2-64:go-runtime 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-49292 *
CVE-2023-50387 (CVSS3: 7.5 HIGH): bind 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-50387 *
CVE-2023-50431 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-50431 *
CVE-2023-5088 (CVSS3: 7.0 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5088 *
CVE-2023-51384 (CVSS3: 5.5 MEDIUM): openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51384 *
CVE-2023-51385 (CVSS3: 6.5 MEDIUM): openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51385 *
CVE-2023-51767 (CVSS3: 7.0 HIGH): openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 *
CVE-2023-5178 (CVSS3: 9.8 CRITICAL): linux-yocto 

Re: [OE-core] [PATCH] ptest: test for PTEST_ENABLED instead of DISTRO_FEATURES

2024-03-10 Thread Robert P. J. Day
On Sun, 10 Mar 2024, Alexander Kanavin wrote:

> On Sat, 9 Mar 2024 at 11:29, Robert P. J. Day  wrote:
> > As ptest.bbclass defines the more intuitive ptest-related variable:
> >
> >   PTEST_ENABLED =
> > "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
> >
> > modify a number of obvious recipe ptest checks to use that simpler
> > form.
>
> I disagree. When someone reads a recipe, and sees a variable, the
> questions that typically come up are:
>
> - where is it set
> - how is it set
> - what needs to be done to change it.
>
> DISTRO_FEATURES wins all three, as it's commonly known and understood 
> facility.

  then what is the point of defining PTEST_ENABLED in the first place?
and using a mixture of both throughout the code base?

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196885): 
https://lists.openembedded.org/g/openembedded-core/message/196885
Mute This Topic: https://lists.openembedded.org/mt/104825491/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] ptest: test for PTEST_ENABLED instead of DISTRO_FEATURES

2024-03-10 Thread Alexander Kanavin
On Sat, 9 Mar 2024 at 11:29, Robert P. J. Day  wrote:
> As ptest.bbclass defines the more intuitive ptest-related variable:
>
>   PTEST_ENABLED =
> "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
>
> modify a number of obvious recipe ptest checks to use that simpler
> form.

I disagree. When someone reads a recipe, and sees a variable, the
questions that typically come up are:

- where is it set
- how is it set
- what needs to be done to change it.

DISTRO_FEATURES wins all three, as it's commonly known and understood facility.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196884): 
https://lists.openembedded.org/g/openembedded-core/message/196884
Mute This Topic: https://lists.openembedded.org/mt/104825491/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] [REGRESSION] linux (git/curl-native) and autorev

2024-03-10 Thread Richard Purdie
On Sun, 2024-03-10 at 13:31 +0100, Max wrote:
> Am Samstag, dem 09.03.2024 um 13:04 -0800 schrieb Bruce Ashfield:
> > On Sat, Mar 9, 2024 at 12:58 PM  wrote:
> > > 
> > > From: Max Krummenacher 
> > > 
> > > Hello
> > > 
> > > If one builds a kernel using AUTOREV invoking bitbake only works
> > > once.
> > > Any subsequent bitbake invocation fails parsing the meta data.
> > > 
> > > Reproducable with:
> > > - latest poky, b5624ee564
> > > - Kernel with SRCREV = "AUTOREV", e.g. in local.conf
> > >   `SRCREV_machine:pn-linux-yocto:forcevariable = "${AUTOREV}"`
> > > - bitbake virtual/kernel; bitbake virtual/kernel
> > > 
> > > On the second invocation parsing fails when the fetcher tries to
> > > evaluate the latest SRCREV:
> > > 
> > > > ERROR: ExpansionError during parsing meta/recipes-
> > > > kernel/linux/linux-yocto_6.6.bb
> > > > Traceback (most recent call last):
> > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1245, in
> > > > srcrev_internal_helper(ud= > > > 0x7f8e26f5f290>, d= > > > 0x7f8e26195890>, name='machine'):
> > > >  d.setVar("__BBAUTOREV_ACTED_UPON", True)
> > > >     >    srcrev = ud.method.latest_revision(ud, d, name)
> > > > 
> > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1667, in
> > > > Git.latest_revision(ud= > > > 0x7f8e26f5f290>, d= > > > 0x7f8e26195890>, name='machine'):
> > > >  except KeyError:
> > > >     >    revs[key] = rev = self._latest_revision(ud, d,
> > > > name)
> > > >  return rev
> > > >   File "bitbake/lib/bb/fetch2/git.py", line 850, in
> > > > Git._latest_revision(ud= > > > 0x7f8e26f5f290>, d= > > > 0x7f8e26195890>, name='machine'):
> > > > 
> > > >     >    output = self._lsremote(ud, d, "")
> > > >  # Tags of the form ^{} may not work, need to
> > > > fallback to other form
> > > >   File "bitbake/lib/bb/fetch2/git.py", line 833, in
> > > > Git._lsremote(ud= > > > 0x7f8e26f5f290>, d= > > > 0x7f8e26195890>, search=''):
> > > >  bb.fetch2.check_network_access(d, cmd,
> > > > repourl)
> > > >     >    output = runfetchcmd(cmd, d, True)
> > > >  if not output:
> > > >   File "bitbake/lib/bb/fetch2/__init__.py", line 957, in
> > > > runfetchcmd(cmd='export PSEUDO_DISABLED=1; export
> > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus"; export
> > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > linux/usr/bin:scripts:build/tmp/work/qemux86_64-poky-
> > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-
> > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-
> > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > yocto/6.6.20+git/recipe-sysroot-
> > > > native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > yocto/6.6.20+git/recipe-sysroot-
> > > > native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > yocto/6.6.20+git/recipe-sysroot-
> > > > native/bin:bitbake/bin:build/tmp/hosttools"; export
> > > > HOME="/home/krm"; git -c gc.autoDetach=false -c core.pager=cat
> > > > -c safe.bareRepository=all ls-remote
> > > > https://git.yoctoproject.org/linux-yocto.git ',
> > > > d=,
> > > > quiet=True, cleanup=[], log=None, workdir=None):
> > > > 
> > > >     >    raise FetchError(error_message)
> > > > 
> > > > bb.data_smart.ExpansionError: Failure expanding variable
> > > > fetcher_hashes_dummyfunc[vardepvalue], expression was
> > > > ${@bb.fetch.get_hashvalue(d)} which triggered exception
> > > > FetchError: Fetcher failure: Fetch command export
> > > > PSEUDO_DISABLED=1; export
> > > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus"; export
> > > > PATH="build/tmp/sysroots-uninative/x86_64-
> > > > linux/usr/bin:scripts:/var/home/krm/build/poky/build/tmp/work/q
> > > > emux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-
> > > > poky-linux/linux-yocto/6.6.20+git/recipe-
> > > > sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-
> > > > linux/linux-yocto/6.6.20+git/recipe-sysroot-
> > > > native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > yocto/6.6.20+git/recipe-sysroot-
> > > > native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > yocto/6.6.20+git/recipe-sysroot-
> > > > native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-
> > > > yocto/6.6.20+git/recipe-sysroot-
> > > > native/bin:bitbake/bin:build/tmp/hosttools"; export
> > > > HOME="/home/krm"; git -c gc.autoDetach=false -c core.pager=cat
> > > > -c safe.bareRepository=all ls-remote
> > > > https://git.yoctoproject.org/linux-yocto.git  failed with exit
> > > > code 128, output:
> > > > fatal: unable to access
> > > > 'https://git.yoctoproject.org/linux-yocto.git/': error setting
> > > > certificate file: 

[OE-core] OE-core CVE metrics for kirkstone on Sun 10 Mar 2024 03:00:01 AM HST

2024-03-10 Thread Steve Sakoman
Branch: kirkstone

New this week: 0 CVEs

Removed this week: 4 CVEs
CVE-2023-0687 (CVSS3: 9.8 CRITICAL): glibc 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 *
CVE-2023-42467 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42467 *
CVE-2023-50387 (CVSS3: 7.5 HIGH): bind 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-50387 *
CVE-2023-6693 (CVSS3: 5.3 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6693 *

Full list:  Found 44 unpatched CVEs
CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
CVE-2021-35938 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
CVE-2021-35939 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-3515 (CVSS3: 9.8 CRITICAL): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3515 *
CVE-2022-36648 (CVSS3: 10.0 CRITICAL): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36648 *
CVE-2022-3872 (CVSS3: 8.6 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3872 *
CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
CVE-2023-24532 (CVSS3: 5.3 MEDIUM): go 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-24532 *
CVE-2023-27043 (CVSS3: 5.3 MEDIUM): python3:python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-27043 *
CVE-2023-2731 (CVSS3: 5.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2731 *
CVE-2023-28198 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28198 *
CVE-2023-29403 (CVSS3: 7.8 HIGH): go 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-29403 *
CVE-2023-3019 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 *
CVE-2023-3164 (CVSS3: 5.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3164 *
CVE-2023-32370 (CVSS3: 5.3 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-32370 *
CVE-2023-37769 (CVSS3: 6.5 MEDIUM): pixman:pixman-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37769 *
CVE-2023-39323 (CVSS3: 8.1 HIGH): go 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-39323 *
CVE-2023-4001 (CVSS3: 6.8 MEDIUM): grub:grub-efi:grub-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4001 *
CVE-2023-40397 (CVSS3: 9.8 CRITICAL): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40397 *
CVE-2023-44487 (CVSS3: 7.5 HIGH): go:nghttp2 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-44487 *
CVE-2023-45803 (CVSS3: 4.2 MEDIUM): python3-urllib3 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-45803 *
CVE-2023-46407 (CVSS3: 5.5 MEDIUM): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-46407 *
CVE-2023-47100 (CVSS3: 9.8 CRITICAL): perl:perl-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-47100 *
CVE-2023-47470 (CVSS3: 7.8 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-47470 *
CVE-2023-48795 (CVSS3: 5.9 MEDIUM): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-48795 *
CVE-2023-49292 (CVSS3: 4.8 MEDIUM): go 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-49292 *
CVE-2023-51767 (CVSS3: 7.0 HIGH): openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 *
CVE-2023-52355 (CVSS3: 7.5 HIGH): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52355 *
CVE-2023-52356 (CVSS3: 7.5 HIGH): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52356 *
CVE-2023-52425 (CVSS3: 7.5 HIGH): expat:expat-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52425 *
CVE-2023-52426 (CVSS3: 5.5 MEDIUM): expat:expat-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52426 *
CVE-2023-5380 (CVSS3: 4.7 MEDIUM): xwayland 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5380 *
CVE-2023-5574 (CVSS3: 7.0 HIGH): xserver-xorg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-5574 *
CVE-2023-6277 (CVSS3: 6.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6277 *
CVE-2023-6683 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 *
CVE-2023-6816 (CVSS3: 9.8 CRITICAL): xwayland 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6816 *
CVE-2023-7216 (CVSS3: 8.8 HIGH): cpio 

Re: [OE-core] [REGRESSION] linux (git/curl-native) and autorev

2024-03-10 Thread Max Krummenacher
Am Samstag, dem 09.03.2024 um 13:04 -0800 schrieb Bruce Ashfield:
> On Sat, Mar 9, 2024 at 12:58 PM  wrote:
> > 
> > From: Max Krummenacher 
> > 
> > Hello
> > 
> > If one builds a kernel using AUTOREV invoking bitbake only works once.
> > Any subsequent bitbake invocation fails parsing the meta data.
> > 
> > Reproducable with:
> > - latest poky, b5624ee564
> > - Kernel with SRCREV = "AUTOREV", e.g. in local.conf
> >   `SRCREV_machine:pn-linux-yocto:forcevariable = "${AUTOREV}"`
> > - bitbake virtual/kernel; bitbake virtual/kernel
> > 
> > On the second invocation parsing fails when the fetcher tries to
> > evaluate the latest SRCREV:
> > 
> > > ERROR: ExpansionError during parsing 
> > > meta/recipes-kernel/linux/linux-yocto_6.6.bb
> > > Traceback (most recent call last):
> > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1245, in 
> > > srcrev_internal_helper(ud=, 
> > > d=, name='machine'):
> > >  d.setVar("__BBAUTOREV_ACTED_UPON", True)
> > > >srcrev = ud.method.latest_revision(ud, d, name)
> > > 
> > >   File "bitbake/lib/bb/fetch2/__init__.py", line 1667, in 
> > > Git.latest_revision(ud=, 
> > > d=, name='machine'):
> > >  except KeyError:
> > > >revs[key] = rev = self._latest_revision(ud, d, name)
> > >  return rev
> > >   File "bitbake/lib/bb/fetch2/git.py", line 850, in 
> > > Git._latest_revision(ud=, 
> > > d=, name='machine'):
> > > 
> > > >output = self._lsremote(ud, d, "")
> > >  # Tags of the form ^{} may not work, need to fallback to 
> > > other form
> > >   File "bitbake/lib/bb/fetch2/git.py", line 833, in 
> > > Git._lsremote(ud=, 
> > > d=, search=''):
> > >  bb.fetch2.check_network_access(d, cmd, repourl)
> > > >output = runfetchcmd(cmd, d, True)
> > >  if not output:
> > >   File "bitbake/lib/bb/fetch2/__init__.py", line 957, in 
> > > runfetchcmd(cmd='export PSEUDO_DISABLED=1; export 
> > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus"; export 
> > > PATH="build/tmp/sysroots-uninative/x86_64-linux/usr/bin:scripts:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/bin:bitbake/bin:build/tmp/hosttools";
> > >  export HOME="/home/krm"; git -c gc.autoDetach=false -c core.pager=cat -c 
> > > safe.bareRepository=all ls-remote 
> > > https://git.yoctoproject.org/linux-yocto.git ', 
> > > d=, quiet=True, 
> > > cleanup=[], log=None, workdir=None):
> > > 
> > > >raise FetchError(error_message)
> > > 
> > > bb.data_smart.ExpansionError: Failure expanding variable 
> > > fetcher_hashes_dummyfunc[vardepvalue], expression was 
> > > ${@bb.fetch.get_hashvalue(d)} which triggered exception FetchError: 
> > > Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export 
> > > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1003/bus"; export 
> > > PATH="build/tmp/sysroots-uninative/x86_64-linux/usr/bin:scripts:/var/home/krm/build/poky/build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin/x86_64-poky-linux:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot/usr/bin/crossscripts:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/sbin:build/tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/bin:bitbake/bin:build/tmp/hosttools";
> > >  export HOME="/home/krm"; git -c gc.autoDetach=false -c core.pager=cat -c 
> > > safe.bareRepository=all ls-remote 
> > > https://git.yoctoproject.org/linux-yocto.git  failed with exit code 128, 
> > > output:
> > > fatal: unable to access 'https://git.yoctoproject.org/linux-yocto.git/': 
> > > error setting certificate file: 
> > > build/tmp/work/x86_64-linux/curl-native/8.6.0/recipe-sysroot-native/etc/ssl/certs/ca-certificates.crt
> > > 
> > > The variable dependency chain for the failure is: 
> > > fetcher_hashes_dummyfunc[vardepvalue]
> > 
> > Note:
> > One gets out of that parser error by deleting the git binary in the
> > kernel's work recipe-sysroot-native
> > `rm 
> > tmp/work/qemux86_64-poky-linux/linux-yocto/6.6.20+git/recipe-sysroot-native/usr/bin/git`
> > 
> > Bisecting poky leads to commit
> > f7fa98cca8 ("kern-tools: depend on git-replacement-native")
> > Reverting it on top of b5624ee564 makes the parsing 

[OE-core] OE-core CVE metrics for dunfell on Sun 10 Mar 2024 02:00:01 AM HST

2024-03-10 Thread Steve Sakoman
Branch: dunfell

New this week: 0 CVEs

Removed this week: 0 CVEs

Full list:  Found 110 unpatched CVEs
CVE-2020-15705 (CVSS3: 6.4 MEDIUM): grub:grub-efi:grub-efi-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15705 *
CVE-2020-25742 (CVSS3: 3.2 LOW): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25742 *
CVE-2020-25743 (CVSS3: 3.2 LOW): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25743 *
CVE-2020-27918 (CVSS3: 7.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27918 *
CVE-2020-29623 (CVSS3: 3.3 LOW): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29623 *
CVE-2020-35503 (CVSS3: 6.0 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35503 *
CVE-2020-35506 (CVSS3: 6.7 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35506 *
CVE-2020-9948 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9948 *
CVE-2020-9951 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9951 *
CVE-2020-9952 (CVSS3: 7.1 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9952 *
CVE-2021-1765 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1765 *
CVE-2021-1789 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1789 *
CVE-2021-1799 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1799 *
CVE-2021-1801 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1801 *
CVE-2021-1870 (CVSS3: 9.8 CRITICAL): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1870 *
CVE-2021-27097 (CVSS3: 7.8 HIGH): u-boot 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-27097 *
CVE-2021-27138 (CVSS3: 7.8 HIGH): u-boot 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-27138 *
CVE-2021-31879 (CVSS3: 6.1 MEDIUM): wget 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879 *
CVE-2021-3418 (CVSS3: 6.4 MEDIUM): grub:grub-efi:grub-efi-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3418 *
CVE-2021-3445 (CVSS3: 7.5 HIGH): libdnf 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3445 *
CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
CVE-2021-35938 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
CVE-2021-35939 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
CVE-2021-3611 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3611 *
CVE-2021-42762 (CVSS3: 5.3 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-42762 *
CVE-2021-45085 (CVSS3: 6.1 MEDIUM): epiphany 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45085 *
CVE-2021-45086 (CVSS3: 6.1 MEDIUM): epiphany 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45086 *
CVE-2021-45087 (CVSS3: 6.1 MEDIUM): epiphany 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45087 *
CVE-2021-45088 (CVSS3: 6.1 MEDIUM): epiphany 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45088 *
CVE-2021-45481 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45481 *
CVE-2021-45482 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45482 *
CVE-2021-45483 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-45483 *
CVE-2022-0358 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0358 *
CVE-2022-2294 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2294 *
CVE-2022-2347 (CVSS3: 7.1 HIGH): u-boot 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2347 *
CVE-2022-23773 (CVSS3: 7.5 HIGH): go:go-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-23773 *
CVE-2022-24765 (CVSS3: 7.8 HIGH): git 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-24765 *
CVE-2022-2953 (CVSS3: 5.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2953 *
CVE-2022-2962 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2962 *
CVE-2022-30293 (CVSS3: 7.5 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-30293 *
CVE-2022-30767 (CVSS3: 9.8 CRITICAL): u-boot 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-30767 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *

Re: [OE-core] [yocto-security] OE-core CVE metrics for master on Sun 10 Mar 2024 01:00:01 AM HST

2024-03-10 Thread Simone Weiß
On Sun, 2024-03-10 at 04:18 -0700, Steve Sakoman wrote:
> Branch: master
> 
> New this week: 0 CVEs
> 
> Removed this week: 4 CVEs
> 
Hi, again a quick check:
- wiki updated.
- rest all still same status as last week(no fixes available for any, no
direct action item for porting/upgrading)

- Simone
> 
> Full list:  Found 37 unpatched CVEs
> CVE-2019-14899 (CVSS3: 7.4 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 *
> CVE-2021-3714 (CVSS3: 5.9 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
> CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
> CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
> CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
> CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
> CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
> CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
> CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
> CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
> CVE-2023-3397 (CVSS3: 6.3 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3397 *
> CVE-2023-3640 (CVSS3: 7.8 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 *
> CVE-2023-4010 (CVSS3: 4.6 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 *
> CVE-2023-42363 (CVSS3: 5.5 MEDIUM): busybox
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 *
> CVE-2023-42364 (CVSS3: 5.5 MEDIUM): busybox
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 *
> CVE-2023-42365 (CVSS3: 5.5 MEDIUM): busybox
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 *
> CVE-2023-42366 (CVSS3: 5.5 MEDIUM): busybox
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 *
> CVE-2023-51767 (CVSS3: 7.0 HIGH): openssh
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 *
> CVE-2023-6238 (CVSS3: 6.7 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6238 *
> CVE-2023-6240 (CVSS3: 6.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 *
> CVE-2023-6270 (CVSS3: 7.0 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6270 *
> CVE-2023-6356 (CVSS3: 7.5 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 *
> CVE-2023-6535 (CVSS3: 7.5 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 *
> CVE-2023-6536 (CVSS3: 7.5 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 *
> CVE-2023-7042 (CVSS3: 5.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7042 *
> CVE-2023-7216 (CVSS3: 8.8 HIGH): cpio
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 *
> CVE-2024-0841 (CVSS3: 7.8 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0841 *
> CVE-2024-21803 (CVSS3: 7.8 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 *
> CVE-2024-23307 (CVSS3: 7.8 HIGH): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-23307 *
> CVE-2024-23848 (CVSS3: 5.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-23848 *
> CVE-2024-24857 (CVSS3: 6.8 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 *
> CVE-2024-24858 (CVSS3: 5.3 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 *
> CVE-2024-24859 (CVSS3: 4.8 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 *
> CVE-2024-24861 (CVSS3: 6.3 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 *
> CVE-2024-24864 (CVSS3: 4.7 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 *
> CVE-2024-25739 (CVSS3: 5.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 *
> CVE-2024-25740 (CVSS3: 5.5 MEDIUM): linux-yocto
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 *
> 
> Summary of CVE counts by recipe:
>   linux-yocto: 28
>   busybox: 4
>   cpio: 1
>   gnupg:gnupg-native: 1
>   nasm:nasm-native: 1
>   openssh: 1
>   qemu:qemu-native:qemu-system-native: 1
> 
> For further information see:
> https://autobuilder.yocto.io/pub/non-release/patchmetrics/
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all 

[OE-core] OE-core CVE metrics for master on Sun 10 Mar 2024 01:00:01 AM HST

2024-03-10 Thread Steve Sakoman
Branch: master

New this week: 0 CVEs

Removed this week: 4 CVEs
CVE-2023-6683 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6683 *
CVE-2023-6780 (CVSS3: 5.3 MEDIUM): glibc 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6780 *
CVE-2024-0684 (CVSS3: 5.5 MEDIUM): coreutils:coreutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0684 *
CVE-2024-25062 (CVSS3: 7.5 HIGH): libxml2:libxml2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25062 *

Full list:  Found 37 unpatched CVEs
CVE-2019-14899 (CVSS3: 7.4 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 *
CVE-2021-3714 (CVSS3: 5.9 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
CVE-2023-3397 (CVSS3: 6.3 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3397 *
CVE-2023-3640 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 *
CVE-2023-4010 (CVSS3: 4.6 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 *
CVE-2023-42363 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42363 *
CVE-2023-42364 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42364 *
CVE-2023-42365 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42365 *
CVE-2023-42366 (CVSS3: 5.5 MEDIUM): busybox 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-42366 *
CVE-2023-51767 (CVSS3: 7.0 HIGH): openssh 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51767 *
CVE-2023-6238 (CVSS3: 6.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6238 *
CVE-2023-6240 (CVSS3: 6.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6240 *
CVE-2023-6270 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6270 *
CVE-2023-6356 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6356 *
CVE-2023-6535 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6535 *
CVE-2023-6536 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-6536 *
CVE-2023-7042 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7042 *
CVE-2023-7216 (CVSS3: 8.8 HIGH): cpio 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-7216 *
CVE-2024-0841 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-0841 *
CVE-2024-21803 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-21803 *
CVE-2024-23307 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-23307 *
CVE-2024-23848 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-23848 *
CVE-2024-24857 (CVSS3: 6.8 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24857 *
CVE-2024-24858 (CVSS3: 5.3 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24858 *
CVE-2024-24859 (CVSS3: 4.8 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24859 *
CVE-2024-24861 (CVSS3: 6.3 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24861 *
CVE-2024-24864 (CVSS3: 4.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-24864 *
CVE-2024-25739 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25739 *
CVE-2024-25740 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25740 *

Summary of CVE counts by recipe:
  linux-yocto: 28
  busybox: 4
  cpio: 1
  gnupg:gnupg-native: 1
  nasm:nasm-native: 1
  openssh: 1
  qemu:qemu-native:qemu-system-native: 1

For further information see: 

Re: [OE-core] more pedantry: observation on PACKAGES ordering and bash-completion.bbclass

2024-03-10 Thread Robert P. J. Day
On Sat, 9 Mar 2024, Quentin Schulz wrote:

> Hi,
>
> On March 9, 2024 10:38:18 AM GMT+01:00, "Robert P. J. Day" 
>  wrote:
> >
> >  currently perusing countless recipes to choose really good
> >pedagogical examples of "ptest" usage, and i began running across a
> >number of recipes that (unrelated to ptest) included snippets toward
> >the end of their recipe files that added content to FILES:${PN}.
> >here's an example from fwupd:
> >
> >https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-bsp/fwupd/fwupd_1.8.9.bb#L130
> >
> >FILES:${PN} += "${libdir}/fwupd-plugins-* \
> >${libdir}/fwupd-${PV} \
> >${systemd_unitdir} \
> >${datadir}/fish \
> >${datadir}/metainfo \
> >${datadir}/icons \
> >${datadir}/dbus-1 \
> >${datadir}/polkit-1 \
> >${nonarch_libdir}/modules-load.d"
> >
> >  since i knew(?) that the default PACKAGES list is processed left to
> >right, and that the PN package is left until the end to gather what
> >remains, i couldn't understand why so many recipes insisted on adding
>
> "to gather what remains," is not entirely correct. FILES:${PN} is not a 
> grab-all variable, it still only takes files matching the globs inside the 
> variable, which defaults to:
>
> """
> FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* 
> ${libdir}/lib*${SOLIBS} \ ${sysconfdir} ${sharedstatedir} ${localstatedir} \ 
> ${base_bindir}/* ${base_sbindir}/* \ ${base_libdir}/*${SOLIBS} \ 
> ${base_prefix}/lib/udev ${prefix}/lib/udev \ ${base_libdir}/udev 
> ${libdir}/udev \ ${datadir}/${BPN} ${libdir}/${BPN}/* \ ${datadir}/pixmaps 
> ${datadir}/applications \ ${datadir}/idl ${datadir}/omf ${datadir}/sounds \ 
> ${libdir}/bonobo/servers"
> """
>
> And you can see that the paths added to fwupd aren't matched by those default 
> globs, hence why they are added.
>
> >extra content to FILES:${PN} when the default processing would have
> >collected it anyway, unless ... there was something that had been
> >appended to PACKAGES that required that.
> >
> >  sure enough, bash-completion.bbclass:
> >
> >PACKAGES += "${PN}-bash-completion"
> >FILES:${PN}-bash-completion = "${datadir}/bash-completion 
> > ${sysconfdir}/bash_completion.d"
> >
> >  my understanding is that the "proper" ordering of PACKAGES is to
> >start with the most focused and specific packages, define their
> >content, then move on until, at the end, whatever remains goes into
> >PN. which makes that definition of bash-completion.bbclass a bit
> >puzzling -- why was it not *prepended* to the PACKAGES list given its
> >specificity? and making all that subsequent addition to FILES:${PN}
> >unnecessary?
> >
>
> If a file is matched only by one glob, then it doesn't matter much
> in which order the packages are listed, which is very likely the
> case here.
>
> One reason could simply be that += is more natural than =+ and
> seeing that += worked, the contributor didn't think twice about it.
>
> FWIW, one can also do PACKAGE_BEFORE_PN += "${PN}-bash-completion"
> to have bash-completion done right before PN instead of first if
> using =+.
>
> Moving bash-completion package somewhere else in the PACKAGES list
> likely wouldn't change anything of the globs in FILES:${PN} though.

  you're right, i just thought the structure looked awkward.

rday

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