[yocto] [meta-zephyr][master][langdale][PATCH] zephyr-kernel/3.1: update to latest commit

2022-12-19 Thread Naveen Saini
Recent commits have CVE-2022-2741 fixed.

Also backported CVE-2022-2993 fix.

Signed-off-by: Naveen Saini 
---
 ...ix-SMP-local-keys-check-when-startin.patch | 51 +++
 .../zephyr-kernel/zephyr-kernel-src-3.1.0.inc |  3 +-
 2 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 
meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch

diff --git 
a/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch
 
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch
new file mode 100644
index 000..68650c3
--- /dev/null
+++ 
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch
@@ -0,0 +1,51 @@
+From 74d26b70f080a5dc60c6a1aa2bfec38043ee30d4 Mon Sep 17 00:00:00 2001
+From: Joakim Andersson 
+Date: Fri, 5 Aug 2022 10:50:47 +0200
+Subject: [PATCH] Bluetooth: host: Fix SMP local keys check when starting
+ encryption
+
+Fix SMP check of existing local keys when attempting to start security
+with required security mode 1 level 4. The logic for checking the
+conditions was wrong, leading to a situation where encryption would be
+attempted to be started by the central instead of initiating a new
+pairing procedure. This would fail when the connection was encrypted and
+the connection would be disconnected.
+
+Upstream-Status: Backport 
[https://github.com/zephyrproject-rtos/zephyr/commit/83d5402fe830973f943bde085d80f0d3643e811a]
+https://github.com/zephyrproject-rtos/zephyr/pull/52947/files
+CVE: CVE-2022-2993
+
+Signed-off-by: Joakim Andersson 
+Signed-off-by: Naveen Saini 
+---
+ subsys/bluetooth/host/smp.c | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/subsys/bluetooth/host/smp.c b/subsys/bluetooth/host/smp.c
+index 02a847f97d..555f09fefd 100644
+--- a/subsys/bluetooth/host/smp.c
 b/subsys/bluetooth/host/smp.c
+@@ -357,15 +357,15 @@ static bool smp_keys_check(struct bt_conn *conn)
+   return false;
+   }
+ 
+-  if (conn->required_sec_level > BT_SECURITY_L2 &&
++  if (conn->required_sec_level >= BT_SECURITY_L3 &&
+   !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED)) {
+   return false;
+   }
+ 
+-  if (conn->required_sec_level > BT_SECURITY_L3 &&
+-  !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED) &&
+-  !(conn->le.keys->keys & BT_KEYS_LTK_P256) &&
+-  !(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE)) {
++  if (conn->required_sec_level >= BT_SECURITY_L4 &&
++  !((conn->le.keys->flags & BT_KEYS_AUTHENTICATED) &&
++(conn->le.keys->keys & BT_KEYS_LTK_P256) &&
++(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE))) {
+   return false;
+   }
+ 
+-- 
+2.25.1
+
diff --git 
a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc 
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
index 68016e4..b3feb6a 100644
--- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
+++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
@@ -2,7 +2,7 @@
 
 SRCREV_FORMAT = "default"
 
-SRCREV_default = "2ddd73feafd3316af2c547c34d6969bea637d5c6"
+SRCREV_default = "a7d946331f4f9361d1531984524dd8f151ae20b0"
 SRCREV_canopennode = "53d3415c14d60f8f4bfca54bfbc5d5a667d7e724"
 SRCREV_chre = "0edfe2c2ec656afb910cfab8ed59a5ffd59b87c8"
 SRCREV_civetweb = "094aeb41bb93e9199d24d665ee43e9e05d6d7b1c"
@@ -109,6 +109,7 @@ SRC_URI_ZSCILIB ?= 
"git://github.com/zephyrproject-rtos/zscilib;protocol=https"
 SRC_URI_PATCHES ?= "\
 file://0001-3.1-cmake-add-yocto-toolchain.patch;patchdir=zephyr \
 
file://0001-3.1-x86-fix-efi-binary-generation-issue-in-cross-compila.patch;patchdir=zephyr
 \
+
file://0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch;patchdir=zephyr
 \
 "
 
 SRC_URI = "\
-- 
2.25.1


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



Re: [yocto] Issue with accessing network from a recipe

2022-12-19 Thread Gärding Antti via lists . yoctoproject . org
Hi,

Thanks! That helped my team find out a solution or at least a work-around: 
setting do_configure[network] and do_compile[network] to "1" in local.conf.

I would have another related questions, though: Should the commands requiring 
network access work if they are invoked from do_fetch? I tried that and it 
didn't work.


Best regards,
Antti Gärding


Kohteesta: Martin Jansa 
Lähetetty: maanantaina 19. joulukuuta 2022 klo 16.16
Vastaanottaja: Gärding Antti 
Kopio: yocto@lists.yoctoproject.org 
Aihe: Re: [yocto] Issue with accessing network from a recipe

Hi,

that is intentional, recipes should fetch sources with bitbake fetcher (which 
respects MIRROR/PREMIRROR/DL_DIR etc) in do_fetch and network shouldn't be used 
in other tasks (unless explicitly enabled in well explained exceptions).

bitbake can now restrict network access in various tasks based on "network" 
flag as implemented in:
  
https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543
  
https://git.openembedded.org/bitbake/commit/?id=9d6341df611a1725090444f6f8eb0244aed08213
and oe now enables network mostly only in do_fetch and few special tasks as 
implemented in:
  
https://git.openembedded.org/openembedded-core/commit/?id=7ce1e88a3ad85bbb925bb9f7167dc0a5fd1c27f4

Regards,

On Mon, Dec 19, 2022 at 2:02 PM Gärding Antti via 
lists.yoctoproject.org
 
mailto:etteplan@lists.yoctoproject.org>>
 wrote:
Hi,

I am having an issue with a recipe whose do_configure requires network 
connections and I wonder if this issue could be related to Yocto so that this 
list would be the correct place to ask for ideas.

The problem appears when trying to build dotnet-hello-world which comes with 
meta-dotnet 
(https://github.com/jeremy-prater/meta-dotnet).
 I am not the only one having this issue, but many people, including the 
layer's author, also report having no problems. Googling gives a lot of 
suggestions, but as this is related to .NET, all of them are related to Windows 
/ Visual Studio environment and I don't know how to apply them using Yocto.

In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool 
dotnet as a host tool to fetch what is needed to build and run the program. As 
a part of that, it uses NuGet, the package manager for .NET, which says "error 
NU1301: Unable to load the service index for source 
https://api.nuget.org/v3/index.json".

If I modify the recipe so that it tries to c

[yocto] [layerindex-web] [PATCH] layerindex/utils.py: Add to baseconfig=True for bb.parse.handle()

2022-12-19 Thread Robert Yang
Bitbake's api has been changed via:
afb8478d3 parse: Add support for addpylib conf file directive and 
BB_GLOBAL_PYMODULES

The conf file won't be parsed without baseconfig=True:
bb.parse.ParseError: ParseError at /path/to/oe-core/meta/conf/layer.conf:132: 
unparsed line: 'addpylib ${LAYERDIR}/lib oe'

Signed-off-by: Robert Yang 
---
 layerindex/utils.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/layerindex/utils.py b/layerindex/utils.py
index 6566710..9d94015 100644
--- a/layerindex/utils.py
+++ b/layerindex/utils.py
@@ -314,7 +314,10 @@ def is_branch_valid(layerdir, branch):
 def parse_conf(conf_file, d):
 if hasattr(bb.parse, "handle"):
 # Newer BitBake
-data = bb.parse.handle(conf_file, d, include=True)
+if hasattr(bb.parse.parse_py.ConfHandler, "__addpylib_regexp__"):
+data = bb.parse.handle(conf_file, d, include=True, baseconfig=True)
+else:
+data = bb.parse.handle(conf_file, d, include=True)
 else:
 # Older BitBake (1.18 and below)
 data = bb.cooker._parse(conf_file, d)
-- 
2.37.1


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



[yocto] M+ & H bugs with Milestone Movements WW51

2022-12-19 Thread Stephen Jolley
All,

YP M+ or high bugs which moved to a new milestone in WW51 are listed below: 


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  14467

curl timeout while dnf is downloading package

randy.macl...@windriver.com

sakib.sa...@windriver.com

4.2 M1

4.2 M2


 

  14522

qemuppc doesn't shutdown within timeout (serial console issues)

randy.macl...@windriver.com

sakib.sa...@windriver.com

4.2 M1

4.2 M2


 

  14825

AB-INT PTEST: tcl socket.test failure

randy.macl...@windriver.com

ross.bur...@arm.com

4.2 M1

4.2 M2


 

  14920

oe-selftest-armhost qemu x86-64 kernel NULL pointer dereference in 
handle_level_irq/setup_IO_APIC

randy.macl...@windriver.com

bruce.ashfi...@gmail.com

4.2 M1

4.2 M2


 

  14921

devtool failure: No such file or directory: 
'/tmp/devtoolqambdi_6eh/singletask.lock'

randy.macl...@windriver.com

richard.pur...@linuxfoundation.org

4.2 M1

4.2 M2

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


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



[yocto] Enhancements/Bugs closed WW50!

2022-12-19 Thread Stephen Jolley
All,

The below were the owners of enhancements or bugs closed during the last
week!


Who

Count


tim.orl...@konsulko.com

1


Grand Total

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


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



[yocto] Current high bug count owners for Yocto Project 4.2

2022-12-19 Thread Stephen Jolley
All,

Below is the list as of top 31 bug owners as of the end of WW51 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 89
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

35


ross.bur...@arm.com

30


randy.macl...@windriver.com

25


bruce.ashfi...@gmail.com

25


richard.pur...@linuxfoundation.org

23


david.re...@windriver.com

23


sakib.sa...@windriver.com

10


jpewhac...@gmail.com

10


saul.w...@windriver.com

9


zheng@windriver.com

5


pa...@zhukoff.net

5


alexandre.bell...@bootlin.com

4


tim.orl...@konsulko.com

4


sundeep.kokko...@gmail.com

3


hongxu@windriver.com

2


sundeep.kokko...@windriver.com

2


naveen.go...@windriver.com

2


s...@bigsur.com

2


akuster...@gmail.com

2


jon.ma...@arm.com

2


bluelightn...@bluelightning.org

2


anton.anto...@arm.com

1


martin.ja...@gmail.com

1


thomas.per...@bootlin.com

1


qi.c...@windriver.com

1


rybczyn...@gmail.com

1


workjagade...@gmail.com

1


aeh...@gmail.com

1


tvgamb...@gmail.com

1


martin.bee...@online.de

1


mhalst...@linuxfoundation.org

1


Grand Total

235

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


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



[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2022-12-19 Thread Stephen Jolley
All,

 

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

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


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



Re: [yocto] Issue with accessing network from a recipe

2022-12-19 Thread Martin Jansa
Hi,

that is intentional, recipes should fetch sources with bitbake fetcher
(which respects MIRROR/PREMIRROR/DL_DIR etc) in do_fetch and network
shouldn't be used in other tasks (unless explicitly enabled in well
explained exceptions).

bitbake can now restrict network access in various tasks based on "network"
flag as implemented in:

https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543

https://git.openembedded.org/bitbake/commit/?id=9d6341df611a1725090444f6f8eb0244aed08213
and oe now enables network mostly only in do_fetch and few special tasks as
implemented in:

https://git.openembedded.org/openembedded-core/commit/?id=7ce1e88a3ad85bbb925bb9f7167dc0a5fd1c27f4

Regards,

On Mon, Dec 19, 2022 at 2:02 PM Gärding Antti via lists.yoctoproject.org
 wrote:

> Hi,
>
>
>
> I am having an issue with a recipe whose do_configure requires network
> connections and I wonder if this issue could be related to Yocto so that
> this list would be the correct place to ask for ideas.
>
>
>
> The problem appears when trying to build dotnet-hello-world which comes
> with meta-dotnet (https://github.com/jeremy-prater/meta-dotnet). I am not
> the only one having this issue, but many people, including the layer's
> author, also report having no problems. Googling gives a lot of
> suggestions, but as this is related to .NET, all of them are related to
> Windows / Visual Studio environment and I don't know how to apply them
> using Yocto.
>
>
>
> In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool
> dotnet as a host tool to fetch what is needed to build and run the program.
> As a part of that, it uses NuGet, the package manager for .NET, which says
> "error NU1301: Unable to load the service index for source
> https://api.nuget.org/v3/index.json";.
>
>
>
> If I modify the recipe so that it tries to curl that file, I get "Could
> not resolve host: api.nuget.org". If I do the same but use numeric
> address, I get "Couldn't connect to server".
>
>
>
> If I run the commands in the recipe manually in the same environment I use
> for Yocto builds, using .NET SDK I have installed manually, they work.
>
>
>
> My build environment is Ubuntu 20.04 run inside a Docker container.
>
>
>
>
>
> Best regards,
>
> Antti Gärding
>
> 
>
>

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



[yocto] Issue with accessing network from a recipe

2022-12-19 Thread Gärding Antti via lists . yoctoproject . org
Hi,

I am having an issue with a recipe whose do_configure requires network 
connections and I wonder if this issue could be related to Yocto so that this 
list would be the correct place to ask for ideas.

The problem appears when trying to build dotnet-hello-world which comes with 
meta-dotnet (https://github.com/jeremy-prater/meta-dotnet). I am not the only 
one having this issue, but many people, including the layer's author, also 
report having no problems. Googling gives a lot of suggestions, but as this is 
related to .NET, all of them are related to Windows / Visual Studio environment 
and I don't know how to apply them using Yocto.

In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool 
dotnet as a host tool to fetch what is needed to build and run the program. As 
a part of that, it uses NuGet, the package manager for .NET, which says "error 
NU1301: Unable to load the service index for source 
https://api.nuget.org/v3/index.json";.

If I modify the recipe so that it tries to curl that file, I get "Could not 
resolve host: api.nuget.org". If I do the same but use numeric address, I get 
"Couldn't connect to server".

If I run the commands in the recipe manually in the same environment I use for 
Yocto builds, using .NET SDK I have installed manually, they work.

My build environment is Ubuntu 20.04 run inside a Docker container.


Best regards,
Antti Gärding

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