>From the changelog:
2018-02-28 0.39
* Fixed a security issue with the form module (tx Orange Tsai)
* Fixed a security issue with the db module (tx Adrián Brav and Orange Tsai)
2016-07-08 0.38
..
* Fixed a potential remote exeution risk in `reparam` (tx Adrián Brav)
License files are still not included on pypi, so continue to use the git
repo. Upstream has unfortunately not tagged 0.39, so use the latest commit
on the 0.39 branch. A request to fix this has been submitted:
https://github.com/webpy/webpy/issues/449
0.39 now uses setuptools, so change the _SETUP_TYPE.
Add hashes for the license files.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ce559162fc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
webpy uses hashlib for session handling, so ensure it is available:
web/session.py: import hashlib
web/session.py: sha1 = hashlib.sha1
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 543b0d50fb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The license information in qt5script was just copied from all the other
qt5 modules, but it is different (and complicated).
- libQt5Script itself contains the third-party JavaScriptCore source.
JavaScriptCore has a number of licenses: BSD-2-Clause, BSD-3-Clause,
LGPL-2.0+, LGPL-2.1+. Since it is all linked together, the end
result will be BSD-3-Clause and LGPL-2.1+.
The different BSD licenses are all slightly different (different
authors, which affects the third clause in particular). Only one
separate license file is provided, so let's use that one.
There is an LGPL-2.0 license file, which is slightly different from
the top-level LICENSE.LGPLv21, so let's add that one as well.
- libQt5Script also contains Qt-specific code which is all licensed
under LGPL-2.1 only. This is covered by the LICENSE.LGPLv21 file.
It merges with the LGPL-2.1+ from JavaScriptCore but limits it to
2.1 only.
- libQt5ScriptTools is a separate libary containing just the script
debugger. It is covered by the usual Qt license:
* LGPL-2.1 or LGPL-3.0 with exception for Qt 5.6;
* LGPL-3.0 or GPL-2.0+ for Qt 5.9 (actually it is GPL-2.0 or GPL-3.0
or any later version approved by the KDE Qt foundation, but let's
keep it simple :-). Note that there is no LICENSE.GPLv2 provided,
only LICENSE.GPLv3. Also, there is an LGPL_EXCEPTION.txt file but
no mention of an exception anywhere in the sources.
Update the license information with all of the above. Also add hashes
for the new license files from JavaScriptCore.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit d9ec8526bb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
From ReleaseNotes156:
"""
This is a bugfix release, but it primarily disables the UDP protocol by
default.
In the last few days reports of UDP amplification attacks utilizing
inesure memcached instances have surfaced. Attackers are able to set
large values into memcached, then send requests via spoofed UDP packets.
Memcached will then send a very large number of very large UDP packets
back in response.
"""
Signed-off-by: Christopher McCrory <chrismcc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f03cf639cf)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Install the motion.config file were the program expects it to be. From
the motion source code:
snprintf(filename, PATH_MAX, "%s/motion/motion.conf", sysconfdir);
Signed-off-by: Christopher McCrory <chrismcc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b773c33bf1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Adds WTF platform support for the 32-bits armv8-a architectures.
Fixes:
In file included from ./config.h:30:0,
from ...
./wtf/Platform.h:323:6: error: #error "Not supported ARM architecture"
# error "Not supported ARM architecture"
^~~~~
from this defconfig:
BR2_arm=y
BR2_cortex_a72=y
BR2_ARM_FPU_VFPV3D16=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_NONE=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_QT5WEBKIT=y
The patch is an adaptation of an upstream fix in version 5.212 of
qtwebkit[1].
Unfortunately, the commit cannot be backported and has to be fixed since
the toolchain does not define __ARM_ARCH_8__ but __ARM_ARCH_8A__.
$ host/bin/arm-buildroot-linux-gnueabihf-g++ -dM -E - < /dev/null | grep ARM_ARCH
#define __ARM_ARCH_ISA_ARM 1
#define __ARM_ARCH_8A__ 1
#define __ARM_ARCH_PROFILE 65
#define __ARM_ARCH_ISA_THUMB 2
#define __ARM_ARCH 8
#define __ARM_ARCH_EXT_IDIV__ 1
[1]: 35655d5f4b/Source/WTF/wtf/Platform.h (L241-L242)
Cc: Arnout Vandecappelle <arnout@mind.be>
Reported-by: Brock Williams <brock@cottonwoodcomputer.com>
Reviewed-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Gaël PORTAY <gael.portay@savoirfairelinux.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit cea7aa873a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In current Buildroot, clashes occur between the variables _NAME and
_BASE_NAME for two packages called foo and foo-base, i.e.
Package foo:
FOO_NAME = foo
FOO_BASE_NAME = foo-1.2.3
Package foo-base:
FOO_BASE_NAME = foo-base
FOO_BASE_BASE_NAME = foo-base-4.5.6
where variable FOO_BASE_NAME is clashing between these two packages.
Specific cases where this clash is already existing are:
- alljoyn-base
- alljoyn-tcl-base
- perl-xml-sax-base
The problem is generic and can occur for a number of variables in Buildroot.
A non-exhaustive list:
<pkg>_BASE and <pkg>_BASE_NAME
<pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME
<pkg>_DIR and <pkg>_DL_DIR
<pkg>_VERSION and <pkg>_DL_VERSION
<pkg>_SOURCE and <pkg>_TARGET_SOURCE
<pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET)
<pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES
<pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES
One solution is to use another separator than '_' to separate the
package name from the rest of the variable name. For example, a double
underscore:
FOO__NAME
FOO__BASE_NAME
FOO_BASE__NAME
FOO_BASE__BASE_NAME
However, making that change for only this case means that the variable
naming is no longer consistent. And making the change for all variables has
a large impact, also on certain user scripts.
For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that
the variables become:
FOO_NAME
FOO_BASENAME
FOO_BASE_NAME
FOO_BASE_BASENAME
For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would
still pose a conflict with a package called 'foo-raw', take the opportunity
to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict
as we have no variable called FOO_RAW.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Sam Voss <sam.voss@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 83d2644b11)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It should be "host gnupg" and not "host-gnupg" to be consistent with
all other Config.in.host options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 083716cdfb)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes#10856
The SSE_GENERIC target fails to build with a "sgemm_kernel.o: No such file
or directory" error. Several upstream bug reports exist for this:
https://github.com/xianyi/OpenBLAS/issues/502https://github.com/xianyi/OpenBLAS/issues/685
In both cases, upstream suggests using a different target definition
instead. E.G. from issue 685:
You may use NORTHWOOD on x86: make TARGET=NORTHWOOD that uses SSE2
instructions. It's very hard to find non-SSE2 x86 CPUs today. For x86-64
use the PRESCOTT target
So drop the SSE_GENERIC target. The only x86_64 variant we support not
covered by a more specific openblas target is the default variant, nocona
and jaguar.
Nocona was a Xeon variant of the P4 "Prescott" architecture, so use the
PRESCOTT openblas target:
https://en.wikipedia.org/wiki/Xeon#Nocona_and_Irwindale
Jaguar is from the Bobcat family, so use the BOBCAT openblas target:
https://en.wikipedia.org/wiki/List_of_AMD_microprocessors#Bobcat_core_architecture_(APU)
[Peter: add Jaguar as pointed out by Arnout]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5e6fa93483)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the OpenCV3 Python support is enabled with Python 3.x, it builds
properly, and the resulting .so file is built for the target
architecture, but its name is wrong:
output/target/usr/lib/python3.6/site-packages/cv2.cpython-36m-x86_64-linux-gnu.so
This prevents Python 3.x from importing the module:
>>> import cv2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'cv2'
In order to fix this, we simply need to pass PKG_PYTHON_DISTUTILS_ENV
in the environment. The Python module then gets named:
output/target/usr/lib/python3.6/site-packages/cv2.cpython-36m-arm-linux-gnueabi.so
And can be imported properly:
>>> import cv2
>>>
This solution was suggested by Arnout Vandecappelle in
https://stackoverflow.com/questions/49059035/buildroot-opencv3-python-package-builds-for-the-wrong-target.
With Python 2.x, the module is named just cv2.so so this problem isn't
visible. However, for consistency, we also pass
PKG_PYTHON_DISTUTILS_ENV when building against Python 2.x, by putting
the OPENCV3_CONF_ENV assignment inside the
BR2_PACKAGE_OPENCV3_LIB_PYTHON condition, but outside the
BR2_PACKAGE_PYTHON3/BR2_PACKAGE_PYTHON condition.
Signed-off-by: Sasha Shyrokov <alexander-shyrokov@idexx.com>
[Thomas: extend the commit log, apply the solution to Python 2.x.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 8ba80282c3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
https://git.buildroot.net/buildroot/commit/?id=266208972192f1e0869f89d7be941de6294a810a
broke imx support in Kodi because previously the G2D libraries were
part of the imx-gpu-viv package:
CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find IMX (missing: G2D_LIBRARY)
Adjusting the Kodi package to use the imx-gpu-g2d as well still does
not provide a working build:
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'void CIMX::Deinitialize()':
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:79:21: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'bool CIMX::UpdateDCIC()':
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:109:19: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:115:21: error: 'DCIC_IOC_START_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_START_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'virtual void CIMX::Process()':
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:125:19: error: 'DCIC_IOC_START_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_START_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:131:19: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope
ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0);
^~~~~~~~~~~~~~~~~~~
Although it might be possible to fix these bugs with something like
#define DCIC_IOC_CONFIG_DCIC _IO('D', 12)
#define DCIC_IOC_START_VSYNC _IO('D', 15)
#define DCIC_IOC_STOP_VSYNC _IO('D', 16)
as done in
https://raw.githubusercontent.com/LibreELEC/LibreELEC.tv/libreelec-7.0/projects/imx6/patches/kodi/imx6-jarvis.patch
we would still try to ride a dead horse. The upcoming Kodi version
18.0-Leia will remove imx support completely, see upstream PR 12990.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com>
[Thomas: keep an explicit -DENABLE_IMX=OFF in CONF_OPTS.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 878716830b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
According to imx-vpu-5.4.37/Makefile, line 6:
INCLUDE_LIST:= IMX27ADS IMX51 IMX53 IMX6Q
imx6s is not supported by the imx-vpu package. Its install target,
guarded by
ifeq ($(PLATFORM), $(findstring $(PLATFORM), $(INCLUDE_LIST)))
does nothing, causing a build error later on in the imx-vpuwrap package
checking for vpu_lib.h... no
configure: error: lib_vpu is required, consider installing imx-lib
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e42a65bdcd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When imake is installed on the host, it tries to include
freetype headers from host, so we must override ac_cv_path_IMAKE
to avoid this.
Extract from config.log:
configure:14803: checking if we should use imake to help
configure:14820: result: yes
configure:14829: checking for xmkmf
configure:14846: found /usr/bin/xmkmf
configure:14857: result: /usr/bin/xmkmf
configure:14920: testing Using /usr/bin/xmkmf ...
configure:15015: testing IMAKE_CFLAGS -I. -I/usr/include/freetype2
Signed-off-by: Valentin Korenblit <valentin.korenblit@smile.fr>
[Thomas: pass ac_cv_path_IMAKE="" as suggested by Romain Naour.]
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 6d0316dc7b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes#10776
The upstream git repo contains a number of fixes for building against newer
kernel versions, so bump the version.
git shortlog eb66d40310c93dc82bc8eac889744c1ed1f01f7b..
Alain Kalker (2):
uprobe: Print the symbol, not the matching pattern
uprobe: Blacklist uretprobes on _start
Aleksa Sarai (2):
runtime: update GFP_WAIT to GFP_RECLAIM
userspace: fix up argument parsing NULL dereference
Alexey Makhalov (1):
Fix building for v4.8 kernel
Azat Khuzhin (12):
Use get_unused_fd_flags(0) instead of get_unused_fd()
Support trace_seq::seq
Ignore separate debug files (*.dwo)
Use trace_seq_has_overflowed()
makefile: split vim plugins installing into separate target
makefile: use DESTDIR for install (allow to change install dir)
makefile: install: create dirs
makefile: use ldflags for linking ktap
makefile: add CPPFLAGS to KTAPC_CFLAGS, to allow change default flags
ignore: exclude /debian
Support compilation for 4.2 (ftrace_events cleanup)
runtime: fix building on 4.3
Jovi Zhangwei (11):
Merge pull request #84 from azat/linux-3.19-fixes-v3
Merge pull request #85 from azat/debian-preparations-v2
Merge pull request #88 from NanXiao/master
Merge pull request #89 from NanXiao/patch-1
Merge pull request #91 from NanXiao/patch-1
Merge pull request #90 from azat/linux-4.2-compilation-fixes
Merge pull request #99 from cyphar/fix-null-deref
Merge pull request #98 from cyphar/fix-gfp-reclaim
Merge pull request #97 from azat/fix-building-4.3-__GFP_RECLAIM
Merge pull request #103 from ackalker/blacklist
Merge pull request #104 from YustasSwamp/master
Nan Xiao (3):
Update tutorial.md
Update Makefile
Fix memory leak issue in main function.
WEI ZHANG (1):
ktap: Change the copyright to Huawei Technologies
While we are at it, also add a hash for the license file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8a612c9ed9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- Fix for inspector DNS rebinding vulnerability (CVE-2018-7160): A malicious
website could use a DNS rebinding attack to trick a web browser to bypass
same-origin-policy checks and allow HTTP connections to localhost or to
hosts on the local network, potentially to an open inspector port as a
debugger, therefore gaining full code execution access. The inspector now
only allows connections that have a browser Host value of localhost or
localhost6.
- Fix for 'path' module regular expression denial of service
(CVE-2018-7158): A regular expression used for parsing POSIX paths could
be used to cause a denial of service if an attacker were able to have a
specially crafted path string passed through one of the impacted 'path'
module functions.
- Reject spaces in HTTP Content-Length header values (CVE-2018-7159): The
Node.js HTTP parser allowed for spaces inside Content-Length header
values. Such values now lead to rejected connections in the same way as
non-numeric values.
While we are at it, also add a hash for the license file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 7f02604553)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages that use libtool really need some love to be able to
disable C++ support.
This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
will want a C++ preprocessor that works on valid input *and* fail on
invalid input.
So, providing 'false' as the C++ compiler will then require that we do
have a working C++ preprocessor. Which is totally counter-productive
since we do not have a C++ compiler to start with...
bd39d11d2e (core/infra: fix build on toolchain without C++) was a
previous attempt at fixing this, by using the host's C++ preprocessor.
However, that is very incorrect (that's my code, I can say so!) because
the set of defines will most probably be different for the host and the
target, thus causing all sorts of trouble. For example, on ARM we'd have
to include different headers for soft-float vs hard-float, which is
decided based on a macro, which is not defined for x86, and thus may
redirect to the wrong (and missing) header.
Instead, we notice that libtool uses the magic value 'no' to decide that
a C++ compiler is not available, in which case it skips the call to
AC_PROG_CXXCPP.
Given that 'no' is not provided by any package in Debian and
derivatives, as well as in Fedora, we can assume that no system will
have an executable called 'no'. Hence, we use that as a magic value to
disable C++ detection altogether.
Fixes: #10846 (again)
Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 4cd1ab1588)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
Constructed ASN.1 types with a recursive definition could exceed the stack
(CVE-2018-0739)
Constructed ASN.1 types with a recursive definition (such as can be found in
PKCS7) could eventually exceed the stack given malicious input with
excessive recursion. This could result in a Denial Of Service attack.
There are no such structures used within SSL/TLS that come from untrusted
sources so this is considered safe.
Incorrect CRYPTO_memcmp on HP-UX PA-RISC (CVE-2018-0733)
Because of an implementation bug the PA-RISC CRYPTO_memcmp function is
effectively reduced to only comparing the least significant bit of each
byte. This allows an attacker to forge messages that would be considered as
authenticated in an amount of tries lower than that guaranteed by the
security claims of the scheme. The module can only be compiled by the HP-UX
assembler, so that only HP-UX PA-RISC targets are affected.
rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
This issue has been reported in a previous OpenSSL security advisory and a
fix was provided for OpenSSL 1.0.2. Due to the low severity no fix was
released at that time for OpenSSL 1.1.0. The fix is now available in
OpenSSL 1.1.0h.
There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this
defect would be very difficult to perform and are not believed likely.
Attacks against DH1024 are considered just feasible, because most of the
work necessary to deduce information about a private key may be performed
offline. The amount of resources required for such an attack would be
significant. However, for an attack on TLS to be meaningful, the server
would have to share the DH1024 private key among multiple clients, which is
no longer an option since CVE-2016-0701.
This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).
For more details, see https://www.openssl.org/news/secadv/20180327.txt
The copyright year changed in LICENSE, so adjust the hash to match.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6938c219d8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CVE-2017-12627: dereference of a NULL pointer while processing the path
to the DTD.
xerces 3.2.1 includes this patch. But this version also added
AC_RUN_IFELSE to its configure script, making cross compilation harder.
Switching to cmake is also problematic since the minimum required cmake
version is 3.2.0. The host dependencies check currently allows minimum
cmake version 3.1.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 142c8cc8d5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
systemd meson.build uses values from host /etc/login.defs if
system-uid-max and system-gid-max build options are not explicitly
specified.
Avoid that by setting system-uid-max and system-gid-max to 999 which is
the systemd default if SYSTEM_UID_MAX and SYSTEM_GID_MAX are not set in
/etc/login.defs.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 183d2097ff)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently there is only logic to enable PAM when linux-pam is selected.
However, busybox will fail to build with PAM enabled if the linux-pam
package has not been built before. So we should forcibly disable PAM in
busybox in that case.
Normally this is not an issue since our default busybox config doesn't
have PAM enabled. However, if you enable linux-pam, then save the
busybox config to a custom configuration file, then disable linux-pam
again, and then do a "make clean; make", the build will fail. A more
practical situation where this can occur is when the same custom
busybox config is used in a Buildroot config with and without
linux-pam.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 0876b02366)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following the removal of $(HOST_DIR)/usr, the symbolic link from
$(HOST_DIR)/bin/sam-ba/ to $(HOST_DIR)/opt/sam-ba/sam-ba was broken,
so we fix this.
In addition, sam-ba being prebuilt, it comes in two separates
binaries, one for x86 and the other for x86_64, so we take this into
account as well.
Signed-off-by: Joshua Henderson <joshua.henderson@microchip.com>
[Thomas:
- add spaces around = signs
- rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b3b5608b47)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The following error occures in the udev init script because the kernel config
may optionally not include uevent_helper.
/etc/init.d/S10udev: line 47: can't create /proc/sys/kernel/hotplug: nonexistent directory
Work around this by not trying to access the destination if it's not available.
Signed-off-by: Joshua Henderson <joshua.henderson@microchip.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit cbe725d755)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Prevent out-of-bounds write in codebook decoding.
Codebooks that are not an exact divisor of the partition size are now
truncated to fit within the partition.
Upstream has migrated from subversion to git, so change to git and bump the
version to include the fix for CVE-2018-5146.
While we're at it, also add a hash file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 80266c9505)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
Use after free when server is disconnected during netsplits. Incomplete fix
of CVE-2017-7191. Found by Joseph Bisch. (CWE-416, CWE-825) -
CVE-2018-7054 [2] was assigned to this issue.
Use after free when SASL messages are received in unexpected order. Found
by Joseph Bisch. (CWE-416, CWE-691) - CVE-2018-7053 [3] was assigned to
this issue.
Null pointer dereference when an “empty” nick has been observed by Irssi.
Found by Joseph Bisch. (CWE-476, CWE-475) - CVE-2018-7050 [4] was assigned
to this issue.
When the number of windows exceed the available space, Irssi would crash due
to Null pointer dereference. Found by Joseph Bisch. (CWE-690) -
CVE-2018-7052 [5] was assigned to this issue.
Certain nick names could result in out of bounds access when printing theme
strings. Found by Oss-Fuzz. (CWE-126) - CVE-2018-7051 [6] was assigned to
this issue.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 181ef8a1d0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As part of the build, we run some instrumentation hooks to gather
statistics about the usage of the target/, staging/ and host/
directories, so that we can generate reports for the user, that
shows:
- for each file, what package installed it,
- for each package,the size that it installed.
In so doing, we run a double md5 pass on all files of the affected
directories (before/after installation). These passes were mostly invisible
when we were only scanning target/, but has greatly increased in time now
that we also scan staging/ and host/ (but only in the corresponding _CMDS,
of course).
This md5 was mostly aimed at catching packages that would "cheat" with
mtime/atime/ctime somehow. They can't really cheat on md5, though [0].
Timings however speak for themselves, with this defconfig (slightly
biggish-but-still-manageable build) [1].
host/ 20965 files 1.2GiB
staging/ 4715 files 333MiB
target/ 1801 files 44MiB
All instrumentation steps, using md5: 19min 27s
All instrumentation steps, using mtime: 14min 45s
No instrumentation step at all: 14min 31s
So, using mtime is an almost-5min improvement, i.e. about 25% faster,
while removing all instrumentation steps does not gain that much more...
So, we switch to using mtime, because in the end that's still good-enough
for our use-case: generating some graphs. It is not mission-critical, and
if a graph is slightly off, that's not a biggy. It can anyway be attributed
to a broken package's buildsystem, which should get fixed.
However, we lose the ability to track directories. Non-empty directories
can be tracked back by a bit of scripting, but empty directories are
simply not caught. If we were to also look for directories using mtime,
we would catch parents of installed files:
- /foo/bar/ exists
- a package installs /foo/bar/buz
- mtime of /foo/bar/ is changed to account for the new file in it.
So we do not track directories at all, and we lose empty directories.
The existing tracking was mostly happenstance, with the original
submission and comments not really accounting for a real use-case.
Now, we also change the way we handle symlinks. Previously, we would
hash the file pointed to by the symlink. Now, we only look at the mtime
of the symlink itself, which still detects modifications.
Eventually, this also means that we now no longer need to establish a
list before the install step; we can now simply run after the install
step, finding any files newer than the build stamp.
[0] Yeah, md5 is very weak, but we're not guarding against malicious
attacks, just about careless modifications.
[1] defconfig used for tests:
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_OSMESA=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y
BR2_PACKAGE_SYSTEMD_BACKLIGHT=y
BR2_PACKAGE_SYSTEMD_BINFMT=y
BR2_PACKAGE_SYSTEMD_COREDUMP=y
BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y
BR2_PACKAGE_SYSTEMD_HIBERNATE=y
BR2_PACKAGE_SYSTEMD_IMPORTD=y
BR2_PACKAGE_SYSTEMD_LOCALED=y
BR2_PACKAGE_SYSTEMD_LOGIND=y
BR2_PACKAGE_SYSTEMD_MACHINED=y
BR2_PACKAGE_SYSTEMD_POLKIT=y
BR2_PACKAGE_SYSTEMD_QUOTACHECK=y
BR2_PACKAGE_SYSTEMD_RANDOMSEED=y
BR2_PACKAGE_SYSTEMD_RFKILL=y
BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y
BR2_PACKAGE_SYSTEMD_SYSUSERS=y
BR2_PACKAGE_SYSTEMD_VCONSOLE=y
[Peter: tweak commit message, use find -type l]
Reported-by: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Trent Piepho <tpiepho@impinj.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 7fb6e78254)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2018-5146: Prevent out-of-bounds write in codebook decoding.
Drop 0001-CVE-2017-14633-Don-t-allow-for-more-than-256-channel.patch and
0002-CVE-2017-14632-vorbis_analysis_header_out-Don-t-clea.patch as they are
now upstream, and add a hash for the license file while we're at it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit eca03d6774)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
--disable-rpath was added by m4/lib-link.m4 with autotools based
buildsystem. Now we use meson, we don't have such option anymore.
The autotools eet-eet and eldbus_codegen options are named respectively
eet and eldbus-codegen with meson.
Fixes:
WARNING: Unknown command line options: "eet-eet, eldbus_codegen, rpath"
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b582d137a1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>