Reported via IRC in #buildroot connmanctl segfaults randomly
on startup and keyboard input is not echoed back.
Could be reproduced with Raspberry PI4 (32 Bit) defconfig and glibc
based userland.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
https://github.com/Netatalk/netatalk/blob/netatalk-4-4-3/NEWS.md
The bump from 4.4.2 to 4.4.3 fixes these CVEs:
CVE-2026-44047, CVE-2026-44048, CVE-2026-44049, CVE-2026-44050,
CVE-2026-44051, CVE-2026-44052, CVE-2026-44054, CVE-2026-44055,
CVE-2026-44057, CVE-2026-44060, CVE-2026-44062, CVE-2026-44064,
CVE-2026-44066, CVE-2026-44068, CVE-2026-44076, CVE-2026-45354,
CVE-2026-45355, CVE-2026-45356, CVE-2026-45698, CVE-2026-45699
Version 3.2.8 fixes these CVEs:
CVE-2024-1544, CVE-2024-5288, CVE-2024-5991, CVE-2024-5814
Version 3.2.1 fixes these CVEs:
CVE-2024-38439, CVE-2024-38440, CVE-2024-38441
Updated project URL in Config.in help text.
Removed md5 tarball hash and added sha256 and sha512 tarball hashes
provided by upstream.
Updated license hash due to upstream commits:
06e427ea02934495d9e1
Switched _SITE to https.
Version 4.0.0 removed autotools and kept only meson as build system.
Reworked dependencies, sorted NETATALK_DEPENDENCIES.
Iniparser was added as mandatory dependency in 4.2.0.
Added optional dependencies to cracklib and openldap.
Disabled usage of libiconv for uClibc due to different definitions of
iconv_t (uClibc: typedef long vs. glibc: typedef void) which causes
a build error after the switch to meson.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
When running 'make show-info-all' without a '.config', it is possible to
trigger this script without passing a version number.
The 'show-info-all' target is special because it forces the reading of
all packages without requiring a .config, so BR2_HOST_CMAKE_AT_LEAST is
unset and the script is called as:
check-host-cmake.sh cmake cmake3
Without validation, the integer comparisons below would produce errors
like:
check-host-cmake.sh: line 37: [: cmake: integer expected
It's possible to trigger this by adding the following file somewhere in
you path:
cat >/bin/cmake3 <<EOF
echo "cmake version 4.3.3 CMake suite maintained and supported by Kitware (kitware.com/cmake)."
EOF
make show-info-all
The same issue can also occur with pkg-stats.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The maintenance and testing workflow sometimes requires to output a
list of every existing package on Buildroot:
- Generating an SBOM of the whole Buildroot tree, e.g. `for
security.buildroot.org
- List every source for every package, e.g. for sources.buildroot.net
The previous solution relied on `make allyesconfig` but always ran into
conflicts that needed manual resolution. Also some packages would not be
present because they are architecture dependent.
To avoid having to manually modify the 'show-info' command this commit
adds the 'show-info-all' command. It accesses the PACKAGES_ALL variable
with all the packages present in Buildroot independently of the
architecture or any config entries.
It forces the `BR2_HAVE_DOT_CONFIG` variable to be set to force the
reading of the package mk files.
It is also added to noconfig_targets, to avoid the .config influencing
the output of show-info-all.
Note that this is not yet a complete solution - it doesn't take into
account the multiple versions that are possible for some packages like
GCC. Also for e.g. linux or uboot the version is empty and the URL is
invalid.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Arnout: refactor with existing show-info]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
https://www.busybox.net/news.html
Removed patches which are included in this release, renumbered remaining
patches.
Patch 0006 was removed because its fix is included in upstream commit
9a8796436b
which also adds a new Kconfig option, disabled by default, to fix
CVE-2023-39810. To improve security we enable this option by default.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since Buildroot commit 0e3ddc9dc8,
linux hash files are split between pre- and post-6.17.
Since that commit, the script that automatically updates kernel
versions in Buildroot was broken, as it assumed only a single linux
hash file at a static location. Update the script to find all relevant
files, even if a new split occurs in the future.
In addition, this patch carries additional minor changes:
- Fix some minor shellcheck issues found with a newer shellcheck version
than in the container (quoting, test -a -> -e)
- Move from wget to curl, as I had some issue on my home connection
with the former (possibly ipv6 related or something)
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
uutils install 0.8.0 as used in Ubuntu 26.04 has a bug in the install
applet, breaking a number of packages:
https://github.com/uutils/coreutils/pull/11505https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2151454
The fix has been merged upstream but not yet released or packaged in Ubuntu,
so detect and reject the buggy version and explain how to change to the
coreutils version. Once fixed the version output will hopefully change.
For simplicity, only check for the exact 0.8.0 version string. Hopefully
when it is fixed in Ubuntu, they also update the version string. Note
that earlier versions of uutils have the same issue of course, but those
versions were never the default "install" on Ubuntu (or anywhere else).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This reverts commit 6b56e0b4f0.
commit 6b56e0b4f0 ("linux: disable -Werror") said we needed to disable
CONFIG_WERROR in the kernel because it failed to build the esp-hosted
kernel module. This was very much the hammer approach because a) it'd be
better to fix the warnings in the kernel module or b) disable the
kernel's CONFIG_WERROR *only* if esp-hosted is to be built, via the
ESP_HOSTED_LINUX_CONFIG_FIXUPS variable in
package/esp-hosted/esp-hosted.mk.
This is a simple revert without making any change to any kernel module
(including esp-hosted) because all upstream Buildroot defconfigs with a
kernel module enabled build fine today (albeit with warnings). The two
defconfigs that were pointed at by the now-reverted commit all have been
(updated for and) run on master without failing the build.
Suggested-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
As of today, the Buildroot project is now 100% compliant with
OpenSSF Best Practices self-assesment. Let's therefore advertise this
in our SECURITY.md and in the footer of the website.
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Detected by Gitlab pipeline when testing the other build fixes in this
series. Autobuilders did not detect the problem due to the build error
with glibc 2.43.
https://gitlab.com/bkuhls/buildroot/-/jobs/14571737512
/builds/bkuhls/buildroot/br-test-pkg/bootlin-powerpc-e500mc-uclibc/build/odhcp6c-f19dd37fb467c9cf10cad57aefa0d048312d7dfd/src/dhcpv6.c:1395:58:
error: comparison of integer expressions of different signedness:
‘uint32_t’ {aka ‘unsigned int’} and ‘int’ [-Werror=sign-compare]
1395 | if (ia_hdr->iaid != htonl(ifindex) && otype == DHCPV6_OPT_IA_NA)
https://gitlab.com/bkuhls/buildroot/-/jobs/14571737510
/builds/bkuhls/buildroot/br-test-pkg/bootlin-openrisc-uclibc/build/odhcp6c-f19dd37fb467c9cf10cad57aefa0d048312d7dfd/src/dhcpv6.c:1395:58:
error: comparison of integer expressions of different signedness:
‘uint32_t’ {aka ‘unsigned int’} and ‘int’ [-Werror=sign-compare]
https://gitlab.com/bkuhls/buildroot/-/jobs/14571737505
/builds/bkuhls/buildroot/br-test-pkg/bootlin-m68k-68040-uclibc/build/odhcp6c-f19dd37fb467c9cf10cad57aefa0d048312d7dfd/src/dhcpv6.c:1395:58:
error: comparison of integer expressions of different signedness:
‘uint32_t’ {aka ‘unsigned int’} and ‘int’ [-Werror=sign-compare]
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Fixes build errors seen with Gitlab pipeline and this defconfig:
support/config-fragments/autobuild/bootlin-aarch64-glibc-old.config
https://gitlab.com/bkuhls/buildroot/-/jobs/14570080455
aarch64-linux-gcc.br_real: error: unrecognized command line option
‘-Wimplicit-fallthrough=5’; did you mean ‘-Wno-fallthrough’?
aarch64-linux-gcc.br_real: error: unrecognized command line option
‘-Wshadow=local’; did you mean ‘-Wshadow-ivar’?
Removing all the unrecognized command line options from CMakeLists.txt
showed more build errors during compile:
output/build/odhcp6c-24485bb4b35ab84c17c2e87bd561d026d4c15c00/src/odhcp6c.h:47:46:
error: expected ‘)’ before ‘__VA_OPT__’
#define error(fmt, ...) __iflog(LOG_ERR, fmt __VA_OPT__(, ) __VA_ARGS__)
Another pipeline with gcc 9 showed other errors:
https://gitlab.com/bkuhls/buildroot/-/jobs/14570080479
/builds/bkuhls/buildroot/br-test-pkg/br-arm-basic/build/odhcp6c-24485bb4b35ab84c17c2e87bd561d026d4c15c00/src/dhcpv6.c:1126:4:
error: a label can only be part of a statement and a declaration is not a statement
1126 | struct dhcpv6_auth *r = (void*)&odata[-DHCPV6_OPT_HDR_SIZE];
so we raise the minimum gcc version to 10.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit ce5d173571 removed
0001-fix-build-with-gcc-14.patch which the version bump to 1.4.3.
The patch originally not only fixed share/utf8.c but also
ogginfo/codec_skeleton.c. Upstream only applied the fix for
ogginfo/codec_skeleton.c:
68c5a33685
so the build still fails:
utf8.c: In function 'convert_buffer':
utf8.c:271:9: error: implicit declaration of function 'charset_convert'
[-Wimplicit-function-declaration]
271 | ret = charset_convert(fromcode, tocode, from, fromlen, to, tolen);
Added upstream commit to fix the problem.
Fixes:
https://autobuild.buildroot.net/results/135/13520e3cbf6b6d169985f4d1378c2a1baab852e0/
The build error can be reproduced by this minimal defconfig:
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PACKAGE_VORBIS_TOOLS=y
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit e1050a3a50 bumped the
package which includes upstream commit
https://git.openwrt.org/?p=project/ustream-ssl.git;a=commit;h=956fba242ac0a4bcfe3db103d4d1f41545c924fb
that adds the usage of SSL_trace causing a build error when OpenSSL was
built without ssl-trace support:
/home/autobuild/autobuild/instance-10/output-1/build/ustream-ssl-5a81c108d20e24724ed847cc4be033f2a74e6635/ustream-openssl.c:
In function '__ustream_ssl_set_debug':
/home/autobuild/autobuild/instance-10/output-1/build/ustream-ssl-5a81c108d20e24724ed847cc4be033f2a74e6635/ustream-openssl.c:490:44:
error: 'SSL_trace' undeclared (first use in this function); did you mean 'SSL_write'?
490 | SSL_CTX_set_msg_callback(ctx->ssl, SSL_trace);
Fixes:
https://autobuild.buildroot.net/results/17c/17c88282c32f2edfa0991e0e10cb45013c947be9/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot commit c7a1b73f17 removed
patches 0001-ecore_evas-engines-drm-meson.build-use-gl_deps-as-en.patch
and 0002-ecore_evas-engines-drm-meson.build-fix-gl_drm-includ.patch.
This defconfig
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_EFL=y
BR2_PACKAGE_EFL_DRM=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_LUAJIT=y
is broken now during configure stage
output/build/efl-1.28.1/src/modules/ecore_evas/engines/drm/meson.build:6:18:
ERROR: Unknown variable "engine_gl_drm".
which is fixed by former patch 0001.
Later a build error occurs which is fixed by former patch 0002.
The error was not yet caught by the autobuilders.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The tags specified by a job are ANDed, not ORed. So with
.runner-small:
tags:
- buildroot-runner
- saas-linux-small-amd64
the job will only run on a runner that has _both_ tags - so only on the
buildroot runner. That makes it pretty pointless.
Remove all the buildroot-runner tags, except in the
.runner-buildroot-runner-only template.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Currently the weekly pipelines are triggered from a cron job on the
Buildroot server, so generate-gitlab-ci-yml filters on the "trigger"
source. However, we'd like to schedule it on gitlab itself, which makes
managing it easier.
We could filter on "schedule" in addition to "trigger", but there's not
really a reason to. We can simply rely on the BR_SCHEDULE_JOBS variable
- if it is set, we use its information.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
We have our own GitLab-CI runner, but with only one we can't run many
jobs in parallel so it takes a very long time before all the tests have
completed. In addition, if that runner goes down, we have nothing at
all.
GitLab offers the following machine types for hosted runners on Linux
x86-64 [1]. The default is the "small" runner. Using a larger runner
increases the "Cost factor" [2]:
Runner Tag vCPUs Memory Storage Cost factor
saas-linux-small-amd64 (default) 2 8 GB 30 GB 1
saas-linux-medium-amd64 4 16 GB 50 GB 2
saas-linux-large-amd64 (Premium and Ultimate only) 8 32 GB 100 GB 3
saas-linux-xlarge-amd64 (Premium and Ultimate only) 16 64 GB 200 GB 6
saas-linux-2xlarge-amd64 (Premium and Ultimate only) 32 128 GB 200 GB 12
Compute minutes consumed by a job is calculated by:
Job duration / 60 * Cost factor
(Job duration: The time, in seconds, that a job took to run, not
including time spent in the created or pending statuses.)
Thanks to the GitLab OSS program [3], Buildroot benefits from a free
Ultimate subscription and can use GitLab shared runners tagged with
saas-linux-{large, xlarge, 2xlarge}-amd64. In addition, we receive
50,000 free runner minutes per month.
For opensource projects, the Cost factor is reduced by 0,5 (1 minute per
2 minutes of job time).
In order to use one of those tags in Buildroot GitLab-CI jobs, we have
to classify all tests by resource requirement, to make sure the job
doesn't fail because it times out or has insufficient memory or disk
space. We also don't want to use the largest runner for everything
because that would spend the minutes very quickly while the resources
aren't used efficiently (mostly serialized).
First we introduce some new templates used to add the corresponding
runner tag to a runtime test job (reusing the GitLab terminology).
.runner-{small,medium,large,xlarge,2xlarge}
Most of our tests are fast (checkpackage, test_external_bootlin...), so
saas-linux-small-amd64 runner tag is enough. Default to this tag if
nothing else is specified.
Add a comment next to the test class to provide the runner tag.
This runner tag is retrieved when generating the
generated-gitlab-ci.yml file used to create the child pipeline where
the runtime test jobs are executed.
We use the list of runtime tests returned by node2:
"tests.boot.test_edk2.TestEdk2.test_run"
We convert each element of this list to get the path to the test source
file and the name of the test:
"support/testing/tests/boot/test_edk2.py"
TestEdk2
With that, we can grep into the test source file to retrieve the runner
tag placed one line above the test class:
# GitLab-runner: large
class TestEdk2(infra.basetest.BRTest):
Once the runner tag is retrieved, it's used to use the corresponding
runner template to the runtime test job:
tests.boot.test_edk2.TestEdk2.test_run: { extends: [ .runtime_test_base, .runner-large ]}
GitLab runners hosted by the Buildroot project should be able to run any
jobs, so a specific runner tag "buildroot-runner" is used to allow
running a job on such runners. The "buildroot-runner" tag is used in
addition to GitLab ones to run a job on the Buildroot runner or on a
shared GitLab-CI runner.
If a test can't be executed by any shared GitLab-CI runners, we have
to use a runner owned by the Buildroot project. In this case we have
to use a specific template ".runner-buildroot-runner-only". There is no
such runtime test at the moment.
The proposed classification is based on a previous pipeline analysis
[5]:
- Tests lasting more than 3 hours will use 2xlarge runners.
- Tests lasting more than 2 hours will use xlarge runners.
- Tests lasting more than 1 hours will use large runners.
- Tests building a kernel or a toolchain will use medium runners.
- All other tests will use small runners when possible.
CI minute cost estimate:
tests.package.test_clang.TestClangCompilerRT.test_run lasts 4h25 on the
Buildroot runner. If we this duration for 2xlarge runners, the CI
minute consumed would be:
(265 / 60) * 12 * 0.5 = 26,5
With 6 jobs using a 2xlarge runners we used ~160 CI minutes.
tests.package.test_kmscube.TestKmsCube.test_run list 2h04 on the
Buildroot runner. If we this duration for xlarge runners, the CI
minute consumed would be:
(124 / 60) * 6 * 0.5 = 6,2
With 4 jobs using a xlarge runners we used ~37 CI minutes.
tests.package.test_weston.TestWeston.test_run last 1h15 on th
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(75 / 60) * 3 * 0.5 = 1.87
With 28 jobs using a large runners we used ~53 CI minutes.
tests.package.test_gstreamer1.TestGstreamer1.test_run last 46min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(46 / 60) * 2 * 0.5 = 0.76
With 31 jobs using a medium runners we used ~24 CI minutes.
tests.package.test_python.TestPython3Py.test_run last 13min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(13 / 60) * 1 * 0.5 = 0.1
With 691 jobs using a medium runners we used ~69 CI minutes.
In total, one pipeline for the runtime tests cost ~350 CI minutes.
We run such pipeline once a week (on Monday), one for each Buildroot
releases every 3 month, one for each stable and LTS release per month,
and one for each release candidate (3).
Worst case (realse month):
(4 weeks + 1 release + 1 stable + 1 LTS + 3 release candidate) * 350 CI
minutes: 3500 CI minutes / 50000.
So we should be able to run our pipeline without exhausting our CI
minutes credit.
[1] https://docs.gitlab.com/ci/runners/hosted_runners/linux/#machine-types-available-for-linux---x86-64
[2] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factorshttps://docs.gitlab.com/ci/pipelines/compute_minutes/#compute-usage-calculationhttps://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[3] https://gitlab.com/buildroot.org/gitlab-oss
[4] https://docs.gitlab.com/ci/runners/hosted_runners/#gitlabcom-hosted-runner-workflow
[5] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2416603721
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Arnout:
- simplify parsing of test_file and test_name;
- match the entire test_name instead of substring;
- assume "small" by default;
- remove the "small" tags;
- use "gitlab-runner" instead of "Gitlab-runner".
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
For host packages, this commit adds the same `ignore_cves` list as their
target counterpart and make it available from the `show-info` output.
When generating a CycloneDX SBOM with `make show-info-all |
utils/generate-cyclonedx` and running an analysis over it with
`support/script/cve-check`, multiple vulnerabilities
entries would be created with different analysis for packages that have
both a host and target variant that include IGNORE_CVES entries.
This is the case for the grub2 package that include ignored
vulnerabilities that patch both the target and host package but aren't
declared as ignored for the host package. This resulted in
vulnerabilities marked as 'exploitable' for the host variant while it
is patched.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Before this commit, only one entry per vulnerability ID was added to the
output. In CycloneDX, if you need to provide different analyses for
different affected components with the same vulnerability ID, you must
create multiple entries with the same ID.
When running `cve-check` with the `--include-resolved` argument, the
analysis of some vulnerabilities would get overwritten, which led to
undefined analysis results.
This is especially true when running the analysis on multiple components
with the same name but different versions. For instance, if the input
SBOM includes both the `gnupg` and `gnupg2` packages, CVE-2025-68973
could be included. This CVE might be exploitable for the `gnupg` package
but resolved for `gnupg2`. Therefore, a single analysis entry cannot
cover both cases.
This commit fixes the logic for adding vulnerabilities to the output
SBOM. A vulnerability is now added as a new entry if:
1. A vulnerability with the same ID doesn't exist yet.
2. The affect of the new vulnerability is not the same as the one
already present.
For the CVE-2025-68973 example this would result in the following
output:
```json
[
{
"id": "CVE-2025-68973",
"analysis": {
"state": "exploitable"
}
"affects": [
{"ref": "gnupg"}
]
},
{
"id": "CVE-2025-68973",
"analysis": {
"state": "resolved"
}
"affects": [
{"ref": "gnupg2"}
]
}
]
```
45 vulnerabilities were concerned by this bug over the Buildroot tree.
Co-Authored-By: Tim Soubry <tim.soubry@mind.be>
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
