Add a script to manage the .hash files in the BR2_GLOBAL_PATCH_DIR for
packages using custom versions.
To use it, run in a configured Buildroot directory, E.G.
make foo_defconfig; ./utils/add-custom-hashes
We support multiple patch directories in BR2_GLOBAL_PATCH_DIR. If multiple
directories are specified then use the last one as that is likely to be the
most specific one.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: silence command -v invocation]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 4984d0f230)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
By default dhcpcd installed with 555 permissions as it is
configured in its Makefile.inc. Since 'w' bit is missing,
strip fails and dhcpcd binary installed non-stripped.
On ARM GCC 12 glibc configuration strip saves over 1MB of disk space.
Signed-off-by: Oleg Lyovin <ovlevin@salutedevices.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 72c3f87efa)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also, bump package/opencv4-contrib to in lock-step.
This addresses both CVE-2023-2617 and CVE-2023-2618, that have been
fixed in OpenCV 4.8.0.
Signed-off-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a01490397e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following (Windows only) security issues:
CVE-2023-45283: path/filepath: recognize \??\ as a Root Local Device path prefix.
CVE-2023-45284: path/filepath: recognize device names with trailing spaces and superscripts
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This upstream patch restores the connectivity check functionality with
libcurl 8.4.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=15835
Signed-off-by: Christian Hitz <christian.hitz@bbv.ch>
Reviewed-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit b660402b57)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Node modules available on the npm registry, may contain prebuild
binaries for various targets and/or ABIs; for example., there might be
ARM. AArch64, x86_64 binaries for glibc or musl, for Linux or Darwin.
Needless to say, those binaries will most often not match the current
target architecture; as such, check-bin-arch will whine loudly as
reported in #15823:
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node" is "ARM", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node" is "ARM", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node" is "ARM", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node" is "Advanced Micro Devices X86-64", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node" is "Advanced Micro Devices X86-64", should be "AArch64"
The proper solution would be to remove all those prebuilt binaries, and
request npm to forcefully rebuild the proper binary for the current
architecture; alas, there is no option to tell npm to do so.
Doing it manually would not be easy either, as such modules might be
retrieved as part of the "vendoring" for another module that the user
has requested, and be pretty deep in the dependency chain; trying to fix
this properly would be a nightmare: it would require that we manually
inspect the depednency chain, and install dependent modules one by one,
recursively, re-implementing the same logic npm has when multiple
verions of the same module are installed as part of different branches
of the depenency tree, all while detecting prebuilds and removing them
before installing the mpdule (hence decorrelating download and install,
which is not trivial to do with npm alone).
We also can't simply remove all the prebuilds, because it is not known
whether the location ("<module>/prebuilds/") is standardised, or a
convention with the path noted somewhere in the package metadata, and
how deep they would be in the tree, and whether that could conflict with
arbitrary files...
Instead, we will consider that npm has a sane heuristic to detect
whether it should indeed rebuilt the modules, and that node has a sane
heuristic to know which binary to load at runtime, and we will leave the
prebuilt binaries in place and just exclude them from being checked.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=15823
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cbc5691ab2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, when a package is downloaded from a custom location or
version, Buildroot excludes such a package from the mandatory integrity
check with hashes, because it was until now not possible to have such
hashes.
We now have a mechanism which users can leverage to provide additional
hashes, and so custom versions or locations can now be checked too.
Buildroot has no way to know that hashes have indeed been provided for
a custom location/version, and so will still happily ignore an
unchecked package.
However, users who do provide extra hashes most probably do expect that
no download is done without an integrity check, and thus expect that a
missing hash not be ignored.
Add an option that users can select to make Buildroot forcibly require
at least one valid hash, and no invalid hash, for all downloads.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e091e31831)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5d36710e36)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
So, we need our download helpers to be able to accept more than one hash
file to lookup for hashes.
Extend the dl-wrapper and the check-hash helpers thusly, and update the
legal-info accordingly.
Note that, to be able to pass more than one hash file, we also need to
re-order the arguments passed to support/download/check-hash, which also
impies some shuffling in the three places it is called:
- 2 in dl-wrapper
- 1 in the legal-info infra
That in turn also requires that the legal-license-file macro args get
re-ordered to have the hash file last; we take the opportunity to also
move the HOST/TARGET arg to be first, like in the other legal-info
macros.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f91e89b6e6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit f20589cbc7 (configs/stm32mp157c_odyssey: new defconfig) forgot to
specify a fixed TF-A version, so do that now.
When the defconfig was added, the default version was v2.5 - So use that.
Similarly to the other stm32mp1 defconfigs, this needs disabling -Werror
with E=0 to fix a build issue with GCC >= 12.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 69ac9fdbc4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With the move to default to GCC 12 in commit e0091e42ee (package/gcc:
switch to gcc 12.x as the default), TF-A now fails to build as a warning is
generated and it builds with -Werror:
CC plat/st/stm32mp1/bl2_plat_setup.c
drivers/st/io/io_stm32image.c: In function ‘stm32image_partition_read’:
drivers/st/io/io_stm32image.c:249:13: error: ‘result’ may be used uninitialized [-Werror=maybe-uninitialized]
249 | int result;
| ^~~~~~
cc1: all warnings being treated as errors
This is fixed in TF-A v2.6 with commit c1d732d0db24 (fix(io_stm32image):
uninitialized variable warning), but I do not have the board to verify if
v2.6 works, so instead disable -Werror by passsing E=0.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1c0c67fc1a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With the move to default to GCC 12 in commit e0091e42ee (package/gcc:
switch to gcc 12.x as the default), TF-A now fails to build as a warning is
generated and it builds with -Werror:
CC plat/st/stm32mp1/bl2_plat_setup.c
drivers/st/io/io_stm32image.c: In function ‘stm32image_partition_read’:
drivers/st/io/io_stm32image.c:249:13: error: ‘result’ may be used uninitialized [-Werror=maybe-uninitialized]
249 | int result;
| ^~~~~~
cc1: all warnings being treated as errors
This is fixed in TF-A v2.6 with commit c1d732d0db24 (fix(io_stm32image):
uninitialized variable warning), but I do not have the board to verify if
v2.6 works, so instead disable -Werror by passsing E=0.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5c40f41b2e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since bump to version 3.2.3 in
commit 4155139365:
In file included from /home/thomas/autobuild/instance-1/output-1/host/include/python3.11/Python.h:38,
from src/modules/rlm_python3/rlm_python3.c:37:
/home/thomas/autobuild/instance-1/output-1/host/include/python3.11/pyport.h:596:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
596 | #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
| ^~~~~
Fixes:
- http://autobuild.buildroot.org/results/36143ab06b66a047aa2247ea66b1df0d6c1cbd66
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit fdae1d231c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
python handling is wrong since the addition of the package in commit
736c4c1655 so disable python(2) and enable
python3 if needed
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4513f5198a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cpe:2.3🅰️kvmtool_project:kvmtool is a valid CPE identifier for this
package:
https://nvd.nist.gov/products/cpe/detail/9B4C8068-B4EB-487F-958A-353BD3F494D1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 718a800828)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
timeout = 35 * self.emulator.timeout_multiplier
[...]
self.assertRunOk(cmd, timeout=timeout)
Gets re-multiplied by self.emulator.timeout_multiplier in self.emulator.run().
Drop multiplying the timeout by self.emulator.timeout_multiplier to fix this
issue.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9a81c7a7a4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
self.emulator.timeout_multiplier *= 10 is equivilent to 60 * 10 or 600.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4889ac89b8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
self.emulator.timeout_multiplier *= 10 is equivilent to 60 * 10 or 600.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c9316f21c7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
to override the current value of 60 seconds
As per a suggestion by Thomas, add a timeout argument to override the current
value of 60 seconds for the emulator.login method.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b1d554b9a7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 89f5e98932 (support/download/svn: generate reproducible
svn archives), we've been able to generate reproducible archives, and
thus we have been able to verify the hashes for those archives.
However, the manual was not changed, and still falsely hinted that this
was not the cae.
Fix that.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6898781f03)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cpe:2.3🅰️buc:traceroute is a valid CPE identifier for this package:
https://nvd.nist.gov/products/cpe/detail/399C82DE-9AC7-4C48-8E9B-57C480E95FF5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 707c2c70bc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Switch to using HTTPS for downloading libzlib from zlib.net.
(zlib.net doesn't default to HTTPS but does suggest HTTPS in the permalink
for the latest zlib release. Also works better with some corporate firewalls
that get suspicious about zlib for some reason.)
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5b139e2a8d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-24805: cups-filters contains backends, filters, and other
software required to get the cups printing service working on operating
systems other than macos. If you use the Backend Error Handler (beh) to
create an accessible network printer, this security vulnerability can
cause remote code execution. `beh.c` contains the line `retval =
system(cmdline) >> 8;` which calls the `system` command with the operand
`cmdline`. `cmdline` contains multiple user controlled, unsanitized
values. As a result an attacker with network access to the hosted print
server can exploit this vulnerability to inject system commands which
are executed in the context of the running server. This issue has been
addressed in commit `8f2740357` and is expected to be bundled in the
next release. Users are advised to upgrade when possible and to restrict
access to network printers in the meantime.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 738029bc12)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update also the release url because the OpenPrinting https archive page
is out of sync with the current release archive on the main github
project.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a3c50b7427)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
"mschap" and "realm" are already part of default required
raddb modules(DEFAULT_MODULES in raddb/all.mk).
so removed them from disabled module list so that
radiusd.service can start without following errors:
- /etc/raddb/mods-enabled/mschap[11]: Failed to link to module 'rlm_mschap': /usr/lib/rlm_mschap.so
- /etc/raddb/mods-enabled/realm[21]: Failed to link to module 'rlm_realm': /usr/lib/rlm_realm.so
Signed-off-by: Kalpesh Panchal <kalpesh.panchal2@collins.com>
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ce918125e1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The description of REFPOLICY_CUSTOM_GIT states:
The custom refpolicy must define the full policy explicitly,
and must be a fork of the original refpolicy, to have the
same build system. When this is selected, only the custom
policy definition are taken into account and all the modules
of the policy are built into the binary policy.
Currently, if a user definess their own policy, a package containing a selinux
directory would add to their custom policy, which is not what they would want.
Disable applying selinux policies in selinux/ directories for custom git
refpolicies.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5f6e608057)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The licensing terms are inherited from the target variant to the host
variant: when the host _LICENSE is empty, then the value of the target
_LICENSE is used.
However, for the golang infra, we want to append a little blurb about
vendored depndencies. If the package is a host-only, then it would
inherit the target _LICENSE, i.e. the variable without the leading
HOST_. If that is defined, this is inherited in the generic-package part
of the infra, but in the golang infra, we saw an empty variable, and so
we would not add the vendoring blurb.
We can't move the condition appending that blurb, after we called into
the generic-package infra, otherwise in that case, we'd have the
opposite issue for packages that are both target and host packages,
where the blurb would be duplicated for host packages...
Instead, we workaround the issue by duplicating the heuristic to inherit
the target value, from the generic- into the golang-package infra.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit aa87875b9f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The golang infrastructure automatically expands the list of licenses
with a little blurb that the licenses for vendored dependencies might be
missing in the list.
However, when a package does not define a license, the resulting text is
sub-optimal, resulting in a manifest that contains (with a leading
comma, yes):
, vendored dependencies licenses probably not listed
In that case, pointing out some unkown licensing terms may be part of
unkonwn licensing terms is superfluous.
Instead, just let the legal infra do its job, and report an "unkown"
license altogether.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 01a4614d10)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The licensing terms are inherited from the target variant to the host
variant: when the host _LICENSE is empty, then the value of the target
_LICENSE is used.
However, for the cargo infra, we want to append a little blurb about
vendored depndencies. If the package is a host-only, then it would
inherit the target _LICENSE, i.e. the variable without the leading
HOST_. If that is defined, this is inherited in the generic-package part
of the infra, but in the cargo infra, we saw an empty variable, and so
we would not add the vendoring blurb.
We can't move the condition appending that blurb, after we called into
the generic-package infra, otherwise in that case, we'd have the
opposite issue for packages that are both target and host packages,
where the blurb would be duplicated for host packages...
Instead, we workaround the issue by duplicating the heuristic to inherit
the target value, from the generic- into the cargo-package infra.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 049ea7b389)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The cargo infrastructure automatically expands the list of licenses with
a little blurb that the licenses for vendored dependencies might be
missing in the list.
However, when a package does not define a license, the resulting text is
sub-optimal, resulting in a manifest that contains (with a leading
comma, yes):
, vendored dependencies licenses probably not listed
In that case, pointing out some unkown licensing terms may be part of
unkonwn licensing terms is superfluous.
Instead, just let the legal infra do its job, and report an "unkown"
license altogether.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 0a8bc54e09)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
redis handling is wrong since the addition of the package in commit
736c4c1655. Indeed, freeradius-server
needs hiredis, not redis
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5a8d6014c7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
websocketpp had some ill-formed usage of template parameters which was
finally removed in C++20. Hence build fails when building with C++20
support enabled.
The patch is already in the develop branch but no new release was
done.
There are no autobuilder failures because websocketpp is a header-only
library, and there are no packages in Buildroot that depned on
websocketpp.
A build issue was encountered when bumping an internal project to
C++20. This issue triggered quite some bug reports in the project [0]
and there are backports to other package managers like vcpkg [1] and
conan [2].
[0] https://github.com/zaphoyd/websocketpp/pull/1060
[1] https://github.com/microsoft/vcpkg/pull/23669
[2] https://github.com/conan-io/conan-center-index/pull/15295
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
[Thomas: extend commit log with details provided by Michael.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9ac1a76fcf)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes a yet-to-be published security issue TROVE-2023-004. From the
announcement:
https://forum.torproject.org/t/security-release-0-4-7-16-and-0-4-8-8/10064
We are releasing an emergency security release fixing a high security bug
affecting relays.
This is tracked by the TROVE-2023-004 92 for which we’ll make the ticket
public once the packages and network has started to upgrade.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cpe:2.3🅰️northern.tech:mender is a valid CPE identifier for this
package:
https://nvd.nist.gov/products/cpe/detail/F90CE0C3-FCE6-40AA-8C0D-EDE2C81BD67B
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit f4a9cdb1f8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following (Windows-only) security issue:
CVE-2023-46695: Potential denial of service vulnerability in UsernameField
on Windows
The NFKC normalization is slow on Windows. As a consequence,
django.contrib.auth.forms.UsernameField was subject to a potential denial of
service attack via certain inputs with a very large number of Unicode
characters.
In order to avoid the vulnerability, invalid values longer than
UsernameField.max_length are no longer normalized, since they cannot pass
validation anyway.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
apache uses pkgconfig to find dependencies such as lua, nhgttp2, openssl
and systemd.
For openssl, pkgconfig is used since version 2.1.1 and
0d4387dedc
resulting in the following build failure since at least bump to version
2.4.54 in commit 78e5a9c40e:
ac_cv_path_PKGCONFIG=/usr/bin/pkg-config
[...]
configure:28669: checking for SSL_CTX_new
configure:28669: /home/buildroot/autobuild/instance-1/output-1/host/bin/armeb-buildroot-linux-uclibcgnueabi-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -g0 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/home/buildroot/autobuild/instance-1/output-1/host/armeb-buildroot-linux-uclibcgnueabi/sysroot/usr/bin/../../../../armeb-buildroot-linux-uclibcgnueabi/sysroot/usr/lib -L/usr/lib conftest.c -lssl -lcrypto -lpthread >&5
armeb-buildroot-linux-uclibcgnueabi-gcc: ERROR: unsafe header/library path used in cross-compilation: '-L/usr/lib'
Fixes:
- http://autobuild.buildroot.org/results/d85c86ee1070582014c7b29b39f9a9f356988220
- http://autobuild.buildroot.org/results/55d6bad8572138e200730d3a9f2dd1b9048fd95d
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1f6b53b1a4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Disable provisioning client when building statically to avoid the
following build failure raised since bump to version LTS_01_2022_Ref01
in commit 06bb3640c1 and
1de399fd48
which enabled provisioning client by default:
/home/buildroot/autobuild/instance-3/output-1/build/azure-iot-sdk-c-LTS_01_2023_Ref02/provisioning_client/deps/utpm/src/tpm_comm_linux.c:13:10: fatal error: dlfcn.h: No such file or directory
13 | #include <dlfcn.h>
| ^~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/894188649f66d9917e1ed94989ebe307102ab28c
- http://autobuild.buildroot.org/results/735b96c842796f309c33a0545eeb2e8f8d1f75ca
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ce0d4efa76)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add missing BR2_OPTIMIZE_FAST dependency to BR2_PACKAGE_ZABBIX_SERVER
to avoid the following build failure raised since commit
e702a05d89:
checking for Zabbix server/proxy database selection... error
configure: error: No database selected for Zabbix server/proxy. Use --with-mysql or --with-oracle or --with-postgresql or --with-sqlite3.
Fixes:
- http://autobuild.buildroot.org/results/ab403b45761c82f49a9380564bf10d3e7ae935f2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 6da2b51a66)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
TF-A prints a version string at boot which includes the version number as
specified in the Makefile and additional "build" information, specified by
the BUILD_STRING parameter:
https://trustedfirmware-a.readthedocs.io/en/v2.9/getting_started/build-options.html
BUILD_STRING: Input string for VERSION_STRING, which allows the TF-A build
to be uniquely identified. Defaults to the current git commit id.
This is implemented as:
# Default build string (git branch and commit)
ifeq (${BUILD_STRING},)
BUILD_STRING := $(shell git describe --always --dirty --tags 2> /dev/null)
endif
https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile#L225-L228
Which is never correct in the context of Buildroot, as the TF-A build
directory is never a git repo, and git will move up the directory tree and
possibly and (possibly) pick up the git version of Buildroot instead.
To fix that, explicitly set BUILD_STRING to the version of the package.
Pass it before BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES so it
can still be overridden by the user if needed.
strings images/tf-a-* | egrep '^v2\.'
v2.9(debug):2023.08-859-g99d78b52a0
v2.9(debug):v2.9
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5a8a7530bf)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cpe:2.3🅰️xiph:opusfile is a valid CPE identifier for this package:
https://nvd.nist.gov/products/cpe/detail/BB1B035B-FCF0-4854-AB18-0FD1181B0CC3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 522f25ed42)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-45158: An OS command injection vulnerability exists in
web2py 2.24.1 and earlier. When the product is configured to use
notifySendHandler for logging (not the default configuration), a crafted
web request may execute an arbitrary OS command on the web server using
the product.
https://jvn.jp/en/jp/JVN80476432https://github.com/web2py/web2py/compare/v2.24.1...v2.26.1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 30cb3d784c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
