[OE-core] [dunfell][PATCH] bluez5: fix CVE-2023-45866

2023-12-25 Thread Hitendra Prajapati via lists.openembedded.org 
Upstream-Status: Backport from 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=25a471a83e02e1effb15d5a488b3f0085eaeb675

Signed-off-by: Hitendra Prajapati 
---
 meta/recipes-connectivity/bluez5/bluez5.inc   |  1 +
 .../bluez5/bluez5/CVE-2023-45866.patch| 54 +++
 2 files changed, 55 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2023-45866.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index a71d339928..74fd344170 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -59,6 +59,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://CVE-2022-0204.patch \
file://CVE-2022-39176.patch \
file://CVE-2022-3637.patch \
+   file://CVE-2023-45866.patch \
"
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2023-45866.patch 
b/meta/recipes-connectivity/bluez5/bluez5/CVE-2023-45866.patch
new file mode 100644
index 00..43670ab2b3
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2023-45866.patch
@@ -0,0 +1,54 @@
+From 25a471a83e02e1effb15d5a488b3f0085eaeb675 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz 
+Date: Tue, 10 Oct 2023 13:03:12 -0700
+Subject: input.conf: Change default of ClassicBondedOnly
+
+This changes the default of ClassicBondedOnly since defaulting to false
+is not inline with HID specification which mandates the of Security Mode
+4:
+
+BLUETOOTH SPECIFICATION Page 84 of 123
+Human Interface Device (HID) Profile:
+
+5.4.3.4.2 Security Modes
+Bluetooth HID Hosts shall use Security Mode 4 when interoperating with
+Bluetooth HID devices that are compliant to the Bluetooth Core
+Specification v2.1+EDR[6].
+
+Upstream-Status: Backport 
[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=25a471a83e02e1effb15d5a488b3f0085eaeb675]
+CVE: CVE-2023-45866
+Signed-off-by: Hitendra Prajapati 
+---
+ profiles/input/device.c   | 2 +-
+ profiles/input/input.conf | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/profiles/input/device.c b/profiles/input/device.c
+index 375314e..0236488 100644
+--- a/profiles/input/device.c
 b/profiles/input/device.c
