As found out by Yann E. Morin in [1], apcupsd configure script is ugly,
and uses gcc to do the link line-wrapping which will raise the following
build failure with gcc 13:
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/bin/ld: /home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/lib/../lib64/libsupc++.a(eh_alloc.o): in function `std::basic_string_view<char, std::char_traits<char> >::compare(unsigned long, unsigned long, char const*, unsigned long) const':
eh_alloc.cc:(.text._ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm[_ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm]+0x44): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
It will also raise the following build failure on sparc/arc:
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-3/output-1/host/arceb-buildroot-linux-uclibc/sysroot/lib/libsupc++.a(eh_throw.o): in function `__exchange_and_add_dispatch':
/SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
Instead of trying to patch the configure script as advocated by
Yann E. Morin, set LD to TARGET_CXX as:
- this solution is quicker
- usptream is dead (last release in 2016)
- this solution has already been used in other packages (nodejs, zmqpp)
[1]: https://patchwork.ozlabs.org/project/buildroot/patch/20200812171821.2517-1-Evgeniy.Didin@synopsys.com/
Fixes:
- http://autobuild.buildroot.org/results/6096c3ddc5edf3204635c2c90246c2e8c8e074e7
- http://autobuild.buildroot.org/results/d8a/d8a3ab31c5b86871c7e1117f4ffa7b6cedfcb7e0/build-end.log
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cd2dcaa6c6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The condition checking whether the webrtc-audio-processing package is
enabled, added in commit
3ccd3b4c38 ("package/pipewire: bump to
version 0.3.32") is obviously incorrect, and can never be true.
Fix the condition to use the correct variable instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 52f8db409f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A number of packages try to detect if they are running in a git repo and run
git describe at build time instead of using the hard coded version number if
it succeed, leading to odd version numbers as they end up picking up the
Buildroot git version if building inside a Buildroot git checkout, E.G.:
rauc --version
rauc 2023.11-562-g9c954953b4+
This is because rauc builds with meson and uses vcs_tag:
https://github.com/rauc/rauc/blob/v1.11/meson.build#L168-L171https://mesonbuild.com/Reference-manual_functions.html#vcs_tag
Another example is micropython, where we already work around it by passing
GIT_DIR=.
In the context of Buildroot the packages are never built in their own git
checkout, so pass GIT_DIR=. to ensure git doesn't walk back up the
directory tree and finds the Buildroot git repo, which fixes the rauc (and
similar) issues.
>>> rauc 1.11 Building
..
ninja: Entering directory `/home/peko/source/buildroot/output-rauc/build/rauc-1.11//build'
[1/29] Generating version.h with a custom command
fatal: not a git repository: '.'
cat output-rauc/build/rauc-1.11/build/version.h
#define PACKAGE_STRING "rauc 1.11"
#define PACKAGE_VERSION "1.11"
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit c07aafa087)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 768f9f80f6 (support/download: generate even more reproducible
tarballs) causes non-reproducibility in tarballs we previousy
generated, especially the archives for two cargo-vendored packages,
ripgrep and sentry-cli.
The cause is that those two pakcages eventually vendor a file that has
the u+x bit set, but is otehrwise go-x. With 768f9f80f6, the files are
now go+x, so the hash for those generated archives has changed.
Besides, that commit was wrong: it did not account for the 'r' bit for
go part, leaving some non-reproducibility still unaccounted for.
So, to generate really reproducible archives, we would need to fix that
read bit as well, and that has the potential to affect all the archives
we generated so far. If we wanted to do so, we'd need a way to version
all generated archives, like we do for git and svn, but now for all the
different CVSes, as well as for all the vendoring post-processes.
For 768f9f80f6, all that was of conern was the working copies of CVSes
(i.e. git, svn, cvs...) that we cache in the Buildroot download dir, not
the temporary files during post-processing. Indeed, in that latter case,
the user has virtually no way to mangle with the mode of the
intermediate extract before repack.
And we do have a big fat warning that users should not attempt to meddle
with the git tree that Buildroot caches.
As 768f9f80f6 however demonstrates, is that it took quite a long time
between the introduction of the git caching, and the time someone
eventually discovered they could meddle in there. This shows that the
issue it not actually critical in most setups.
Also, the tar manual [0] hints at a better solution to handle
reproducibility, which even avoids touching the files on disk which is
even nicer:
‘--mode='go+u,go-w'’
Omit irrelevant information about file permissions.
If we were to actually handle the mode bit for reproducibility, we'd
need to:
- introduce archive versioning for all download backends and
prost-processing
- use the tar officially suggested method
So, revert that change, as it was incomplete, was not really fixing much
issues, and causes actual issues.
This reverts commit 768f9f80f6.
[0] https://www.gnu.org/software/tar/manual/tar.html#Reproducibility
Thanks to Vincent and Arnout for pointing at the tar manual.
Reported-by: Antoine Coutant <antoine.coutant@smile.fr>
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Vincent Fazio <vfazio@xes-inc.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
(cherry picked from commit 9fbd3d8574)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Use official tarball
- Update hash of license file (some packages have been added or removed
but the list of licenses is the same)
- Fix CVE-2023-7158: A vulnerability was found in MicroPython up to
1.21.0. It has been classified as critical. Affected is the function
slice_indices of the file objslice.c. The manipulation leads to
heap-based buffer overflow. It is possible to launch the attack
remotely. The exploit has been disclosed to the public and may be
used. Upgrading to version 1.22.0 is able to address this issue. It is
recommended to upgrade the affected component. The identifier of this
vulnerability is VDB-249180.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1e12b7dd49)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update site to avoid redirections (HSTS, etc.)
Version 5.0.3 - 12/17/2023
A memory leak fix in the prior version wasn't applied correctly, resulting
in an invalid memory access causing a crash. Bug fixed.
Version 5.0.2 - 11/8/2023
Fixed bug that caused crash when a CLIENT_KEY arrived out of order
Fixed option handling on Windows when an argument is missing
https://sourceforge.net/projects/uftp-multicast/files/Changes.txt/download
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit bfe2fe2269)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This usage of <PKG>_NAME was introduced in commit f9e9c6349a
("package/rng-tools: bump to 6.7"). No other package uses <PKG>_NAME
this way.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a2b8596873)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure without neon raised since bump to
version 1.4.0 in commit 2f7f8f3813 and
https://github.com/jgaeddert/liquid-dsp/commit/c821187dd9af2758c8e3c82e95eaf041b8ac81a0:
/home/peko/autobuild/instance-0/output-1/host/bin/arm-none-linux-gnueabi-gcc -std=gnu11 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=2 -ffast-math -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -Wall -fPIC -Wno-deprecated -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -Iinclude -c -o src/audio/src/cvsd.o src/audio/src/cvsd.c
In file included from /home/peko/autobuild/instance-0/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/features.h:388:0,
from /home/peko/autobuild/instance-0/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/stdlib.h:24,
from src/libliquid.c:25:
/home/peko/autobuild/instance-0/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory
# include <gnu/stubs-hard.h>
^
Indeed, upstream considers that NEON is available on all ARM platforms,
and their configure.ac contains that code snippet:
239 arm|armv7*|armv8*)
240 # assume neon instructions are available
241 # TODO: check for Neon availability
242
243 # ARM architecture : use neon extensions
Fixes:
- http://autobuild.buildroot.org/results/36b3c2220c462e7a20262fd1b9064d9aeb6c9ec4
- http://autobuild.buildroot.org/results/881826b4b6c141e59a0da2d7d1ad55d3709fdb95
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- refactor with LIQUID_DSP_SIMDOVERRIDE
- add comment about --disable-simdoverride
- extend commit log with upstream code snippet
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 9501bc80f5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libaio is only needed for standard install
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: fix check-package]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit ee9c92e4a4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
--{dis,en}able-avahi is unrecognized since bump to version 2.3.3op2 in
commit 8cf034ab0f (which switched upstream
location from apple to openprinting):
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --disable-dependency-tracking, --enable-ipv6, --disable-nls, --disable-systemd, --disable-avahi
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 36743d6175)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With [1], [2] & [3] we made sure Buildroot packages get built with
proper MMU page size assumed. This was done nicely through insertion of
required flags into the toolchain wrapper so that there's no need to
pass these flags to each and every package separately - toolchain
wrapper used for real building has all set internally and so proper
flags are implicitly used.
But there's yet another corner case which is not handled that way -
these are binaries or rather libraries which are being used as a part of
GCC compilation: libgcc_s.so.1 and libstdc++.so.
And so to make sure both the libraries get built properly we need to
set TARGET_CFLAGS (cures libgcc_s.so) & TARGET_LDFLAGS (cures
libstdc++.so).
In case of ARM by defaut 64 KiB page size seems to be used, as w/o
that patch we see the following for BR2_ARM64_PAGE_SIZE_4K=y:
--------------------------->8----------------------------
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/lib/libgcc_s.so.1
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000013d1c 0x0000000000013d1c R E 0x10000
LOAD 0x000000000001fd98 0x000000000002fd98 0x000000000002fd98
0x0000000000000438 0x00000000000005c8 RW 0x10000
DYNAMIC 0x000000000001fdb8 0x000000000002fdb8 0x000000000002fdb8
0x0000000000000200 0x0000000000000200 RW 0x8
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/usr/lib/libstdc++.so.6.0.32
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001d3462 0x00000000001d3462 R E 0x10000
LOAD 0x00000000001d5760 0x00000000001e5760 0x00000000001e5760
0x000000000000e528 0x0000000000012de8 RW 0x10000
DYNAMIC 0x00000000001deef0 0x00000000001eeef0 0x00000000001eeef0
0x0000000000000240 0x0000000000000240 RW 0x8
--------------------------->8----------------------------
Note alignment of 0x10000 in sections marked for loading.
And with the patch applied we get expected alignment of 0x1000 (4
KiB):
--------------------------->8----------------------------
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/lib/libgcc_s.so.1
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000013d1c 0x0000000000013d1c R E 0x1000
LOAD 0x0000000000013d98 0x0000000000014d98 0x0000000000014d98
0x0000000000000438 0x00000000000005c8 RW 0x1000
DYNAMIC 0x0000000000013db8 0x0000000000014db8 0x0000000000014db8
0x0000000000000200 0x0000000000000200 RW 0x8
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/usr/lib/libstdc++.so.6.0.32
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001d3462 0x00000000001d3462 R E 0x1000
LOAD 0x00000000001d3760 0x00000000001d4760 0x00000000001d4760
0x000000000000e528 0x0000000000012de8 RW 0x1000
DYNAMIC 0x00000000001dcef0 0x00000000001ddef0 0x00000000001ddef0
0x0000000000000240 0x0000000000000240 RW 0x8
--------------------------->8----------------------------
A nice side effect is that we can get rid of the special handling of
"-matomic" as it's already part of ARCH_TOOLCHAIN_WRAPPER_OPTS.
[1] https://git.buildroot.net/buildroot/commit/?id=3cc2c6d19ab2e1bb4634f26f9318da9b07df5fff
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
[3] https://git.buildroot.net/buildroot/commit/?id=5e52c28397b79f8c4c99552217cbe95202166626
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vladimir Isaev <VVIsaev@gmail.com>
Signed-off-by: Pavel Kozlov <kozlov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 747dff5a36)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following musl build failure with powerpc raised since bump to
version 2.14 in commit c6addf4606:
In file included from fault.h:36,
from handler-unix.c:77,
from handler.c:19:
handler-unix.c: In function 'sigsegv_handler':
fault-linux-powerpc.h:35:73: error: 'mcontext_t' has no member named 'uc_regs'; did you mean 'gregs'?
35 | # define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.uc_regs->gregs[1]
| ^~~~~~~
handler-unix.c:157:43: note: in expansion of macro 'SIGSEGV_FAULT_STACKPOINTER'
157 | uintptr_t old_sp = (uintptr_t) (SIGSEGV_FAULT_STACKPOINTER);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/77b600071f07605be3ec28e2da46d6938e240087
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 74f401025d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bumping libssh2 to 1.11.0 with buildroot commit
af87ad197c
causes build errors with libcurl due to "-R" being added to libssh2.pc.
Quoting autobuilder build-end.log
checking for recv... no
configure: error: Unable to link function recv
Quoting autobuilder libcurl-8.1.2/config.log
arc-buildroot-linux-uclibc-gcc.br_real: error: unrecognized command-line option '-R'
Fixes:
http://autobuild.buildroot.net/results/78f/78ffda92d51f8abdbcef93f968ace432d0d44979/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 409a5f9876)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann reported in [1] that edk2 build could sometimes fail. The issue
can be reproduced when per-package directories is enabled, or also
when building on a system with GNU Make >= 4.4 using the
"--shuffle=reverse" option (such as Fedora 39). Those are pointing
toward a Makefile dependency issue.
The issue can be reproduced with commands:
cat > .config <<EOF
BR2_riscv=y
BR2_RISCV_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TARGET_EDK2=y
EOF
make olddefconfig
Then, building either with:
make --shuffle=reverse
Or:
utils/config -e BR2_PER_PACKAGE_DIRECTORIES
make olddefconfig
make -j$(nproc)
It is interesting to mention that when using "make --shuffle=reverse"
to build, the build can be completed if restarted only with "make". It
will not pull any other Buildroot package. This fact hints toward a
Makefile dependency issue internal to the EDK2 build system, rather
than in the Buildroot recipe.
The EDK2 build system is quite unique. See [2]. It generates files,
makefiles and internally uses GNU Make to compile code. This system is
likely not tested as being a sub-Make process in a complex Makefile
such as Buildroot.
In order to prevent Buildroot to pass unexpected Make flags to the
EDK2 sub-Make, this commit unset the MAKEFLAGS variable in the EDK2
build environment. This will put the EDK2 build script in a more
common and tested state. See GNU Make documentation about recursive use
of Make, more specifically [3].
Note: as mentioned, the build failure is likely due to an internal
issue of the EDK2 build system. The failure points to a missing
dependency in the EDK2 generator itself. This commit does not fix this
issue, but rather put the EDK2 build system in a normalized
environment, avoiding Buildroot flags being passed to the internal
EDK2 sub-Make invocation. The upstream EDK2 build system most likely
need a fix too.
Fixes:
make[2]: *** No rule to make target '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.efi', needed by '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/FV/Ffs/462CAA21-7614-4503-836E-8AB6F4662331UiApp/UiApp.offset'. Stop.
build.py...
: error 7000: Failed to execute command
make tbuild [/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp]
build.py...
: error F002: Failed to build module
/buildroot/output/build/edk2-edk2-stable202308/MdeModulePkg/Application/UiApp/UiApp.inf [RISCV64, GCC5, RELEASE]
[1] https://lists.buildroot.org/pipermail/buildroot/2023-December/681507.html
[2] https://tianocore-docs.github.io/edk2-BuildSpecification/draft/4_edk_ii_build_process_overview/42_build_process_overview.html
[3] https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
Reported-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 44af6938fb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
1) CVE-2023-6377: X.Org server: Out-of-bounds memory write in XKB button actions
A device has XKB button actions for each button on the device. When a
logical device switch happens (e.g. moving from a touchpad to a mouse), the
server re-calculates the information available on the respective master
device (typically the Virtual Core Pointer). This re-calculation only
allocated enough memory for a single XKB action rather instead of enough for
the newly active physical device's number of button. As a result, querying
or changing the XKB button actions results in out-of-bounds memory reads and
writes.
This may lead to local privilege escalation if the server is run as root or
remote code execution (e.g. x11 over ssh).
2) CVE-2023-6478: X.Org server: Out-of-bounds memory read in
RRChangeOutputProperty and RRChangeProviderProperty
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->nUnits value the expected request size was truncated,
passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->nUnits bytes
(depending on stuff->format) from the request and stuffing whatever it finds
into the property. In the process it would also allocate at least
stuff->nUnits bytes, i.e. 4GB.
See also CVE-2022-46344 where this issue was fixed for other requests.
For more details, see the advisory:
https://lists.x.org/archives/xorg-announce/2023-December/003435.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9b62f5905e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 5770a645a3 ("package/qt5:
bump packages to latest kde submodule versions"), the
QT_HEADERS_SYNC_HOOK hook no longer calls the syncqt.pl script, so
host-perl is no longer needed as a dependency of running this
hook (and as a dependency of building Qt).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit b678091a1c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_DOWNLOAD_FORCE_CHECK_HASHES currently has the following
dependency:
depends on BR2_GLOBAL_PATCH_DIR != ""
However, strictly speaking checking all hashes does not necessarily
require using BR2_GLOBAL_PATCH_DIR, as long as you don't use custom
versions.
But more importantly:
- Having this dependency means that this options is hidden when people
don't use BR2_GLOBAL_PATCH_DIR. Instead the option should always be
made visible, encouraging people to turn it on.
- The Config.in comment was there to mitigate this previous argument,
but this comment then shows up all the time when you have an empty
global patch dir.
This seems over-complicated, and it sounds much easier to have the
option unconditionally available, and visible, and clarify in its help
text that in order to this to work fully with custom package versions,
BR2_GLOBAL_PATCH_DIR can be used to provide extra hash files.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- fix typo noticed by Peter K.
- reword kast sentence after review by Peter K.
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5b0c02a77a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop patches (already in version) and so drop autoreconf
- Fix the following security issues:
- CVE-2023-40660: Fix Potential PIN bypass
- CVE-2023-40661: Important dynamic analyzers reports
- CVE-2023-4535: Out-of-bounds read in MyEID driver handling
encryption using symmetric keys
https://github.com/OpenSC/OpenSC/releases/tag/0.24.0
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 37eb68c9fb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure with libressl >= 3.8 raised since bump
of libressl to version 3.8.2 in commit
21eca49ed5:
In file included from card-westcos.c:37:
/home/autobuild/autobuild/instance-11/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/openssl/evp.h:627:32: error: macro "EVP_sha3_224" passed 1 arguments, but takes just 0
627 | const EVP_MD *EVP_sha3_224(void);
| ^
Fixes:
- http://autobuild.buildroot.org/results/cecee659371f370bf4bd2b27a4752bf20ceff326
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e8ca87083b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As described in the announcement, this fixes a security issue:
There is one security fix in this release:
- Fix for a newly discovered security issue known as the 'Terrapin'
attack, also numbered CVE-2023-48795. The issue affects widely-used
OpenSSH extensions to the SSH protocol: the ChaCha20+Poly1305
cipher system, and 'encrypt-then-MAC' mode.
In order to benefit from the fix, you must be using a fixed version
of PuTTY _and_ a server with the fix, so that they can agree to
adopt a modified version of the protocol. Alternatively, you may be
able to reconfigure PuTTY to avoid selecting any of the affected
modes.
If PuTTY 0.80 connects to an SSH server without the fix, it will
warn you if the initial protocol negotiation chooses an insecure
mode to run the connection in, so that you can abandon the
connection. If it's possible to alter PuTTY's configuration to
avoid the problem, then the warning message will tell you how to do
it.
https://lists.tartarus.org/pipermail/putty-announce/2023/000037.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 922132c39e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following static build failure raised since bump to version 0.78
in commit 5673ea3ce4:
In file included from /home/buildroot/autobuild/instance-0/output-1/build/putty-0.78/putty.h:8,
from /home/buildroot/autobuild/instance-0/output-1/build/putty-0.78/callback.c:8:
/home/buildroot/autobuild/instance-0/output-1/build/putty-0.78/unix/platform.h:11:10: fatal error: dlfcn.h: No such file or directory
11 | #include <dlfcn.h> /* Dynamic library loading */
| ^~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/06f0b14bd0414f97b06070198e290fb3253348c5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3d8e0a263f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
5 CVEs affecting glibc according to the NVD database are considered as
not being security issues by upstream glibc developers:
* CVE-2010-4756: The glob implementation in the GNU C Library (aka
glibc or libc6) allows remote authenticated users to cause a denial
of service (CPU and memory consumption) via crafted glob expressions
that do not match any pathnames. glibc maintainers position: "That's
standard POSIX behaviour implemented by (e)glibc. Applications using
glob need to impose limits for themselves"
* CVE-2019-1010022: GNU Libc current is affected by: Mitigation
bypass. The impact is: Attacker may bypass stack guard
protection. The component is: nptl. The attack vector is: Exploit
stack buffer overflow vulnerability and use this bypass
vulnerability to bypass stack guard. NOTE: Upstream comments
indicate "this is being treated as a non-security bug and no real
threat. glibc maintainers position: "Not treated as a security issue
by upstream https://sourceware.org/bugzilla/show_bug.cgi?id=22850"
* CVE-2019-1010023: GNU Libc current is affected by: Re-mapping
current loaded library with malicious ELF file. The impact is: In
worst case attacker may evaluate privileges. The component is:
libld. The attack vector is: Attacker sends 2 ELF files to victim
and asks to run ldd on it. ldd execute code. NOTE: Upstream comments
indicate "this is being treated as a non-security bug and no real
threat. glibc maintainers position: "Not treated as a security issue
by upstream https://sourceware.org/bugzilla/show_bug.cgi?id=22851"
* CVE-2019-1010024: GNU Libc current is affected by: Mitigation
bypass. The impact is: Attacker may bypass ASLR using cache of
thread stack and heap. The component is: glibc. NOTE: Upstream
comments indicate "this is being treated as a non-security bug and
no real threat. glibc maintainers position: "Not treated as a
security issue by upstream
https://sourceware.org/bugzilla/show_bug.cgi?id=22852"
* CVE-2019-1010025: GNU Libc current is affected by: Mitigation
bypass. The impact is: Attacker may guess the heap addresses of
pthread_created thread. The component is: glibc. NOTE: the vendor's
position is "ASLR bypass itself is not a vulnerability. Glibc
maintainers position: "Not treated as a security issue by upstream
https://sourceware.org/bugzilla/show_bug.cgi?id=22853"
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit adaae82c58)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As reported in bug 15895, the GLIBC_VERSION field having a value
looking like 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701, it
prevents the CPE/CVE matching with the NVD database to work correctly.
This commit fixes that by defining GLIBC_CPE_ID_VERSION, derived from
GLIBC_VERSION, by extracting the base version.
Also, we update GLIBC_IGNORE_CVES to account for the CVEs that have
clearly been fixed between 2.38 and
2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701. There are a number
of other CVEs still affecting the glibc package, but they are not
related to this
2.38...2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701 range.
Fixes: #15895
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit af8c0e5c74)
[Peter: adjust for glibc 2.36.x on 2023.02.x]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
OpenSSH 9.6 was released on 2023-12-18.
This release contains fixes for a newly-discovered weakness in the
SSH transport protocol (the "Terrapin" attack), a logic error relating
to constrained PKCS#11 keys in ssh-agent(1) and countermeasures for
programs that invoke ssh(1) with user or hostnames containing invalid
characters.
https://www.openssh.com/txt/release-9.6
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3c047ea463)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
linux-pam is required to login via OpenSSH if the upstream refpolicy for
SELinux is enaabled, as linux-pam handles changing user contexts. If a
user wants to make their own policy and use a refpolicy via git, we of course
should let them do so. As such, only select linux-pam if the upstream version
of refpolicy is selected.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 2c5a82a29c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the update of Python to version 3.11 in commit
738500c296 ("package/python3: bump to
version 3.11.0"), python-sip fails to compile with:
siplib.c: In function ‘sip_api_get_frame’:
siplib.c:13750:22: error: invalid use of undefined type ‘struct _frame’
13750 | frame = frame->f_back;
This is due to a change in the Python C API, which is fixed by a new
patch. The patch can't be upstreamed, as SIP 4.x is no longer
maintained upstream.
Fixes:
http://autobuild.buildroot.net/results/7b01739e7514e48c06182bc1804b32497ce2e414/
Signed-off-by: Ralf Dragon <hypnotoad@lindra.de>
[Thomas: improved commit log, reformatted patch using Git]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 3ef6884e6d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- CVE-2023-5367 X.Org server: OOB write in
XIChangeDeviceProperty/RRChangeOutputProperty
- CVE-2023-5380: Use-after-free bug in DestroyWindow
- CVE-2023-5574: Use-after-free bug in DamageDestroy
For details, see the advisory:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 36a9ec8921)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
rsync is used in the infrastructure, mostly for the per-package infra,
and for the override-srcdir mechanism, but also to build the manual.
As such, it is not optional but mandatory, and already listed so.
Drop the reference to rsync from the list of optional packages.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b79fb3c224)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- CVE-2023-46218: cookie mixed case PSL bypass
This flaw allows a malicious HTTP server to set "super cookies" in curl
that are then passed back to more origins than what is otherwise allowed
or possible. This allows a site to set cookies that then would get sent
to different and unrelated sites and domains.
https://curl.se/docs/CVE-2023-46218.html
- CVE-2023-46219: HSTS long file name clears contents
When saving HSTS data to an excessively long file name, curl could end up
removing all contents, making subsequent requests using that file unaware
of the HSTS status they should otherwise use.
https://curl.se/docs/CVE-2023-46219.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit aaa9438b96)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/5834758777
Commit e7d16c35a (boot/arm-trusted-firmware: fix the RPATH of fiptool) tried
to fix the build of host-fiptool, but forgot to pass HOST_CFLAGS.
On hosts without (compatible) openssl development headers, this breaks
the build when it cannot find the openssl headers:
fiptool_platform.h:19:11: fatal error: openssl/sha.h: No such file or directory
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e6ef64d955)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The arm-trusted-firmware package builds a host tool called "fiptool",
which is used during the build process of arm-trusted-firmware
itself. This tool links against the OpenSSL host library, and
therefore needs to be built with the correct RPATH pointing to
$HOST_DIR/lib.
This is why commit a957d9a90a
("boot/arm-trusted-firmware: build fiptool separately with dependency
o n host-openssl") added the ARM_TRUSTED_FIRMWARE_BUILD_FIPTOOL
variable, which builds the fiptool tool first, with the right
variables set, before invoking the full build of TF-A. This ensured
that fiptool was built with the correct RPATH.
However, more recent versions of TF-A have modified their Makefile
machinery, and fiptool is being rebuilt even if it was built
before. Unfortunately, this rebuild is no longer done with the right
flags, so we end up with a fiptool binary that no longer has the right
RPATH, and fiptool fails to find the OpenSSL libraries from
$HOST_DIR/lib.
In order to fix this, we take a different approach: we do not build
fiptool separately first, but we inject the necessary flags through
the HOSTCC variable. Indeed, there's no HOST_LDFLAGS or HOST_LDLIBS
variable or similar that would allow us to pass the -Wl,-rpath flag
that is needed. Shoe-horning this flag into HOSTCC gets the job done,
and actually simplifies our arm-trusted-firmware.mk.
This patch break the compatibility with version prior to 1.4 (upstream
commit 72610c4102990 ("build: Introduce HOSTCC flag")). v1.4 is very old
(July 2017), not used anymore in-tree and probably not used anymore
outside the tree.
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Co-authored-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e7d16c35ae)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following CVEs:
CVE-2023-39326: net/http: limit chunked data overhead
CVE-2023-45285: cmd/go: go get may unexpectedly fallback to insecure git
https://go.dev/doc/devel/release#go1.20.12
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If systemd is used we should enable support in mariadb and enable
"Type=notify" in the mysqld.service unit file
"Type=notify" stops systemd from starting services which depend on mariadb
until it has notified systemd that it has finished starting up, this helps
avoid startup race conditions
Signed-off-by: Danny Wood <danny@rotronics.co.uk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1a9ad16ed8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The defconfig fetches Linux and U-Boot from a git repo using the
unauthenticated git:// protocol, so add download hashes for them to ensure
we get the right sources by adding a global patch dir and running
utils/add-custom-hashes.
The defconfig uses the Linux sources for the kernel headers, so make
linux-headers/linux-headers.hash a symlink to linux/linux.hash so the same
hash file is used.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit cdc9b8a3a7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure with gcc >= 12:
task.c: In function 't_start':
task.c:398:16: error: 'ret' may be used uninitialized [-Werror=maybe-uninitialized]
398 | return ret;
| ^~~
task.c:364:13: note: 'ret' was declared here
364 | int ret;
| ^~~
task.c: In function 't_resume':
task.c:444:16: error: 'ret' may be used uninitialized [-Werror=maybe-uninitialized]
444 | return ret;
| ^~~
task.c:428:13: note: 'ret' was declared here
428 | int ret;
| ^~~
Fixes:
- http://autobuild.buildroot.org/results/bc1b40de22e563b704ad7f20b6bf4d1f73a6ed8a
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit a3db1dd1b7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following NLS build failure raised since the addition of the
package in commit 9f4f8c5f89:
/home/buildroot/autobuild/run/instance-2/output-1/host/lib/gcc/arm-buildroot-linux-musleabihf/12.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: ../../src/common/.libs/libcommon.a(libcommon_la-i18n.o): undefined reference to symbol 'libintl_bindtextdomain'
Fixes:
- http://autobuild.buildroot.org/results/8ab13cf474d732c95a1da65592d950b24b3d474b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f6a7050d71)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
fix CVE-2023-47038 - Write past buffer end via illegal user-defined Unicode property
note: 5.36.2 was a broken release
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit bc7b0e1002)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-38703: PJSIP is a free and open source multimedia
communication library written in C with high level API in C, C++, Java,
C#, and Python languages. SRTP is a higher level media transport which
is stacked upon a lower level media transport such as UDP and ICE.
Currently a higher level transport is not synchronized with its lower
level transport that may introduce use-after-free issue. This
vulnerability affects applications that have SRTP capability
(`PJMEDIA_HAS_SRTP` is set) and use underlying media transport other
than UDP. This vulnerability’s impact may range from unexpected
application termination to control flow hijack/memory corruption. The
patch is available as a commit in the master branch.
https://github.com/pjsip/pjproject/security/advisories/GHSA-f76w-fh7c-pc66https://github.com/pjsip/pjproject/releases/tag/2.14
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 38c4aa2826)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following wolfssl build failure raised at least since bump to
version 7.4.0 in commit 6b5907bf65:
/home/autobuild/autobuild/instance-4/output-1/build/rtty-8.1.0/src/ssl/openssl.c: In function 'ssl_last_error_string':
/home/autobuild/autobuild/instance-4/output-1/build/rtty-8.1.0/src/ssl/openssl.c:143:24: error: implicit declaration of function 'ERR_peek_error_line_data'; did you mean 'wolfSSL_ERR_get_error_line_data'? [-Werror=implicit-function-declaration]
143 | ssl_err_code = ERR_peek_error_line_data(&file, &line, &data, &flags);
| ^~~~~~~~~~~~~~~~~~~~~~~~
| wolfSSL_ERR_get_error_line_data
Fixes:
- http://autobuild.buildroot.org/results/9db9f1dcc6760de4b78771bb79f109c4efd06c36
- http://autobuild.buildroot.org/results/16422af9469de114e552124542508c3b18ea8f19
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: don't force wolfssl-all]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 67cb7d8d09)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-45322: libxml2 through 2.11.5 has a use-after-free that can
only occur after a certain memory allocation fails. This occurs in
xmlUnlinkNode in tree.c. NOTE: the vendor's position is "I don't think
these issues are critical enough to warrant a CVE ID ... because an
attacker typically can't control when memory allocations fail."
https://gitlab.gnome.org/GNOME/libxml2/-/blob/v2.11.6/NEWS
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e5af07dce9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-46852: In Memcached before 1.6.22, a buffer overflow exists
when processing multiget requests in proxy mode, if there are many
spaces after the "get" substring.
Fix CVE-2023-46853: In Memcached before 1.6.22, an off-by-one error
exists when processing proxy requests in proxy mode, if \n is used
instead of \r\n.
https://github.com/memcached/memcached/wiki/ReleaseNotes1622
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit bc96e9da0d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-47359: Videolan VLC prior to version 3.0.20 contains an
incorrect offset read that leads to a Heap-Based Buffer Overflow in
function GetPacket() and results in a memory corruption.
Fix CVE-2023-47360: Videolan VLC prior to version 3.0.20 contains an
Integer underflow that leads to an incorrect packet length.
https://code.videolan.org/videolan/vlc/-/blob/3.0.20/NEWS
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit d675873f4f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since bump of webp to version
1.3.2 in commit c88c1d3319:
/home/autobuild/autobuild/instance-9/output-1/host/lib/gcc/aarch64_be-buildroot-linux-uclibc/13.2.0/../../../../aarch64_be-buildroot-linux-uclibc/bin/ld: picture.o: undefined reference to symbol 'WebPMemoryWriterClear'
/home/autobuild/autobuild/instance-9/output-1/host/lib/gcc/aarch64_be-buildroot-linux-uclibc/13.2.0/../../../../aarch64_be-buildroot-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-9/output-1/host/aarch64_be-buildroot-linux-uclibc/sysroot/usr/lib64/libwebp.so.7: error adding symbols: DSO missing from command line
Fixes:
- http://autobuild.buildroot.org/results/9b859a701debeaddf1f9909e16adc6811a620576
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1267a234ff)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 13fc9dcb34, netsnmp was bumped
from 5.9.3 to 5.9.4 to fix two CVEs.
However, even though it's a minor version bump, there are actually 163
commits upstream between those two minor releases, and some of them
are breaking existing use-cases. In particular upstream
a2cb167514ac0c7e1b04e8f151e0b015501362e0 now requires that config_()
macros in MIB files are terminated with a semicolon, causing a build
breakage with existing MIB files that were totally valid with 5.9.3.
This commit therefore proposes to revert back to 5.9.3, by reverting
those two commits:
56caafceab package/netsnmp: fix musl build
13fc9dcb34 package/netsnmp: security bump to version 5.9.4
and instead backport the one upstream commit that fixes both CVEs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: fix typo as reported by Baruch]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 44243b4c80)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Git-generated patches embed the short-hash of the objects in the
repository. The length of those short hashes are subject to change
in at least three cases:
- the number of objects in the repository increases, so git increases
the length of short hashes to get a good change there is no
collision;
- the git configuration changes, see core.abbrev in git-config;
- the heuristic to compute the length changes in a newer git version.
Since the bump to zfs 2.1.4 in commit 68dfd09708, the patch generated
by github has changed, causing download failures:
wget --passive-ftp -nd -t 3 -O '/home/ymorin/dev/buildroot/O/master/build/.bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch.uoFq9e/output' 'https://github.com/openzfs/zfs/commit/bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch'
--2023-11-26 16:53:25--
https://github.com/openzfs/zfs/commit/bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch
Resolving github.com (github.com)... 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2976 (2.9K) [text/plain]
Saving to: ‘/home/ymorin/dev/buildroot/O/master/build/.bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch.uoFq9e/output’
/home/ymorin/dev/buildroot/O/ 100%[================================================>] 2.91K --.-KB/s in 0s
2023-11-26 16:53:25 (15.0 MB/s) - ‘/home/ymorin/dev/buildroot/O/master/build/.bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch.uoFq9e/output’ saved [2976/2976]
ERROR: while checking hashes from package/zfs//zfs.hash
ERROR: bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch has wrong sha256 hash:
ERROR: expected: 96a27353fe717ff2c8b95deb8b009c4eb750303c6400e2d8a2582ab1ec12b25a
ERROR: got : 246c80f66abca5a7e0c41cc7c56eec0b4cb7f16b142262480401142bbc2f999f
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
And indeed, the length of short hashes has increased by one since then.
Fix that by bundling the patch, with the short hashes that were known
then, so that it matches the sha256 we had for it.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2c3946fcb4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gcc.mk attempts to disable building the documentation by setting
MAKEINFO=missing, but it is not working. If makeinfo is installed
and recent enough, gcc still uses it. This can be checked easily:
grep BUILD_INFO='info' host-gcc-initial-*/build/gcc/config.log
It happens because the root ./configure script will check
$MAKEINFO --version (aka 'missing --version') and will overwrite it with
MAKEINFO='missing makeinfo' because the version does not match.
Having MAKEINFO='missing makeinfo' is a problem because
'missing makeinfo' will actually attempt to run 'makeinfo' before
failing with an error message. If makeinfo is installed on the host,
then 'missing makeinfo' will successfully run makeinfo anyway.
Many gcc subprojects will check $MAKEINFO --version and enable building
the documentation if it is recent enough. This patch overrides these
checks by forcing gcc_cv_prog_makeinfo_modern=no.
Building the GCC documentation can fail with the wrong makeinfo version.
It happened at least when building GCC 11.3.0 with makeinfo 7.1.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit f7b9d3ad2b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2022-48303: GNU Tar through 1.34 has a one-byte out-of-bounds read
that results in use of uninitialized memory for a conditional jump.
Exploitation to change the flow of control has not been demonstrated. The
issue occurs in from_header in list.c via a V7 archive in which mtime has
approximately 11 whitespace characters.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: add _IGNORE_CVES entry]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit ad0bb50dc7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit d4d483451f.
Tar 1.35 unfortunately changes the behaviour for the devmajor/devminor
fields, breaking the download hash validation. From the release notes:
* Leave the devmajor and devminor fields empty (rather than zero) for
non-special files, as this is more compatible with traditional tar.
https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00005.html
So revert the bump for now.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f2b23a6320)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
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>
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>
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>
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>
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>
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
https://github.com/apache/httpd/commit/0d4387dedc4ad83460bf52fc326c475c64133634
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>
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>
nettle uses m4 during its build process. Without it, the build fails
with:
m4 ./m4-utils.m4 ./asm.m4 config.m4 machine.m4 aes-decrypt-internal.asm >aes-decrypt-internal.s
/bin/sh: 1: m4: not found
For the target package this is not visible, as the existing gmp
dependency pulls in host-m4. But technically speaking, nettle needs
host-m4 directly, so it makes sense to have this dependency.
For the host package, it clearly fails to build, but probably isn't
very visible as most systems have m4 installed system-wide: this was
noticed when building inside Buildroot's minimal Docker
container. There are no recorded autobuilder failures for this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d4ca1b03c0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This maybe the last patch for OpenSSL 1.1.1 LTS, it had reached
end-of-life on 2023-09-11.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Medium] A fix was added, but still under review for completeness, for a
Bleichenbacher style attack, leading to being able to decrypt a saved
TLS connection and potentially forge a signature after probing with a
large number of trial connections. This issue is around RSA decryption
and affects static RSA cipher suites on the server side, which are not
recommended to be used and are off by default. Static RSA cipher suites
were also removed from the TLS 1.3 protocol and only present in TLS 1.2
and lower. All padding versions of RSA decrypt are affected since the
code under review is outside of the padding processing. Information
about the private keys is NOT compromised in affected code. It's
recommended to disable static RSA cipher suites and update the version
of wolfSSL used if using RSA private decryption alone outside of TLS.
https://github.com/wolfSSL/wolfssl/releases/tag/v5.6.4-stable
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit c4658ede71)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
An issue was discovered in the C AMQP client library (aka rabbitmq-c)
through 0.13.0 for RabbitMQ. Credentials can only be entered on the
command line (e.g., for amqp-publish or amqp-consume) and are thus
visible to local attackers by listing a process and its arguments.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit c3fcaeaaa7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop --without-x (now unrecognized)
- Fix CVE-2023-40745: LibTIFF is vulnerable to an integer overflow. This
flaw allows remote attackers to cause a denial of service (application
crash) or possibly execute an arbitrary code via a crafted tiff image,
which triggers a heap-based buffer overflow.
- Fix CVE-2023-41175: A vulnerability was found in libtiff due to
multiple potential integer overflows in raw2tiff.c. This flaw allows
remote attackers to cause a denial of service or possibly execute an
arbitrary code via a crafted tiff image, which triggers a heap-based
buffer overflow.
https://libtiff.gitlab.io/libtiff/releases/v4.6.0.html
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e96b1c4b0b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
git.code.sf.net is available over HTTPS, so use that for security and
consistency with the other packages.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 99d525028f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
git.code.sf.net is available over HTTPS, so use that for security and
consistency with the other packages.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit f2a590750f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that we have HTTPS support for sources.buildroot.net (through Lets
encrypt / Cloudflare), it makes sense to default to it for our backup site.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 05296ced36)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
MiniZip in zlib through 1.3 has an integer overflow and resultant
heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long
filename, comment, or extra field. NOTE: MiniZip is not a supported part
of the zlib product.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit de7bc4ada2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
CVE-2023-43665: Denial-of-service possibility in django.utils.text.Truncator
Following the fix for CVE-2019-14232, the regular expressions used in the
implementation of django.utils.text.Truncator’s chars() and words() methods
(with html=True) were revised and improved. However, these regular
expressions still exhibited linear backtracking complexity, so when given a
very long, potentially malformed HTML input, the evaluation would still be
slow, leading to a potential denial of service vulnerability.
The chars() and words() methods are used to implement the truncatechars_html
and truncatewords_html template filters, which were thus also vulnerable.
The input processed by Truncator, when operating in HTML mode, has been
limited to the first five million characters in order to avoid potential
performance and memory issues.
https://www.djangoproject.com/weblog/2023/oct/04/security-releases/
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
commit 21d52e52d8 (package/pkg-utils.mk: break hardlinks in global
{TARGET, HOST}_DIR on per-package build) was recently reverted, so we
are back to a situation where it is possible for packages and post-build
scripts to modify files in-place, and thus impact files in any arbitrary
per-package directory, which may break things on rebuild for example.
21d52e52d8 was too big a hammer, but we can still apply the reasoning
from it, to the aggregation of the final target and host directories.
This solves the case for post-build scripts at least. We leave the case
of inter-package modification aside, as it is a bigger issue that will
need more than just copying files around.
We use --hard-links, so that hard-links in the source (the PPD), are
kept as new hard-links (i.e. "copy" of hard-links) in the destination.
This contributes to limiting the size of target/.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Herve Codina <herve.codina@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
(cherry picked from commit 23edf9837c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 21d52e52d8 (package/pkg-utils.mk: break hardlinks in global
{TARGET, HOST}_DIR on per-package build) stopped hardlink the source and
destination when rsyncing per-package directory, on the rationale that
modifying files in-place after the rsync would also modify the original
file, and that break foo-rebuild and can cause issues with post-build
scripts.
However, what 21d52e52d8 did not envision, is that copying instead of
hard-linking has two nasty side effects:
- the size increase for the build directory increase with the number
of packages and with the depth of th dependency chains for those
packages: a (relatively small) build that was previously totalling
~13GiB in output/, now totals north of 122GiB, an almost 10-time
increase;
- the build time increases, as it takes more time to read+write files
than it takes to create a new link to a file; the same build saw an
increase of build time from 5min 10s to 7min 30s, a 45% increase.
These regressions are both serious, so revert the change; we'll come up
with a stopgap measure in follow-up commits.
This reverts commit 21d52e52d8.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Herve Codina <herve.codina@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
(cherry picked from commit 8f1487d6fa)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The relocate-sdk.sh script does not work correctly when
BR2_PER_PACKAGE_DIRECTORIES is enabled. relocate-sdk.sh expects
everything to point at $HOST_DIR, but each package will be pointing at
its $(O)/per-package/*/host.
Use the same command for scrubing host paths during the build, to scrub
to the final host directory location.
Signed-off-by: Brandon Maier <Brandon.Maier@collins.com>
Acked-by: Charles Hardin <ckhardin@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 25e60fbe1c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
# used to fix ../../../../libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
ifeq($(BR2_ENABLE_DEBUG),y)
GCC_COMMON_TARGET_CFLAGS+= -Wno-error
endif
# Make sure libgcc & libstdc++ always get built with -matomic on ARC700
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Peter Korsgaard