PR was removed by cc83e4548465 ("bitbake.conf: Drop PE and PR from
WORKDIR and STAMP") on OE-Core.
(From yocto-docs rev: 56db4fd81f6235428bef9e46a61c11ca0ba89733)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit d7a1038ee7c8c463623f0996963f9e8f29d40555)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Use the same sed command to sanitize libtool script for target recipe
and nativesdk one. Otherwise fails with buildpaths QA error:
ERROR: nativesdk-libtool-2.5.0-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/bin/libtool in package nativesdk-libtool contains reference to TMPDIR [buildpaths]
(From OE-Core rev: f08df9adf290fb6cbebff24df6bbbbe8e5ce95e0)
Upstream-Status: Backport[https://git.yoctoproject.org/poky/commit/?id=89e184da6c9d95a99fd34334df5ac6c5ae87f13a]
(From OE-Core rev: a720df7ad77af1f8b1c00a211c88537e5f23edbc)
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 89e184da6c)
Signed-off-by: Nikhil R <nikhilr5@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since target and cross variants were already doing similar cleanup
of include-fixed headers, as those aren't used, unify the code and
also apply the same to cross-canadian variant.
Some of those header files get processed with a tool that leaves
absolute buildpaths inside the file's commented section, causing
QA errors. Since those aren't used, let's remove them.
This may be a temporary solution until the tool itself gets fixed
to not embed absolute buildpaths in the header files:
https://lists.openembedded.org/g/openembedded-core/topic/107268307
(From OE-Core rev: 621e0ac9308cc163fb767a27d63fff6570896b92)
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
On big-endian systems the preprocessor define ICU_DATA_DIR
is currently being set to a path ending with the ${PV} of
the recipe.
The PV version string has changed to a '-' separator
since oe-core commit cebe8439cdc656d53355506a31a3782312bf03c5
whereas the build system installs the data files into a
path ending with the dot-separated version of ICU.
This causes the ICU data file to not be detected at runtime,
consequently breaking any dependant applications.
We therefore substitute ${PV} with the dot-separated version
string of ICU, as returned from the icu_install_folder function,
on the ICU_DATA_DIR define on big-endian targets.
(From OE-Core rev: 345ebe7046eab4a0588aa33c595f48cfe90f899e)
Signed-off-by: Makarios Christakis <makchrbiz@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 28cdc0110def011e3d690da1d591076385267ef7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
These are tracked as versionless redhat CVEs in NVD DB.
(From OE-Core rev: 84b1631bcbead1409ff44a1ed430244784c382be)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This patch is causing build failures where pthread.h does not exist:
sed: can't read
No such file or directory
This reverts commit d3c294ee0afe4d2eb46320945d41064ebfb5cbff.
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Replace the hardcoded path with /not/exist as used for other
options[--with-sysroot] to ensure pthread.h does not contain
hardocded references to TMPDIR:
ERROR: gcc-cross-canadian-x86-64-13.3.0-r0 do_package_qa: QA Issue:
File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/
usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/13.3.0/include-fixed/
pthread.h in package gcc-cross-canadian-x86-64 contains reference to
TMPDIR [buildpaths]
(From OE-Core rev: d3c294ee0afe4d2eb46320945d41064ebfb5cbff)
Signed-off-by: Sana Kazi <sanakazi720@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Apply fixes from gcc-cross (84a78f46d594 and 0ead8cbdfb96) to gcc-cross-canadian.
This will improve (but not fix) reproducibility of gcc-cross-canadian.
Also move this code to functions to avoid code duplication.
[RP: Tweak patch to make the function parameters clear and fix quoting issues
ensuring the code exactly matches the original replacements with an additional
parameter.]
(From OE-Core rev: 350ff7d53f7506de2bc01f0efc569b8294b9afea)
(From OE-Core rev: b1aa13b9f656666458189d4dae0c25564abe2f25)
Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f1ad5be433)
Signed-off-by: Sana Kazi <sanakazi720@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Changelog:
==========
1.32.10
- scripts/tag_lyrics.py: fix for python3
- libout123: Use strtok_r() to avoid conflicts multithreaded contexts
- libmpg123: Un-break DLL builds that need I/O functions defined in libmpg123.c
- ports/cmake: More fixup to also produce .pc files with Libs.private.
1.32.9
- libmpg123:
-- enable 64 bit offset path for MSVCRT and avoid warnings about
MS's game about POSIX API with and without underscores
-- Increase the library patchlevel, as was forgotten on previous
release.
1.32.8
Update: The buffer overflow got assigned the CVE ID CVE-2024-10573.
- libmpg123:
-- Add sections to assembly to support PAC/BTI code
for aarch64 (-mbranch-protection variants)
-- Prevent premature application of header info into decoding structure,
at worst having triggered out-of-bounds writes of decoded PCM data
- out123: Show --quiet in --longhelp.
1.32.7
- ports/cmake: Work around bug in CMake that does not detect FPU on Apple ARM CPUs.
- Fix some laziness (func() to func(void)) for standards conformance.
(From OE-Core rev: a3db638932e76ac0972d7905072cc7ab3f2abb75)
Signed-off-by: Zhang Peng <peng.zhang1.cn@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Pick commit referencing this MR which was merged to master.
(From OE-Core rev: a4ff82c789d50a3f411170636679ce46c8f84b25)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This allows anyone using the SDK to be able to analyze the logs
collected on target
(From OE-Core rev: b00b0d744a1768843386cfd529b73cc17c88bec9)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This allows anyone using the SDK to be able to analyze the logs
collected on target
(From OE-Core rev: b422b4d3c04fb04fddb22da82aa91c39f1b54b2a)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
For reasons we have explicit xorg.conf files for a number of the qemu
machines, but not all of them. These mainly disabled screen blanking
(which is now down with a separate fragment) but also explictly set the
device driver to fbdev which meant they didn't use the modesettings
driver as they should (with the virtio framebuffer from qemu).
This is the root cause of why the xserver 21.1.16 upgrade doesn't work
on a number of machines: the /sys probing changed and the fbdev driver
now refuses to use the PCI framebuffer device as there are better
drivers, but we've explictly told xorg to use the wrong driver.
For more details, see https://gitlab.freedesktop.org/xorg/xserver/-/issues/1798.
(From OE-Core rev: ccbb0f5491e13d61015872fba93417b91c3213a2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8c8039bf4c2d011e3d12c970ce45036b184902a9)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add a configuration fragment that disables screen blanking, and add it
to all qemu machines.
(From OE-Core rev: bb16526a4a0c39b6c156edbf68c7377bfdfa0bd1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 780a5ccaa51d5aed18200883a686387e70847e4b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning these CVEs.
(From OE-Core rev: d96bf8ec82ed07c006167e15f7aa0d5e81440977)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning these CVEs.
(From OE-Core rev: f25e1296b8265414061b0b8f12110c6ee22bc7be)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning these CVEs.
(From OE-Core rev: eb9811ef2a38f1dcd4074eef6f809fd63e98454f)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 77abb78b5d4dd0e54b656170c03ac68b919b8784)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: d9fb00f71380ad39ea5b61e60c4f458371460862)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 2ec4bcda16b92cabf7cf5cb7c68cbe45da269364)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: e1e13086f38b021a8aabfe8d044b5755d62ee846)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: d9d99bd5baddcb0438e0c28ab6e302ee9fa0c327)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 4e01993bf71d3b8e2375ab43857b671738953507)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: f24f2dc0b7504508357cbe5d5f7a577639a6548e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 0c860bf1765b49a7540ae3cb206ce09cf25f30a7)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 70a15bc790025e3241274d3e92674928c41537b6)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: f3a14813ed012904e64fd9897ea4ddaf622059dd)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning these CVEs.
(From OE-Core rev: 61268080ba160a4965873ba5aad6ebbfd1ee2fe1)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Cherry-pick patch mentioning this CVE.
(From OE-Core rev: 120d8cc7b91654557a3101a5f8fda44fb703e5b2)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
It is used to fix multiple CVEs.
(From OE-Core rev: c12baf254a37ff4921c2be0e4d3f626a91980d1a)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2021-46705 was needed only with 2.06
CVE-2023-4692 and CVE-2023-4693 were fixed in NVD DB meanwhile
(From OE-Core rev: fab492f32a8630a353d307119dd4109dac81ad45)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
According to Yocto reference manual, in description of the
IMAGE_LINK_NAME variable, it is said that
It is possible to set this to "" to disable symlink creation,
however, you also need to set :term:`IMAGE_NAME` to still have
a reasonable value e.g.::
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
However, when using following additions in local.conf file:
INHERIT += "cve-check"
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
the implicit symlink creation in cve_check_write_rootfs_manifest leads
to following build failure
$ bitbake core-image-minimal core-image-base
...
ERROR: core-image-base-1.0-r0 do_image_complete: Recipe core-image-base is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
/home/poky/build/tmp/deploy/images/qemux86-64/.json
(matched in manifest-qemux86_64-core-image-minimal.image_complete)
Please adjust the recipes so only one recipe provides a given file.
Mitigate the issue by creating the symlink only in case IMAGE_LINK_NAME
has not been set to empty string.
(From OE-Core rev: 64bfec359bd909761ce0a6a716286d938ed162d1)
(From OE-Core rev: 35e210e3ebe21f1f4466760076b7140618af536e)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
As we just match on product by default, ignore three CVEs which are
for the "Puzzles" WordPress theme by ThemeREX (CPE themerex:puzzles).
(From OE-Core rev: 87326573c82ac1e8dc335319442236ef2341501e)
(From OE-Core rev: 9543945bb935e9a3e2bfbf731412188fc52ad2c9)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled.
A machine-in-the-middle attack can be performed by a malicious machine impersonating
a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific
conditions when verifying the host key. For an attack to be considered successful,
the attacker needs to manage to exhaust the client's memory resource first, turning
the attack complexity high.
(From OE-Core rev: 60b5df194a5bea491489fdae2f32e33ffd21c9c7)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We've been seeing intermittent failures on Ubuntu 22.04 in oe-selftest which
were problematic to debug. The failure was inside lock_timeout and once that was
identified and the backtrace obtained, the problem becomes clearer:
File "X/bitbake/lib/bb/server/process.py", line 466, in idle_thread_internal
retval = function(self, data, False)
File "X/bitbake/lib/bb/command.py", line 123, in runAsyncCommand
self.cooker.updateCache()
File "X/bitbake/lib/bb/cooker.py", line 1629, in updateCache
self.parser = CookerParser(self, mcfilelist, total_masked)
File "X/bitbake/lib/bb/cooker.py", line 2141, in __init__
self.bb_caches = bb.cache.MulticonfigCache(self.cfgbuilder, self.cfghash, cooker.caches_array)
File "X/bitbake/lib/bb/cache.py", line 772, in __init__
loaded += c.prepare_cache(progress)
File "X/bitbake/lib/bb/cache.py", line 435, in prepare_cache
loaded = self.load_cachefile(progress)
File "X/bitbake/lib/bb/cache.py", line 516, in load_cachefile
progress(cachefile.tell() + previous_progress)
File "X/bitbake/lib/bb/cache.py", line 751, in progress
bb.event.fire(bb.event.CacheLoadProgress(current_progress, cachesize),
File "X/bitbake/lib/bb/event.py", line 234, in fire
fire_ui_handlers(event, d)
File "X/bitbake/lib/bb/event.py", line 210, in fire_ui_handlers
_ui_handlers[h].event.send(event)
File "X/bitbake/lib/bb/cooker.py", line 117, in send
str_event = codecs.encode(pickle.dumps(event), \'base64\').decode(\'utf-8\')
File "/usr/lib/python3.10/asyncio/sslproto.py", line 320, in __del__
_warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
File "/usr/lib/python3.10/warnings.py", line 109, in _showwarnmsg
sw(msg.message, msg.category, msg.filename, msg.lineno,
File "X/bitbake/lib/bb/main.py", line 113, in _showwarning
warnlog.warning(s)
File "/usr/lib/python3.10/logging/__init__.py", line 1489, in warning
self._log(WARNING, msg, args, **kwargs)
File "/usr/lib/python3.10/logging/__init__.py", line 1624, in _log
self.handle(record)
File "/usr/lib/python3.10/logging/__init__.py", line 1634, in handle
self.callHandlers(record)
File "/usr/lib/python3.10/logging/__init__.py", line 1696, in callHandlers
hdlr.handle(record)
File "/usr/lib/python3.10/logging/__init__.py", line 968, in handle
self.emit(record)
File "X/bitbake/lib/bb/event.py", line 778, in emit
fire(record, None)
File "X/bitbake/lib/bb/event.py", line 234, in fire
fire_ui_handlers(event, d)
File "X/bitbake/lib/bb/event.py", line 197, in fire_ui_handlers
with bb.utils.lock_timeout(_thread_lock):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "X/bitbake/lib/bb/utils.py", line 1888, in lock_timeout
bb.server.process.serverlog("Couldn\'t get the lock for 5 mins, timed out, exiting. %s" % traceback.format_stack())
or put in simpler terms, whilst sending an event(), an unrelated warning
message happens to be triggered from asyncio:
/usr/lib/python3.10/asyncio/sslproto.py:320: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7f0e797d3100>
which triggers a second event() which can't be sent as we're already
in the critcal section and already hold the lock.
That warning is due to the version of asyncio used on Ubuntu 22.04 with
python 3.10 and that comined with timing issues explains why we don't
see it on other python versions or distros.
We can't handle the second event as the lock is there to serialise the
events. Instead, we queue the event and then process the queue later.
Add a new version of lock_timeout which allows us to handle the situation
more gracefully.
(Bitbake rev: 696c2c1ef095f8b11c7d2eff36fae50f58c62e5e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2c590ff1aff89d23b25ce808650f200013a1e6af)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We never want to exit whilst holding these locks as it deadlocks all python
threads. Add signal blocking around the lock critical part so a signal
shouldn't cause such an exit.
(Bitbake rev: 5cc1dde1ffd9382b3a9e4cc182be067defba16a7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a097755c671e2b530dea6200a94b39fa9dca246c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We should really try and take the lock in the try/finally block so that
in some rare cases such as badly timed interrupt/signal, we always release
the lock.
(Bitbake rev: 5dbbca616a71047fc3573a2be49846d5c9cdd15a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a9eb8bf7174b6962b5ba07192fe95b8c7112d9d2)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Bruce Ashfield
Vijay Anusuri
Divya Chellam
Madhu Marri
Antonin Godard
Denys Dmytriyenko
Makarios Christakis
Peter Marko
Steve Sakoman
Sana Kazi
Oleksandr Hnatiuk
Zhang Peng
Changqing Li
Ross Burton
Wang Mingyu
Niko Mauno
Ashish Sharma
Archana Polampalli
Richard Purdie