+@@ -93,7 +93,7 @@ struct input_device {
+ 
+ static int idle_timeout = 0;
+ static bool uhid_enabled = false;
+-static bool classic_bonded_only = false;
++static bool classic_bonded_only = true;
+ 
+ void input_set_idle_timeout(int timeout)
+ {
+diff --git a/profiles/input/input.conf b/profiles/input/input.conf
+index 4c70bc5..d8645f3 100644
+--- a/profiles/input/input.conf
 b/profiles/input/input.conf
+@@ -17,7 +17,7 @@
+ # platforms may want to make sure that input connections only come from bonded
+ # device connections. Several older mice have been known for not supporting
+ # pairing/encryption.
+-# Defaults to false to maximize device compatibility.
++# Defaults to true for security.
+ #ClassicBondedOnly=true
+ 
+ # LE upgrade security
+-- 
+2.25.1
+
-- 
2.25.1


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

[OE-core][PATCH] devtool/standard: avoid KeyError

2023-12-25 Thread Chen Qi via lists.openembedded.org 
From: Chen Qi 

The initial_revs["."] does not have an initial value, resulting
in the following error:

  KeyError: '.'

The problem could be reproduced by running:

  devtool modify -n systemd 

Signed-off-by: Chen Qi 
---
 scripts/lib/devtool/standard.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 559fd45676..5d9b86ed6a 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -905,6 +905,7 @@ def modify(args, config, basepath, workspace):
 (stdout, _) = bb.process.run('git rev-list --reverse 
devtool-base..HEAD', cwd=submodule_path)
 commits[submodule] = stdout.split()
 else:
+initial_revs["."] = None
 if os.path.exists(os.path.join(srctree, '.git')):
 # Check if it's a tree previously extracted by us. This is done
 # by ensuring that devtool-base and args.branch (devtool) 
exist.
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192906): 
https://lists.openembedded.org/g/openembedded-core/message/192906
Mute This Topic: https://lists.openembedded.org/mt/10330/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-5.0_M1.rc3)

2023-12-25 Thread Jing Hui Tham 
Hi All,
 
QA for yocto-5.0_M1.rc3 is completed. This is the full report for this release: 
 
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
 
=== Summary 
No high milestone defects.
 
No new issue found. 
 
Thanks,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Monday, December 18, 2023 10:43 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-5.0_M1.rc3)
> 
> 
> A build flagged for QA (yocto-5.0_M1.rc3) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-5.0_M1.rc3
> 
> 
> Build URL:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6345
> 
> Build hash information:
> 
> bitbake: 8295ac1b6672c25bee595cff6e000b2af817f904
> meta-agl: 266ac5373b4458d7fcb78b1e8948eb2b33f18b5d
> meta-arm: e6e7ac4d99f103d26a0ffefd6d0a5d2deef5b17c
> meta-aws: 7915e6bafd876ab3d654a26629dbf501479caae0
> meta-intel: 5cfefd9a8ff1f5a3534c1ba9d7d7f6971ed5d56f
> meta-mingw: e01d47d183945caeaf3c5c086539af0a925ddc32
> meta-openembedded: 0a0ea87b8dda01a2887a525cef78eb6c3f4c2c32
> meta-virtualization: caa14c63f158fdd13382ccf1ff4e20a8ba6ad667
> oecore: 6b729088dce302eb3a967cb6839f00488025be0e
> poky: 33112178d164ddd9ef0b1115c254ad4341ec3ad1
> 
> 
> 
> 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 (#192905): 
https://lists.openembedded.org/g/openembedded-core/message/192905
Mute This Topic: https://lists.openembedded.org/mt/103295022/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 0/6] Stepwise rust upgrade 1.71.1 -> 1.74.1

2023-12-25 Thread Richard Purdie 
On Mon, 2023-12-25 at 08:40 +, Richard Purdie via
lists.openembedded.org wrote:
> On Sun, 2023-12-24 at 23:09 +, Alex Kiernan wrote:
> > This is the 1.74.1 rust series rebased to include a revert of
> > https://github.com/rust-lang/cc-rs/commit/c4f414f449bb7cffba3bc923f277704d1d08a8ec
> > which I'm pretty sure is what's causing our filename churn. I've checked
> > 1.72.0 and 1.74.1 for the absvdi2.o intrinsic (one of many intrinsics
> > which had the issue) and in both cases we're not generating the dirname
> > based prefix - hopefully that means that the interim commits are fine
> > too, if not we can do the step back through the commits to find the next
> > issue.
> > 
> > I've dropped the zvariant tests as upgrading it isn't useful (since it
> > no longer includes git crate dependency) and spurious oe-selftest
> > failures aren't helpful. I guess we need to include either something
> > synthetic which tests git crates, or pull in
> > https://github.com/jthornber/thin-provisioning-tools/ from
> > meta-openembedded which includes a live example (though who knows for
> > how long!)
> > 
> > Assuming this does actually fix the reproducibility issue, I'll look at
> > how we fix the issue properly, rather than just reverting the commit
> > which I think is our problem, but I'd like to try and get us back on the
> > rust release train if we can!
> > 
> > 
> > Alex Kiernan (6):
> >   meta-selftest: Drop zvariant recipe
> >   rust: Upgrade 1.71.1 -> 1.72.0
> >   rust: Upgrade 1.72.0 -> 1.72.1
> >   rust: Upgrade 1.72.1 -> 1.73.0
> >   rust: Upgrade 1.73.0 -> 1.74.0
> >   rust: Upgrade 1.74.0 -> 1.74.1
> 
> Sounds like a good plan, I've started a reproducibility test:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4142
> 
> With zvariant, we might be better replacing with a synthetic example
> for testing purposes?

That build went green so I ran an a-full to double check and check
everything else:

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

Curl ptest warning was the only issue (unrelated) so it also looks
good.

Looks like you might have tracked down the issue, nice work! :)

Should I merge this as is or is there something we should do first now
we know where the issue is?

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192904): 
https://lists.openembedded.org/g/openembedded-core/message/192904
Mute This Topic: https://lists.openembedded.org/mt/103354255/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 0/6] Stepwise rust upgrade 1.71.1 -> 1.74.1

