This variable is not referenced in oe-core anymore.
(From OE-Core rev: 15a79302aa46c58f962e12956aa4fcd0a178cf58)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 905b45a814cb33327503b793741c19b44c8550b3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Adds context manager API for the asyncrcp client class which allow
writing code that will automatically close the connection like so:
with hashserv.create_client(address) as client:
...
Rework the bitbake-hashclient tool and PR server to use this new API to
fix warnings about unclosed event loops when exiting
(Bitbake rev: ee090484cc25d760b8c20f18add17b5eff485b40)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d01d684a0f6398270fe35ed59b7d28f3fd9b7e41)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The target_dumper code is basically broken. It has been reading binary files
over the text base serial communication and runs at every command failure which
makes no sense. Each run might overwrite files from the previous run and the
output appears corrupted due to confusion from the binary data.
It isn't possible to cherry-pick "testimage: Drop target_dumper and most of monitor_dumper"
from master, so just make target_dumper, host_dumper, and monitor_dumper empty
functions.
For further details see:
https://lists.openembedded.org/g/openembedded-architecture/message/1888
(From OE-Core rev: 960e7e3dffa22c2142cb672c68cd9a8f0e3998a3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Some distributions shipping gcc12 end up with stringop-overflow warnings
e.g.
/usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ specified size between 9223372036854775813 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
74 | return __glibc_fortify (pread, __nbytes, sizeof (char),
| ^~~~~~~~~~~~~~~
Until fixed, lets not treat this warning as hard error
MJ: this is needed e.g. on ubuntu 24.04 after gcc was upgraded
from 13.2.0-8ubuntu1 to 13.2.0-9ubuntu1 which includes
switch _FORTIFY_SOURCE to 3:
https://changelogs.ubuntu.com/changelogs/pool/main/g/gcc-13/gcc-13_13.2.0-9ubuntu1/changelog
elfutils config.log then shows:
configure:6762: checking whether to add -D_FORTIFY_SOURCE=2 to CFLAGS
configure:6779: gcc -c -D_FORTIFY_SOURCE=2 -isystem/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include -O2 -pipe -Werror -isystem/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include conftest.c >&5
<command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
configure:6786: result: no
and -D_FORTIFY_SOURCE=2 missing in CFLAGS later causes the above error
in do_compile
(From OE-Core rev: 94d1640d374c9a8827957cba8dbc1c1f978701b5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or
host name has shell metacharacters, and this name is referenced by an expansion
token in certain situations. For example, an untrusted Git repository can have a
submodule with shell metacharacters in a user name or host name.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-51385
Upstream patches:
7ef3787c84
(From OE-Core rev: 617640bd045f07b0870dc9f3bc838b3a9fbc3de7)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In ssh-agent in OpenSSH before 9.6, certain destination constraints can be
incompletely applied. When destination constraints are specified during
addition of PKCS#11-hosted private keys, these constraints are only applied
to the first key, even if a PKCS#11 token returns multiple keys.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-51384
Upstream patches:
881d9c6af9
(From OE-Core rev: 7a745dd1aa13fbf110cc4d86ddbc86617975d6ad)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A recipe variable handles its dependencies even on the "contains"
variables within the "inline Python expressions" like bb.utils.filter().
And it also handles those in the append operator correctly, but the
problem is that it does not so in the remove operator.
Fix it by adding the missing dependencies every time the remove
operator has been handled.
Also add a test case to check if the override operators handle
dependencies correctly.
(Bitbake rev: 23639edfbbb3fced7606dce211db8a31c5766585)
Signed-off-by: Insu Park <insu0.park@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cherry-picked from master: b90520eedb1dbc7f6a3928d089fe74fafb864eb5
- Conflicts in data.py are resolved as the master branch moved
handle_contains() and handle_remove() out of the try block.
- The test code in codeparser.py are modified as the master branch
added three more arguments to the build_dependencies().
Signed-off-by: Insu Park <insu0.park@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
wtmp is filled with binary data which the run_serial command can't cope with.
Catting this results in confusion of the serial interface and potentially large
backlogs of data in the buffers which can hang qemu.
Exclude the problematic files from the command.
(From OE-Core rev: 2afd9a6002cba2a23dd62a1805b4be04083c041b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 599ac08a6f6fb3f6a89a897c8e06367c63c2f979)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
[YOCTO #14933]
test_storlines is yet another Python ptest that fails intermittently on
the Yocto AB, so disable it during ptests for now.
(From OE-Core rev: b71d5ec10f8e64fc6102c66dfc36151f2b0b3c86)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit d7b9f8157e6214a83b5495e8a32e11540ae65ff8)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When SRCREV is used, call bb.fetch.get_srcrev() before accessing
SRC_URI. Without this new bb.fetch.get_srcrev() call, SRC_URI might be
accessed before SRCREV had a chance to be processed.
In master, this is fixed by https://git.yoctoproject.org/poky/commit/?id=62afa02d01794376efab75623f42e7e08af08526
However, this commit is not suited for backport since it is quite invasive.
The part of the commit that fix the bug is:
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -63,6 +63,7 @@ python () {
else:
d.setVar('B', '${WORKDIR}/${BPN}-${PV}')
+ bb.fetch.get_hashvalue(d)
local_srcuri = []
fetch = bb.fetch2.Fetch((d.getVar('SRC_URI') or '').split(), d)
for url in fetch.urls:
NB: bb.fetch.get_hashvalue() does not exist in kirkstone but is
equivalent to bb.fetch.get_srcrev().
Fixes [YOCTO #14918]
(From OE-Core rev: f6563cca6c4bf627e904d81fbe5b0b0f2b16a107)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Suggested-by: Chris Wyse <chris.wyse@wysechoice.net>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A malicious HTTP sender can use chunk extensions to cause a receiver
reading from a request or response body to read many more bytes from
the network than are in the body. A malicious HTTP client can further
exploit this to cause a server to automatically read a large amount
of data (up to about 1GiB) when a handler fails to read the entire
body of a request. Chunk extensions are a little-used HTTP feature
which permit including additional metadata in a request or response
body sent using the chunked encoding. The net/http chunked encoding
reader discards this metadata. A sender can exploit this by inserting
a large metadata segment with each byte transferred. The chunk reader
now produces an error if the ratio of real body to encoded bytes grows
too small.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-39326https://security-tracker.debian.org/tracker/CVE-2023-39326
(From OE-Core rev: 448df3bb9277287dd8586987199223b7314fdd01)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Without a CVE tag, It will be recognised as Unpatched by cve_check task.
(From OE-Core rev: afc21d7fe86d26bf62e56fc611750f89fe73aa1a)
Signed-off-by: mark.yang <mark.yang@lge.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Without a CVE tag, It will be recognised as Unpatched by cve_check task.
(From OE-Core rev: ce4ac3d167496d2f3a3029ef83dc418a0794c2fb)
Signed-off-by: mark.yang <mark.yang@lge.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A bug in QEMU could cause a guest I/O operation otherwise
addressed to an arbitrary disk offset to be targeted to
offset 0 instead (potentially overwriting the VM's boot code).
This change is to fix CVE-2023-5088.
Link: 7d7512019f
(From OE-Core rev: aa84c668bfe2436d36f49a422c775119e2412c8b)
Signed-off-by: Sourav Pramanik <sourav.pramanik@kpit.com>
Signed-off-by: Sourav Kumar Pramanik <pramanik.souravkumar@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Align the order from `BB_SIGNATURE_HANDLER` to `SSTATE_MIRRORS` in Quick Build
with the order in the default local conf. While trivial it is easier to find,
if the order matches.
(From yocto-docs rev: 2ab0bdc7ff74aaddd8a556046de3410300ba560a)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Better than using "python unittest" without any
special formatting.
(From yocto-docs rev: 544cc1f950445d2c103c9adfa9147af1513b7a14)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
SRC_URI[md5sum] has been deprecated for a long time. Discourage its use
by removing it from examples and note that it should be replaced by
SRC_URI[sha256sum] when updating recipes.
Also mention that bitbake supports other checksums, though they are not
commonly used.
(From yocto-docs rev: fb5b87cf7322542896c269f404571a655ed6bf91)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
"--subject-prefix" applies to "git format-patch", not "git send-email"
(From yocto-docs rev: cf3697cebc0494a624fa2766d07c3532ec6b4341)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
- nanbield is now released
- update the start and end dates
(From yocto-docs rev: 51f26829e89674c55471a6a077e5f49a97db84c3)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
After the following meta-yocto commits, MIRRORS & PREMIRRORS are no
longer set in the poky distro config file:
67b79df4fbff ("poky.conf: remove redundant MIRRORS")
1b71a3b9418f ("poky: Drop PREMIRRORS entries for scms")
(From yocto-docs rev: c7882126a75e8814764379d40bf56f39da5d3c19)
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Verify that an existing layer path was given when adding a new
layer.
Manually using the shell for globbing is unnecessary, use the glob
function instead for cleaner code.
(Bitbake rev: de1cf0e31f3836a449cbd17490a2f6b6a86b17f9)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The tests don't actually need sudo on core-image-ptest-openssh.
Based on logs seen in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15178 it seems
that socket errors from sudo are creeping into stderr which are failing
the banner ptest from openssh. Removing sudo should help removing
the stderr messages and possibly cure the banner test failures.
(From OE-Core rev: 47e754f483b674b207bfddcc8d4c5d9a3008e102)
(From OE-Core rev: bce20153973ceff3ac9fc98b30e726aa6698d8ee)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This is required by latest webkit when built with x11 support.
(From OE-Core rev: 024edebf6f722ae4d05411be348730d9eeb3bd7c)
(From OE-Core rev: 9fc0f0a15388af175bd53de5190801750064e60c)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Claus Stovgaard <claus.stovgaard@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Bluetooth HID Hosts in BlueZ may permit an unauthenticated Peripheral role
HID Device to initiate and establish an encrypted connection, and accept HID
keyboard reports,potentially permitting injection of HID messages when no user
interaction has occurred in the Central role to authorize such access. An example
affected package is bluez 5.64-0ubuntu1 in Ubuntu 22.04LTS. NOTE: in some cases,
a CVE-2020-0556 mitigation would have already addressed this Bluetooth HID Hosts issue.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45866
Upstream patches:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675
(From OE-Core rev: f03cb448574a730d85ed6d80bb58561674005ede)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Some recipes reference these. Rather than continually trying to chase down the references
and taskhash issues, clear the variables for an easier life and simpler code. These
wouldn't convey anything useful in a native build.
(From OE-Core rev: 09ecafaf0e128c4dea062d359de37cbef461aed2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f8edeead263708889d31a7ff578ef8274cb678b4)
Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
