Call BUSYBOX_INSTALL_INDIVIDUAL_BINARIES in BUSYBOX_INSTALL_TARGET_CMDS,
not in BUSYBOX_INSTALL_INIT_SYSV. This should have been done in commit
b1e07d6d79 but was somehow lost during the
review/aply process.
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
GCC later than 5.x produce _fdti1.so file with an undefined
symbol str2charp_size due to C99 inline semantics change. So
remove this keyword.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
[yann.morin.1998@free.fr: add upstream status]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Bugfix release, fixing a number of issues:
- Fixed mixing salted and unsalted sessions in the same ESAPI context
- Removed use of VLAs from TPML marshal code
- Added check for object node before calling compute_session_value function
- Fixed auth calculation in Esys_StartAuthSession called with optional parameters
- Fixed compute_encrypted_salt error handling in Esys_StartAuthSession
- Fixed exported symbols map for libtss2-mu
The 2.3.3 tarball accidently contains a Makefile-fuzz-generated.am with
content from a fuzz testing run (rather than an empty file as in earlier
releases), confusing autoreconf together with our
0001-configure-Only-use-CXX-when-fuzzing.patch.
Work around that by adding a post-patch hook to truncate the file. The
issue has been reported upstream and the release logic has been changed to
ensure this does not happen again for future releases:
d163041e3b
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Unlike <PKG>_DEPENDENCIES, <PKG>_PATCH_DEPENDENCIES only guarantees
extract and patch of listed dependencies, not build. Make this subtlety
more explicit in the documentation.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[yann.morin.1998@free.fr: slight fix]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
- Fix potential memory overread when performing an ECDSA signature
operation. The overread only happens with cryptographically low
probability (of the order of 2^-n where n is the bitsize of the
curve) unless the RNG is broken, and could result in information
disclosure or denial of service (application crash or extra resource
consumption).
- To avoid a side channel vulnerability when parsing an RSA private
key, read all the CRT parameters from the DER structure rather than
reconstructing them.
- Update indentation of hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix previous commit[1] which purpose was to fix parallel build. It
didn't work since it assigned $(MAKE1) to LIBSVGTINY_MAKE, but this is a
generic-package and building is done using $(MAKE), then LIBSVGTINY_MAKE
was ignored. Let's substitute instead $(MAKE) with $(MAKE1) in
LIBSVGTINY_BUILD_CMDS.
[1]:
https://git.buildroot.net/buildroot/commit/?id=26d67a2599d6c88facd5178de853fa355244e7c2
Fixes:
http://autobuild.buildroot.net/results/67d/67d341c0cc272323d6e231a20796a6848c21d760/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr:
- use $(MAKE1) in all three step
- move comment out of the define
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 509db3b88a added calls to (parts of) the instrumentation steps.
However, those calls are echoed, unlike the other places where we call
them (in the package infra).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Acked-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
src/gbm/cd6bfad@@gbm at sha/main_backend.c.o: In function `_gbm_create_device':
backend.c:(.text+0x38): undefined reference to `gbm_dri_backend'
backend.c:(.text+0x40): undefined reference to `gbm_dri_backend'
backend.c:(.text+0x74): undefined reference to `gbm_dri_backend'
backend.c:(.text+0x78): undefined reference to `gbm_dri_backend'
collect2: error: ld returned 1 exit status
This issue has been trigged since [1]:
"package/mesa3d: add option to configure gbm support"
Before the patch, the gbm support was autodetected by meson and enabled
only when at least one dri driver was enabled [2].
On the Buildroot side, the gbm support was explicitely enabled only when
BR2_PACKAGE_MESA3D_OPENGL_EGL was set.
We have two cases:
- At least one DRI driver.
- No DRI driver but one Gallium w/ EGL enable (EGL selected or not by the
Gallium driver). In this case the meson build system set with_dri to true
(even if no DRI driver is enabled) to use the builtin:egl_dri2 [3].
The gbm's meson build system seems to handle the case where no dri driver is
enabled [4] but it still use main/backend.c source file [6] that use
gbm_dri_backend [7]. So with_dri2 must always be set.
Probably a missing check in meson.build:
if with_gbm and not with_dri
error('GBM backend needs a dri driver or a gallium driver w/ EGL support.')
endif
Add a dependency on GBM option:
depends on BR2_PACKAGE_MESA3D_DRI_DRIVER \
|| (BR2_PACKAGE_MESA3D_GALLIUM_DRIVER && BR2_PACKAGE_MESA3D_OPENGL_EGL)
Fixes:
http://autobuild.buildroot.net/results/b9b6281983388dc22d929887d653da3db60f1f2c
[1] b6c051acf7
[2] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L348
[3] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L212
[4] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/src/gbm/meson.build#L37
[5] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/src/gbm/meson.build#L24
[6] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/src/gbm/main/backend.c#L38
[7] http://lists.busybox.net/pipermail/buildroot/2020-February/274425.html
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[yann.morin.1998@free.fr: fix dependency of comment]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This issue has been trigged since [1]:
"package/mesa3d: add option to configure gbm support"
Before the patch, the gbm support was autodetected by meson and enabled
only when at least one dri driver was enabled [2].
On the Buildroot side, the gbm support was explicitely enabled only when
BR2_PACKAGE_MESA3D_OPENGL_EGL was set.
Now, the gbm support is explicitely disabled but the meson build system
check if at least one option OpenGL GLX or OpenGL EGL or GBM or
OSMesa (classic) library is enabled [3].
The previous behavious was to enable GBM when GLX, EGL and OSMesa are
disabled. So select GBM symbol for this case.
Fixes:
http://autobuild.buildroot.net/results/a14f329560f8022f7ba8ec43ad8eed84e005d226
[1] b6c051acf7
[2] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L348
[3] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L449
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We don't provide a configuration file, so disable radvd by default.
Update the help message with instructions on how to enable radvd at
build time with systemd.
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds a user-visible option
BR2_TOOLCHAIN_EXTERNAL_HAS_SSP_STRONG, which will allow the user to
indicate if the custom external toolchain does or does not have
SSP_STRONG support. Depending on this, the user will be able to use
(or not) the BR2_SSP_STRONG option.
Checking if what the user said is true or not about this is already
done in toolchain/toolchain-external/pkg-toolchain-external.mk:
$$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION))
If the user selects BR2_SSP_STRONG, this will check if
-fstack-protector-strong is really supported.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This will allow toolchain to indicate if they support
-fstack-protector-strong or not.
Whenever the gcc version is >= 4.9, we always have SSP_STRONG support
if we have SSP support. However, some toolchains older than gcc 4.9
might have backported SSP_STRONG support, which is why we cannot rely
just on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9.
Having this "default" value allows to avoid adding a "select
BR2_TOOLCHAIN_HAS_SSP_STRONG" in the internal toolchain logic plus in
almost external toolchains. But it allows custom external toolchains
that are pre-4.9 to potentially declare that they support strong SSP.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix a check-package error introduce by 6bf74ce3db (package/sdbusplus:
create m4 directory before autoreconf):
package/sdbusplus/sdbusplus.mk:29: expected indent with tabs
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: John Faith <jfaith@impinj.com>
Cc: Michael Walle <michael@walle.cc>
Add a section to the support page for commercial support.
Add Mind, Bootlin and Smile in that section.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The NVD files that are used to build the list of CVEs affecting
Buildroot packages are quite large (a few hundreds MB of json),
and cause the pkg-stats scripts to have a huge memory footprint
(a few GB with Python 2.7).
However, because we only need to iterate on CVE items one by one,
we can process them in streaming (ie decoding one CVE at a time
from the JSON representation). Because the json module from the
python standard library does not support such a mode of operation,
we switch to the third-party package ijson, which is compatible
with both Python 2 and Python3.
To run the script with these modifications, one should install
the ijson python package. This can be done with pip:
`pip install ijson`. On Debian based distributions, this can
also be done with the apt package manager:
`apt install python-ijson`.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
Reviewed-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Tested-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit d255b67972 fixed the handling of
the a package local m4/ directory which might be missing. But this
only works if it is the very first argument. But for this package this
is not possible because we already occupy this with the extra include
directory for autoconf-archive. Bring back the hook to create the m4/
directory to fix this.
Fixes:
http://autobuild.buildroot.net/results/dc907421a343b8523b14fc9a846e0caf7abe630c/
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Remove the lib/ssl/src/deps directory before configuring the package.
Otherwise, during the compilation of the ssl app, it may fails by
looking for logger.hrl in the wrong location (bootstrap/lib/kernel
instead of lib/kernel).
Fixes:
http://autobuild.buildroot.net/results/97606fcd11eaf0822b58a9532c5325601d43eaac/
Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
Tested-by: Frank Vanbever <frank.vanbever@essensium.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Create the staging symlink the same way as the host symlink. This means
using a make dependency rather than recreating it every time.
In coreutils versions below 8.27, re-creation of symbolic links was not
atomic. This means that there is a period in time where the existing link is
removed, before the new one is created. In coreutils 8.27 this was fixed,
see [1]. Note that CentOS 7 ships with coreutils 8.22.
In the following scenario, this is a problem:
- an application is compiled using the sysroot prepared by Buildroot and
links against Xenomai userspace libraries, but its build process is steered
from outside of Buildroot
- to know the correct flags, the application makefile uses the 'xeno-config'
file to request them, and passes DESTDIR=/buildroot/output/staging
- the xeno-config responds with flags based on the path
'/buildroot/output/staging/...'
- while the application build is ongoing, a 'make' happens in Buildroot,
causing the 'staging' symlink to be recreated (even though it already
existed)
- when exactly at this time, the application calls the compiler with -I
flags pointing to output/staging, the build fails with:
-I/buildroot/output/staging/usr/include/xenomai/mercury: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/psos: Error: ^ is not a directory
Failed: ** ^ *
Work around this problem by only creating the staging symlink once, similar
to how the host symlink (if any) is created.
See also commit d0f4f95e39 which changed the
way these symlinks are made. The reasoning in this commit is to move away
from the 'dirs' target.
[1] 376967889e
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The libxml2 package has two patches that fix the two CVEs affecting
libxml2 in version 2.9.10, so let's use LIBXML2_IGNORE_CVES to ensure
these CVEs are no longer reported by pkg-stats.
Cc: Titouan Christophe <titouan.christophe@railnova.eu>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It seems like throughout the series that the CVE pkg-stats support
went through, the support for ignoring CVEs in the per-package
<pkg>_IGNORE_CVES variable was forgotten.
Let's re-introduce this, which is now very simple thanks to the CVE
class, its .identifier() propertly and the .is_cve_ignored() method of
the Package class
Cc: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libupnpp uses pkg-config since version 0.15.1 and
3dc44417e8
so remove unneeded static workaround
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is needed so that building the owfs Python module uses the gcc
from owfs per-package directory, and not the one from the python
per-package directory.
Fixes:
http://autobuild.buildroot.net/results/0d582dda367507991a4c38141db36b0fa8e47e67/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With per-package directory support, Python external modules are
causing a problem: the _sysconfigdata.py module installed by the
Python interpreter contains a number of paths that are relative to the
current package per-package directory, i.e python or python3. For
example:
'BLDSHARED': '/home/thomas/projets/buildroot/output/per-package/python/host/bin/arm-linux-gcc -shared',
'CC': '/home/thomas/projets/buildroot/output/per-package/python/host/bin/arm-linux-gcc',
'CXX': '/home/thomas/projets/buildroot/output/per-package/python/host/bin/arm-linux-g++',
etc.
These paths are problematic, because it means that the wrong compiler
gets used when building external Python modules: instead of using the
compiler from the external Python module per-package host directory,
it uses the one from the 'python' or 'python3' per-package host
directory. Due to this, any native dependency needed by the external
Python module is not found, even though it is properly present in the
current package per-package directory.
Of course, the problem occurs with both target Python modules and host
Python modules.
To fix this, we simply rewrite those paths in _sysconfigdata.py before
building a Python package.
Interestingly, until now, the _sysconfidata.py that was used during
the build was the one from $(TARGET_DIR), which is a bit unusual: it
is more common to use files from $(STAGING_DIR) during the build
process. So this commit changes the PYTHON_PATH and PYTHON3_PATH
variables so that they point to $(STAGING_DIR), which makes the
_sysconfigdata.py fixup in $(STAGING_DIR) effective.
Fixes:
http://autobuild.buildroot.net/results/a24b0555fd4261b50dc3986635c30717d9cbe764/ (python-psycopg2)
http://autobuild.buildroot.net/results/080fa893e1b0e7a8c8a31ac1c98eb8871b97264d/ (python-alsaaudio)
http://autobuild.buildroot.net/results/79bc070f98d6d9d8ef78df12b248cdc7d0e405c3/ (python-lxml)
and many more Python packages that use native code with a native library
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When APR_INCLUDEDIR and APU_INCLUDEDIR point to the same directory,
Apache builds properly. However, with per-package directory support,
they point to different directories, and APU_INCLUDEDIR contains both
the APR headers and the APU headers.
Due to this, the Apache Makefile logic to generate its exports.c file
leads to duplicate definitions, because the APR headers are considered
twice: once from APR_INCLUDEDIR, once from APU_INCLUDEDIR.
We fix this by introducing a patch to the Apache build system.
In addition, apr provides a special libtool script that gets used by
apr-util and apache. apr-util already had a fixup for this, but apache
did not, which was causing the gcc from apr-util per-package
directories be used during the apache build, causing build failures.
To fix this, we adjust this libtool script to point to the correct
tools in apache's per-package directories.
There are no autobuilder failures for this, because Apache needs
apr-util, and apr-util currently fails to build when
BR2_PER_PACKAGE_DIRECTORIES=y.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With per-package directories support enabled, the build of apr-util
fails, for two reasons:
- The rules.mk file is generated by the 'apr' package, and then
copied into the 'apr-util' source directory. This is done by the
'apr-util' build process. Unfortunately, this rules.mk file has a
number of hardcoded paths: to the compiler and to the libtool
script.
Due to this, the compiler from the 'apr' per-package directory gets
used. But this compiler uses the 'apr' package sysroot, which does
not have all the dependencies of the 'apr-util' package, causing
the build to fail because <expat.h> is not found.
- Similarly, the libtool script itself has some hardcoded paths,
which make it use the compiler/linker from the 'apr' per-package
directory, so it does not find the expat library.
We fix both issues by doing the necessary replacement in both rules.mk
and libtool.
Fixes:
http://autobuild.buildroot.net/results/2a67b5d58f79348e20a972125e4797eff5585716/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2019-20388: xmlSchemaPreRun in xmlschemas.c in libxml2 2.9.10
allows an xmlSchemaValidateStream memory leak.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issues (12.15.0):
- CVE-2019-15606: HTTP header values do not have trailing OWS trimmed
- CVE-2019-15605: HTTP request smuggling using malformed Transfer-Encoding
header
- CVE-2019-15604: Remotely trigger an assertion on a TLS server with a
malformed certificate string
For more details, see the advisory:
https://nodejs.org/en/blog/vulnerability/february-2020-security-releases/
On top of this, 12.16.0 brings a number of changes and bugfixes.
Update the license hash for an addition of the (MIT) licensing terms for the
uvwsai module:
+
+- uvwasi, located at deps/uvwasi, is licensed as follows:
+ """
+ MIT License
+
+ Copyright (c) 2019 Colin Ihrig and Contributors
+
+ Permission is hereby granted, free of charge, to any person obtaining a copy
+ of this software and associated documentation files (the "Software"), to deal
+ in the Software without restriction, including without limitation the rights
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ copies of the Software, and to permit persons to whom the Software is
+ furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice shall be included in all
+ copies or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+ """
While we are at it, adjust the white space in the .hash function to match
the new agreements.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
