The AUTORECONF variable was introduced in commit [1] with reference to
the patches that modified the m4 and Makefile.am files.
The commit [2] removed the last such patch but left the reference to the
patch and the AUTORECONF variable.
Later, commit [3] updated the mirror to the gitlab URL that no longer
bundle a pre-generated `configure` file, making the execution of
AUTORECONF necessary anyway.
This patch removes the obsolete reference to the patch 0001 removed in
[2] to avoid ambiguity with the new patch 0001 introduced in commit [4].
[1] 01a82c1401 package/libapparmor: enable python bindings
[2] 27cd0b5033 package/apparmor: bump to version 3.0.4
[3] 5649202ddc package/libapparmor: bump to version 3.1.7
[4] 2640f5dcd0 package/libapparmor: fix build w/ musl
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Peter: add a comment explaining why]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 50cac72f73)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since the package bump to v10.05.0 the xlib libraries detection has been
improved to error missing x libraries (see [2]).
The following error is happening on the autobuilder when building
ghostscript with xlib_libX11:
```
checking for XOpenDisplay in -lX11... yes
checking for XdbeQueryExtension in -lXext... yes
checking for XtAppCreateShell in -lXt... no
configure: error: X11 libraries (libX11, libXt, libXext) not available, either install them, or rerun configure with "--without-x"
make: *** [package/pkg-generic.mk:263: /home/buildroot/instance-0/output-1/build/ghostscript-10.05.1/.stamp_configured] Error 1
```
This error can be reproduced with the following config:
```
cat <<EOF >.config
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XLIB_LIBX11=y
BR2_PACKAGE_GHOSTSCRIPT=y
EOF
make olddefconfig
make
```
This patch fixes the xlib dependencies of the ghostscript package to
correctly build with X support:
- The 'XtAppCreateShell' function is provided by the package
'xlib_libXt'.
- The 'XdbeQueryExtension' function is provided by the package
'xlib_libXext'.
They both select the 'xlib_libX11' package.
[1] 9abf662cfd package/ghostscript: security bump to version 10.05.0
[2] 37eede31e1
Fixes: https://autobuild.buildroot.org/results/45d/45d0414f341feb2354478b145396fe137f9cc6a6
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 9adc8a0570)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Add a patch fixing cmake 4 compatibility, found in upstream pull
request #349. The patch has been modified to apply on version 0.6.1
instead of the current upstream HEAD.
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 76099d285e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since the commit [1] the janet package started failing on the
autobuilder when using musl libc:
```
[50/56] Compiling C object libjanet.so.1.35.2.p/meson-generated_.._janet.c.o
FAILED: libjanet.so.1.35.2.p/meson-generated_.._janet.c.o
/workdir/instance-0/output-1/host/bin/armeb-buildroot-linux-musleabi-gcc -Ilibjanet.so.1.35.2.p -I. -I.. -I../src/include -fdiagnostics-color=always -Wall -Winvalid-pch -std=c99 -O3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -g3 -fPIC -pthread -fvisibility=hidden -MD -MQ libjanet.so.1.35.2.p/meson-generated_.._janet.c.o -MF libjanet.so.1.35.2.p/meson-generated_.._janet.c.o.d -o libjanet.so.1.35.2.p/meson-generated_.._janet.c.o -c janet.c
src/core/util.c: In function 'janet_strerror':
src/core/util.c:977:12: error: returning 'int' from a function with return type 'const char *' makes pointer from integer without a cast [-Wint-conversion]
[51/56] Compiling C object janet-native.p/meson-generated_.._janet.c.o
```
The commit [2] introduced the issue in v1.35.0, the `strerror` function
has different definition on glibc compared to musl. This issue has been
addressed in commit [3]. This patch add the upstream commit [3].
[1] 31212c4c58 package/janet: bump to version 1.35.2
[2] 8334504f4e
[3] a5d6b22838
Fixes: https://autobuild.buildroot.org/results/ff1/ff1d6063c1a79d17cfa9910cca824e704a4a0c67/build-end.log
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 92a244ba8b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since tuxfamily.org is slowly fading away, update my mail address
to something that is more future-proof.
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit b7f7bd44f9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
On the autobuilder the following build error would appear for the
libzenoh-pico package when the option BR2_ENABLE_RUNTIME_DEBUG is
enabled:
```
[ 1%] Building C object CMakeFiles/zenohpico_shared.dir/src/api/encoding.c.o
In function '_z_encoding_convert_into_string',
inlined from 'z_encoding_to_string' at /workdir/instance-0/output-1/build/libzenoh-pico-1.2.1/src/api/encoding.c:261:5:
/workdir/instance-0/output-1/build/libzenoh-pico-1.2.1/src/api/encoding.c:203:15: error: 'strncat' output truncated before terminating nul copying 1 byte from a string of the same length [-Werror=stringop-truncation]
203 | (void)strncat(value, &sep, 1);
| ^~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
This error can be reproduced with:
```
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LIBZENOH_PICO=y
BR2_ENABLE_RUNTIME_DEBUG=y
EOF
make olddefconfig
make libzenoh-pico
```
This patch include the upstream commit [1] that fixes this issue.
[1] 60e635cbb1
Fixes: https://autobuild.buildroot.org/results/0c4/0c4644b17646d3ec482f0a4cf02d6fde19db2c99
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit ec12da7384)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When the package was introduced in [1], it lacked a kconfig comment
indicating that it requires a toolchain with thread support.
[1] ea1cc1af55 package/cpuinfo: new package
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 38107ec40c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
On autobuilder config with BR2_TOOLCHAIN_HAS_THREADS not set the
following error happens when building the pthreadpool package:
```
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at /home/buildroot/instance-0/output-1/host/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/home/buildroot/instance-0/output-1/host/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
/home/buildroot/instance-0/output-1/host/share/cmake-3.31/Modules/FindThreads.cmake:226 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:143 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
```
This can be reproduced with:
```
cat >.config <<EOF
BR2_armeb=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PTHREADS_NONE=y
BR2_PACKAGE_PTHREADPOOL=y
EOF
make olddefconfig
make pthreadpool
```
Since the introduction of this package in [1], the dependency was not
included. Since this package was part of the tensorflow-lite
dependencies that required thread it was not an issue.
This patch adds BR2_TOOLCHAIN_HAS_THREADS in the dependency to avoid
errors when built as a standalone package.
[1] f2486a6cf9 package/pthreadpool: new package
Fixes: https://autobuild.buildroot.org/results/35a/35aa100d72c6875350ad10c57f028f04052cbf79
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 627af87bda)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The following error occur on the autobuilder for static build using
buildroot toolchain and uclibc:
```
/usr/bin/make -j17 -C /home/buildroot/instance-0/output-1/build/snooze-0.5/ PREFIX=/usr CC=/home/buildroot/instance-0/output-1/host/bin/arc-buildroot-linux-uclibc-gcc CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -static -static"
make[1]: Entering directory '/home/buildroot/instance-0/output-1/build/snooze-0.5'
/home/buildroot/instance-0/output-1/host/bin/arc-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -static -static snooze.c -o snooze
snooze.c:22:10: fatal error: sys/auxv.h: No such file or directory
22 | #include <sys/auxv.h>
| ^~~~~~~~~~~~
compilation terminated.
make[1]: *** [<builtin>: snooze] Error 1
```
This error can be reproduced with:
```
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_STATIC_LIBS=y
BR2_PACKAGE_SNOOZE=y
EOF
make olddefconfig
make snooze
```
The error doesn't occur on external toolchains.
The `#include <sys/auxv.h>` was orinally included in the initial commit
(see [1]) to use the `getauxval` function declaration. This function
usage has since been removed in commit [2].
This patch removes the include that is no longer needed.
[1] 5648088197
[2] 610e6b35ec
Fixes: https://autobuild.buildroot.org/results/aec/aec463f87094a47ee059113f08e8ee3604dcea9b
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Reviewed-by: J. Neuschäfer <j.ne@posteo.net>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit a00151af54)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When building tini with musl libc, the following error occurs dur to
missing declaration of 'basename':
```
/home/buildroot/instance-0/output-1/build/tini-0.19.0/src/tini.c: In function 'print_usage':
/home/buildroot/instance-0/output-1/build/tini-0.19.0/src/tini.c:227:36: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
227 | fprintf(file, "%s (%s)\n", basename(name), TINI_VERSION_STRING);
| ^~~~~~~~
make: *** [package/pkg-generic.mk:273: /home/buildroot/instance-0/output-1/build/tini-0.19.0/.stamp_built] Error 1
make: Leaving directory '/home/buildroot/instance-0/buildroot'
```
This error can be reproduced with:
```
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_TINI=y
EOF
make olddefconfig
make tini
```
This patch adds the upstream commit [1], that fixes this issue by
including `libgen.h`.
[1] 924c4bd602
Fixes: https://autobuild.buildroot.org/results/f0d/f0d10cd25f3b0e2a4af7266f7417b339ea5d242a
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 064f7592d3)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The php-pecl-dbus encouters two build issues in both buildroot 2025.02.x
and master branch, both related to PHP8 and GCC14:
/home/alexis/src/buildroot/php/build/php-pecl-dbus-b147624d480c3353e6c700e9a2d0c6f14d853941/dbus.c:465:56:
error: assignment to ‘zend_object_get_properties_t’ {aka ‘struct
_zend_array * (*)(struct _zend_object *)’} from incompatible pointer
type ‘HashTable * (*)(zval *)’ {aka ‘struct _zend_array * (*)(struct
_zval_str
uct *)’} [-Wincompatible-pointer-types]
465 | dbus_object_handlers_dbus_array.get_properties =
dbus_array_get_properties;
| ^
[...]
The build failure can be reproduced with this minimal defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_PHP=y
BR2_PACKAGE_PHP_PECL_DBUS=y
This build failure is the result of two events/conditions:
- the update to PHP8 has changed the prototype for
zend_object_read_property_t and zend_hash_get_current_key(see [1]).
But at this time, php-dbus just generated a new warning
(-Wincompatible-pointer-types)
- using bootlin bleeding-edge toolchain brings in GCC14, which now turns
this warning into a systematic error (see [2])
Bring the relevant patches to fix this build.
The first patch comes from an already opened PR on the upstream source.
The second patch has been written during the build failure
investigation, and has been sent upstream as well.
Fixes: https://autobuild.buildroot.net/results/e9892bbefa781b403fd3d834b6c48527c8e078ba
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 0ae37b712f)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
All Go packages must depend on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS,
which ensures that we do have a Go compiler available for that target.
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is currently restricted to the
availability of a full host Go compiler bootstrap. However, there are
architectures like AArch64 for which a full bootstrap is not supported.
Thus, currently, on an AArch64 host, we can't build Go packages (for
target or host), because we can't bootstrap a Go compiler.
However, note that a single Go compiler can generate code for all the
architectures supported by Go and for some host architectures, there are
pre-built toolchains available. When host-go-bin was added in commit
7b2a164b74 ("package/go/go-bin: new host-go provider"), the host
dependency was properly accounted for: It is already possible to build
host-go packages with go-bin. However, the fact that a Go compiler, in
addition to its native target, can also generate code for all supported
architectures, was missed at the time.
Thus, we can fix this problem by relaxing the condition under which
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is set to allowing go-bin
along with go-bootstrap. This allows a situation where the host can't
bootstrap, but for which there is a pre-built toolchain to build Go
packages for a supported target.
Signed-off-by: Florian Larysch <fl@n621.de>
Cc: Yann E. MORIN <yann.morin@orange.com>
Cc: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 432cf9be9f)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When a br2-external tree has no defconfig, list-defconfig currently
whines with an error from find:
find: ‘[...]/my-external/configs’: No such file or directory
Fix that by only running find if the directory exists.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 117ccb6cc4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When a br2-external tree description contains an odd number of single
quotes, list-defconfigs will fail with a shell error message:
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
make[1]: *** [Makefile:1243: list-defconfigs] Error 2
Whoever wrote that code will have to write this sentence 100 times
on the blackboard:
Never, ever pass user-provided data in a printf format.
(see commit 49117c1028 (core: support description for br2-external
trees); dang, I knew it... And I should have known better when I wrote
that code, damit...)
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 161d7ded43)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Grout automatically creates a TUN interface at runtime, so the target
kernel must have CONFIG_TUN enabled. Add a fix-up to ensure that option
is selected.
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 37b35546eb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Version 95be71b matches with kernel 6.12.41.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Tested-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
[Fiona: tested on CM4 and Zero 2W, with the RPi bootloader
booting into U-Boot]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 53c0b8c2f2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
When building the libapparmor package with musl the following error
would appear:
```
test_multi.c: In function 'main':
test_multi.c:27:30: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
27 | printf("File: %s\n", basename(argv[1]));
| ^~~~~~~~
test_multi.c:27:24: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'int' [-Wformat=]
27 | printf("File: %s\n", basename(argv[1]));
| ~^ ~~~~~~~~~~~~~~~~~
| | |
| | int
| char *
| %d
make[3]: *** [Makefile:466: test_multi_multi-test_multi.o] Error 1
```
This error can be reproduced with the following:
```
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_LIBAPPARMOR=y
EOF
make olddefconfig
make libapparmor
```
On musl libc the function `basename` is provided by included libgen.h.
This error has been addressed upstream in [1] by re-defining the
function `basename`.
[1] 7fb040bde6
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Peter: drop unrelated AUTORECONF change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2640f5dcd0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fix the following vulnerability:
- CVE-2025-8177
A vulnerability was found in LibTIFF up to 4.7.0. It has been rated as
critical. This issue affects the function setrow of the file
tools/thumbnail.c. The manipulation leads to buffer overflow. An
attack has to be approached locally. The patch is named
e8c9d6c616b19438695fd829e58ae4fde5bfbc22. It is recommended to apply a
patch to fix this issue. This vulnerability only affects products that
are no longer supported by the maintainer.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-8177
- https://gitlab.com/libtiff/libtiff/-/merge_requests/737
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 3db725d71d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fix the following vulnerability:
- CVE-2025-8176
A vulnerability was found in LibTIFF up to 4.7.0. It has been declared
as critical. This vulnerability affects the function get_histogram of
the file tools/tiffmedian.c. The manipulation leads to use after free.
The attack needs to be approached locally. The exploit has been
disclosed to the public and may be used. The patch is identified as
fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a
patch to fix this issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-8176
- https://gitlab.com/libtiff/libtiff/-/merge_requests/727
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b3974df966)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
On my laptop (i5-8365U), running cross-tesseract-ocr in QEMU takes
longer than the default timeout (5s), causing the test to fail:
# time tesseract frame10.png output
Error in pixReadMemTiff: function not present
Error in pixReadMem: tiff: no pix returned
Error in pixaGenerateFontFromString: pix not made
Error in bmfCreate: font pixa not made
Estimating resolution as 157
real 0m 8.17s
user 0m 5.36s
sys 0m 2.79s
So extend the assertRunOk() timeout with ~2x that similar to how it is done
for the gst-launch-1.0 pipeline.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c897f16a98)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This patch corrects the spelling of 'Xilinx' in the help menu for the
qemu package.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit bd5faa8a24)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Back in commit
44a6b7866c ("configs/qemu_sh4*: switch
to initramfs"), the Qemu SuperH defconfigs were switched to initramfs
due to a bug in the Qemu disk emulation.
However, the initramfs solution has an issue: if the initramfs is
slightly too large (like just 6 MB!), the system no longer boots.
Since the disk emulation problem has apparently been resolved in Qemu
10 (according to testing), let's switch back to this.
In addition to essentially reverting
44a6b7866c, we also need to adjust the
kernel configuration so that the kernel takes its command line for the
bootloader (in our case from the Qemu -append option). Otherwise an
hardcoded command line is used, which doesn't mount /dev/sda as the
root filesystem.
This update has been tested on Gitlab CI:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/1968267919
Thanks to Romain Naour for pointing to the initramfs size as being the
issue.
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 5edce69188)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes the following security issues:
GNUTLS-SA-2025-07-08-1 CVE-2025-32989
Severity Medium; Heap read buffer overflow
When an X.509 certificate contains an SCT (signed certificate timestamp)
extension and its length field is malformed, the library could read the memory
buffer past the boundary. The issue was reported in the issue tracker as
<https://gitlab.com/gnutls/gnutls/-/issues/1695>.
------------------------------------------------------------------------------
GNUTLS-SA-2025-07-08-2 CVE-2025-32988
Severity Low; Memory corruption on error path
When any error occurs during exporting a certificate with an otherName in the
SAN (subject alternative name) extension, the library could potentially double
free the ASN.1 structure. The issue was reported in the issue tracker as
<https://gitlab.com/gnutls/gnutls/-/issues/1694>.
------------------------------------------------------------------------------
GNUTLS-SA-2025-07-08-3 CVE-2025-32990
Severity Low; Heap write buffer overflow
When the certtool program is invoked with a template file with a number of
string pairs for a single keyword, a NULL pointer could be written past the
memory boundary. The issue was reported in the issue tracker as
<https://gitlab.com/gnutls/gnutls/-/issues/1696>.
------------------------------------------------------------------------------
GNUTLS-SA-2025-07-08-4 CVE-2025-6395
Severity Medium; Denial of service
When a TLS 1.3 handshake involves a Hello Retry Request and the second
Client Hello omits the PSK which was present in the first Client Hello,
the GnuTLS server can dereference a NULL pointer. The issue was reported
in the issue tracker as <https://gitlab.com/gnutls/gnutls/-/issues/1718>.
https://lists.gnupg.org/pipermail/gnutls-help/2025-July/004883.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 16d4159d44)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Add options to customize the project name and version in the generated SBOM
metadata and set buildroot generate-cyclonedx as a tool in the metadata
section.
Signed-off-by: Fabien Lehoussel <fabien.lehoussel@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 9cbbc47762)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The ecvt(), fcvt(), and gcvt() functions from stdlib.h, used by the SIO
library packaged with the xinetd sources, are masked by _GNU_SOURCE in
musl libc.
Signed-off-by: Aaron Sierra <aaron@bubbl-tek.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2982fac48e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
With gcc bump to version 14.3.0 in [1]. The gcc-bare-metal version
was not aligned to the same version which led to the following error in
the autobuilder:
```
make[1]: Leaving directory '/workdir/instance-0/output-1/build/host-mpc-1.3.1'
ERROR: No hash found for gcc-14.2.0.tar.xz
make: *** [package/pkg-generic.mk:179: /workdir/instance-0/output-1/build/host-gcc-bare-metal-14.2.0/.stamp_downloaded] Error 1
```
This patch align gcc-bare-metal with the version of gcc 14.
[1] 1e8c1e0ef0 package/gcc: update to 14.3.0
Fixes: https://autobuild.buildroot.org/results/3a2/3a228e885cb04e0c91eee470f9622e0e44eec3d7
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
(cherry picked from commit 176fed6cc0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
This reverts commit ab7297f3c1.
It was mistakenly applied but the error described doesn't apply on the
LTS branch.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
(cherry picked from commit e69822b2dc)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The CVE-2025-3277 as been marked as a duplicate of CVE-2025-29087 by the
debian security tracker [1].
The CVE-2025-29087 has already been fixed in commit [2] so this patch
adds CVE-2025-3277 to the ignored CVEs.
[1] https://security-tracker.debian.org/tracker/CVE-2025-3277
[2] 835b5659ea package/sqlite: add patch to fix CVE-2025-29087
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 014174f00d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
For change log since 3.5.0, see:
https://github.com/DMTF/libspdm/releases
Following the upgrade of libopenssl to version 3.5.0 [1], the build
process for libspdm encountered issues due to the new openssl API.
It requires some modifications in the asn1.h file of libspdm.
This build error was addressed by a specific commit [2] in libspdm.
As Buildroot 2025.02 isn't impacted, this commit bumps libspdm to the
latest libspdm version to fix the build error.
This commit also updates the license hash, after a year update in:
e8a35c8d0d
[1]: 9868ca6ec9
[2]: 88797f83da
Fixes:
https://autobuild.buildroot.org/results/87b8805975ef132a58c40e622e2e023199f6ee2a/
Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
[Julien:
- add link to change log
- fix LICENSE.md hash
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a01c07f572)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
