Sphinx complains about hardcoded links which can be replaced by an
extlink.
So let's apply its recommendations.
(From yocto-docs rev: f550001f32157c7c30cf5506f3da783c0fd96396)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
uninative works via hashes and doesn't need the version in the tarball name but
it does make things easier to inspect in DL_DIR. There were reasons such as
ease of publication of the build tarballs but we can handle those differently
now and the signature issues from the early code aren't an issue now. From 3.4
onwards we can use a version'd name.
[YOCTO #12970]
(From OE-Core rev: 0ec0e49d0d2a7478efbf20bc3554f0ffba40afa0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dadba70d6a24d8ebb5576598efffa973151c7218)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the BUILDHISTORY_RESET is enabled we need to move the
content from BUILDHISTORY_DIR to BUILDHISTORY_OLD_DIR but
when we start a clean build in the first run we don't have the
BUILDHISTORY_DIR so the move of files will fail.
| ERROR: Command execution failed: Traceback (most recent call last):
| File "/xxx/poky/bitbake/lib/bb/command.py", line 110, in runAsyncCommand
| commandmethod(self.cmds_async, self, options)
| File "/xxx/poky/bitbake/lib/bb/command.py", line 564, in buildTargets
| command.cooker.buildTargets(pkgs_to_build, task)
| File "/xxx/poky/bitbake/lib/bb/cooker.py", line 1481, in buildTargets
| bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.databuilder.mcdata[mc])
| File "/xxx/home/builder/src/base/poky/bitbake/lib/bb/event.py", line 214, in fire
| fire_class_handlers(event, d)
| File "/xxx/poky/bitbake/lib/bb/event.py", line 121, in fire_class_handlers
| execute_handler(name, handler, event, d)
| File "/xxx/poky/bitbake/lib/bb/event.py", line 93, in execute_handler
| ret = handler(event)
| File "/xxx/poky/meta/classes/buildhistory.bbclass", line 919, in buildhistory_eventhandler
| entries = [ x for x in os.listdir(rootdir) if not x.startswith('.') ]
| FileNotFoundError: [Errno 2] No such file or directory: '/xxx/buildhistory'
(From OE-Core rev: de89dc125758f828a7886012bd9b1c8a1017ef48)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 97bc2168da7dbacdfbf79cd70db674363ab84f6b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running the ptest package in an image alone highlighted missing module
dependencies. Add them to fix those errors.
(From OE-Core rev: 6e98fdf7832fed3d93645ed69f62c8df5e89b96b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3859f49db2d694c7b63fdbe25be0018afba5c738)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The linux kernel will by default use pkg-config to get ncurses(w) paths,
falling back to absolute path checks otherwise. If the build host does
not have ncurses installed this will fail as pkg-config will not search
the native sysroot for ncurses.
To more all kernel/kconfig sources, inject the equivalent native
pkg-config variables similar to what is done by the pkg-config-native
script. This only affects the menuconfig python task itself and the
oe_terminal call inside it.
(cherry picked from commit abb95c421bb67d452691819e3f63dabd02e2ba37)
(From OE-Core rev: dc6b20475a69c9fbab9a97a93119aeedf54deb23)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this dependency, generating the bootchart may fail with:
"
ModuleNotFoundError: No module named 'random'
"
(cherry picked from commit 487e9f16a00f895159b79f1865fe8b626b47ddc2)
(From OE-Core rev: 123d4a673dadfee14d5ad8bbc503405da9602bb0)
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Mingli Yu <mingli.yu@windriver.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that all of the functions in cve-check open the database read-only,
we can remove this lockfile.
This means cve-check can run in parallal again, improving runtimes
massively.
This reverts commit d55fbf4779.
(From OE-Core rev: 1a30a8513ca47890470ee9d19a5ea36437e664bf)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e60d149b41d14d177df20dbecaef943696df1586)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All of the function in cve-check should open the database read-only, as
the only writer is the fetch task in cve-update-db. However,
get_cve_info() was failing to do this, which might be causing locking
issues with sqlite.
(From OE-Core rev: 2b3d13a451e99db669977d4d1172653b736ae6e1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8de517238f1f418d9af1ce312d99de04ce2e26fc)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Three CVEs were meant to be ignored via CVE_WHITELIST, but that wasn't
the correct variable name.
The CPEs for those CVEs mean that they don't get picked up in our report,
so just remove the assignment.
(From OE-Core rev: c50688e1d0839d71e05a0d15dd948113d2ef83f6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dea00faf30ec7c19b6b5ed4651b430ba3faf69ff)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Expat (aka libexpat) before 2.4.5, there is an integer overflow
in storeRawNames.
Backport patch from:
eb0362808b
CVE: CVE-2022-25315
(From OE-Core rev: 9cb21fd89de99abeeef1dd962e6019943de546a4)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Expat (aka libexpat) before 2.4.5, there is an integer overflow in
copyString.
Backport patch from:
efcb347440
CVE: CVE-2022-25314
(From OE-Core rev: b92c33285c5f886c95a3734e61007b522b62a71f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack
exhaustion in build_model via a large nesting depth in the DTD element.
Backport patch from:
9b4ce651b2
Also add patch which fixes a regression introduced in the above fix:
https://github.com/libexpat/libexpat/pull/566
CVE: CVE-2022-25313
(From OE-Core rev: 8105700b1d6d23c87332f453bdc7379999bb4b03)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain
validation of encoding, such as checks for whether a UTF-8 character
is valid in a certain context.
Backport patches from:
https://github.com/libexpat/libexpat/pull/562/commits
CVE: CVE-2022-25235
(From OE-Core rev: 27ab07b1e8caa5c85526eee4a7a3ad0d73326866)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
math/big: prevent large memory consumption in Rat.SetString
An attacker can cause unbounded memory growth in a program using (*Rat).SetString
due to an unhandled overflow.
Upstream-Status: Backport [https://go.dev/issue/50699]
CVE: CVE-2022-23772
(From OE-Core rev: e4d15040f62744265b9236ad7276f3371a9172da)
Signed-off-by:Minjae Kim <flowergom@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
crypto/elliptic: fix IsOnCurve for big.Int values that are not valid coordinates
Some big.Int values that are not valid field elements (negative or overflowing)
might cause Curve.IsOnCurve to incorrectly return true. Operating on those values
may cause a panic or an invalid curve operation. Note that Unmarshal will never
return such values.
Upstream-Status: Backport [https://go.dev/issue/50974]
CVE: CVE-2022-23806
(From OE-Core rev: eb7aa0929ecd712aeeec0ff37dfb77c3da33b375)
Signed-off-by:Minjae Kim <flowergom@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