2023-12-25 Thread Khem Raj 
On Sun, Dec 24, 2023 at 3:09 PM Alex Kiernan  wrote:

> This is the 1.74.1 rust series rebased to include a revert of
>
> https://github.com/rust-lang/cc-rs/commit/c4f414f449bb7cffba3bc923f277704d1d08a8ec


I think this is definitely the culprit kudos to track it down. I think this
could be improved by generating hash of file content instead of the
pathname to prefix the relative path and we will fix both the issues


> which I'm pretty sure is what's causing our filename churn. I've checked
> 1.72.0 and 1.74.1 for the absvdi2.o intrinsic (one of many intrinsics
> which had the issue) and in both cases we're not generating the dirname
> based prefix - hopefully that means that the interim commits are fine
> too, if not we can do the step back through the commits to find the next
> issue.
>
> I've dropped the zvariant tests as upgrading it isn't useful (since it
> no longer includes git crate dependency) and spurious oe-selftest
> failures aren't helpful. I guess we need to include either something
> synthetic which tests git crates, or pull in
> https://github.com/jthornber/thin-provisioning-tools/ from
> meta-openembedded which includes a live example (though who knows for
> how long!)
>
> Assuming this does actually fix the reproducibility issue, I'll look at
> how we fix the issue properly, rather than just reverting the commit
> which I think is our problem, but I'd like to try and get us back on the
> rust release train if we can!
>
>
> Alex Kiernan (6):
>   meta-selftest: Drop zvariant recipe
>   rust: Upgrade 1.71.1 -> 1.72.0
>   rust: Upgrade 1.72.0 -> 1.72.1
>   rust: Upgrade 1.72.1 -> 1.73.0
>   rust: Upgrade 1.73.0 -> 1.74.0
>   rust: Upgrade 1.74.0 -> 1.74.1
>
>  .../zvariant/zvariant-crates.inc  |  258 
>  .../zvariant/zvariant-git-crates.inc  |   14 -
>  .../0001-Tweak-zvariant-crate-config.patch| 1292 -
>  .../zvariant/zvariant_3.12.0.bb   |   37 -
>  meta/conf/distro/include/tcmode-default.inc   |2 +-
>  meta/lib/oeqa/selftest/cases/devtool.py   |   93 --
>  .../rust/{cargo_1.71.1.bb => cargo_1.74.1.bb} |0
>  ...-Do-not-use-LFS64-on-linux-with-musl.patch |  164 ---
>  ...0001-Don-t-use-LFS64-symbols-on-musl.patch |  163 +++
>  ...e-absolute-paths-to-OUT_DIR-as-relat.patch |   67 +
>  ...Define-SOCK_NONBLOCK-with-O_NONBLOCK.patch |  122 ++
>  ...efine-SOCK_SEQPACKET-in-common-place.patch |  114 --
>  ...ine-F_SETLK-F_SETLKW-and-fix-F_GETLK.patch |   41 +
>  ...GETLK-F_OFD_SETLK-and-F_OFD_SETLKW-t.patch |  205 +++
>  ...-musl-Define-O_LARGEFILE-for-riscv32.patch |   32 +
>  ...efine-SOCK_SEQPACKET-in-common-place.patch |  115 ++
>  .../rust/files/getrandom-open64.patch |   50 -
>  .../rust/files/hardcodepaths.patch|   14 +-
>  .../rust/files/zlib-off64_t.patch |   17 +-
>  ...ibstd-rs_1.71.1.bb => libstd-rs_1.74.1.bb} |0
>  71.1.bb => rust-cross-canadian_1.74.1.bb} |0
>  ...ust-llvm_1.71.1.bb => rust-llvm_1.74.1.bb} |0
>  meta/recipes-devtools/rust/rust-snapshot.inc  |   64 +-
>  meta/recipes-devtools/rust/rust-source.inc|   12 +-
>  .../rust/{rust_1.71.1.bb => rust_1.74.1.bb}   |1 +
>  25 files changed, 802 insertions(+), 2075 deletions(-)
>  delete mode 100644
> meta-selftest/recipes-extended/zvariant/zvariant-crates.inc
>  delete mode 100644
> meta-selftest/recipes-extended/zvariant/zvariant-git-crates.inc
>  delete mode 100644
> meta-selftest/recipes-extended/zvariant/zvariant/0001-Tweak-zvariant-crate-config.patch
>  delete mode 100644 meta-selftest/recipes-extended/zvariant/
> zvariant_3.12.0.bb
>  rename meta/recipes-devtools/rust/{cargo_1.71.1.bb => cargo_1.74.1.bb}
> (100%)
>  delete mode 100644
> meta/recipes-devtools/rust/files/0001-Do-not-use-LFS64-on-linux-with-musl.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0001-Don-t-use-LFS64-symbols-on-musl.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0001-Revert-Map-source-absolute-paths-to-OUT_DIR-as-relat.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0001-musl-Define-SOCK_NONBLOCK-with-O_NONBLOCK.patch
>  delete mode 100644
> meta/recipes-devtools/rust/files/0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0002-musl-riscv32-Define-F_SETLK-F_SETLKW-and-fix-F_GETLK.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0003-musl-Move-F_OFD_GETLK-F_OFD_SETLK-and-F_OFD_SETLKW-t.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0004-musl-Define-O_LARGEFILE-for-riscv32.patch
>  create mode 100644
> meta/recipes-devtools/rust/files/0005-musl-Define-SOCK_SEQPACKET-in-common-place.patch
>  delete mode 100644 meta/recipes-devtools/rust/files/getrandom-open64.patch
>  rename meta/recipes-devtools/rust/{libstd-rs_1.71.1.bb =>
> libstd-rs_1.74.1.bb} (100%)
>  rename

Re: [OE-Core][PATCH 0/6] Stepwise rust upgrade 1.71.1 -> 1.74.1

2023-12-25 Thread Richard Purdie 
On Sun, 2023-12-24 at 23:09 +, Alex Kiernan wrote:
> This is the 1.74.1 rust series rebased to include a revert of
> https://github.com/rust-lang/cc-rs/commit/c4f414f449bb7cffba3bc923f277704d1d08a8ec
> which I'm pretty sure is what's causing our filename churn. I've checked
> 1.72.0 and 1.74.1 for the absvdi2.o intrinsic (one of many intrinsics
> which had the issue) and in both cases we're not generating the dirname
> based prefix - hopefully that means that the interim commits are fine
> too, if not we can do the step back through the commits to find the next
> issue.
> 
> I've dropped the zvariant tests as upgrading it isn't useful (since it
> no longer includes git crate dependency) and spurious oe-selftest
> failures aren't helpful. I guess we need to include either something
> synthetic which tests git crates, or pull in
> https://github.com/jthornber/thin-provisioning-tools/ from
> meta-openembedded which includes a live example (though who knows for
> how long!)
> 
> Assuming this does actually fix the reproducibility issue, I'll look at
> how we fix the issue properly, rather than just reverting the commit
> which I think is our problem, but I'd like to try and get us back on the
> rust release train if we can!
> 
> 
> Alex Kiernan (6):
>   meta-selftest: Drop zvariant recipe
>   rust: Upgrade 1.71.1 -> 1.72.0
>   rust: Upgrade 1.72.0 -> 1.72.1
>   rust: Upgrade 1.72.1 -> 1.73.0
>   rust: Upgrade 1.73.0 -> 1.74.0
>   rust: Upgrade 1.74.0 -> 1.74.1

Sounds like a good plan, I've started a reproducibility test:

https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4142

With zvariant, we might be better replacing with a synthetic example
for testing purposes?

Cheers,

Richard

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