linux: forcibly disable use of gcc plugins

The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].

To detect the ability to use gcc plugins, the kernel has to check
whether the host gcc is capable enough to build them.

When we call one of the configurator for the Linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
Linux kconfig build [1] [2].

But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.

So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on a machine where gmp is missing in the system, it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).

In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):

    * Restart config...
    * GCC plugins
    GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _

But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):

    * Restart config...
    * GCC plugins
    GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
    Error in reading or end of file.
      Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
    Error in reading or end of file.
      Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
    Error in reading or end of file.
    * Memory initialization
    Initialize kernel stack variables at function entry
    > 1. no automatic initialization (weakest) (INIT_STACK_NONE)
      2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
      3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
      4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
    choice[1-4?]:
    Error in reading or end of file.
    Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
    Error in reading or end of file.
    Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
    Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n

The most obvious and simple solution would be to unconditionally disable
gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
either, because after applying the fixups, we call olddefconfig (or the
likes) with the incapable HOSTCC, so the disabled option would be removed
anyway, and we'd be back to square one.

So, in addition to the above, we also forcibly hack the same call just
before actually building the kernel.

Note that the two are needed: the one in the fixups is needed for those
that have a system that already allows building gcc plugins, and the
second is needed in the other case, where the system does not allow it
but would work with our additional headers and libs in $(O)/host/. The
two ensure there is a very similar experience in the two situations.

Forcibly disabling the use of gcc plugins is not a regression on our
side: it has never been possible to do so so far. We're now making sure
that can't work by accident.

Reported-by: Ganesh <ganesh45in@gmail.com>,
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Michael Walle <michael.walle@kontron.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/qt5/qt5webengine: don't link with libstdc++.a on the host

While cross-compiling, qt5webengine is building a host tool, 'gn', and
by default wants to link it statically with libstdc++, when the tool is
otherwise dynamically linked with other libraries:

    $ ldd 3rdparty/gn/out/Release/gn
        linux-vdso.so.1 (0x00007ffc1c999000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48a3c06000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48a3be4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f48a3a1b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f48a3c53000)

Not all ditributions have the static libraries installed by default; for
example, on Fedora, libstdc++-static is not installed on a fresh system,
leading to build issues:

  [185/185] LINK gn
  FAILED: gn
  /usr/bin/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
  /usr/bin/ld : unable to find -lstdc++
  [...]
  Project ERROR: GN build error!

The root cause is the addition in [0] of a command line option to the
build of gn, that requests static linking with libstdc++ by default.

Explicitly pass that option now, to avoid static linking with libstdc++
and get a fully dynamicallty linked executable:

    $ ldd 3rdparty/gn/out/Release/gn
        linux-vdso.so.1 (0x00007ffd3f160000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f68138e7000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68138c5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f68136fc000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f68135b6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6813b13000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f681359c000)

[0] https://github.com/qt/qtwebengine-chromium/commit/cfab9198a9917f42cf08b1caf84ab9b71aac1911#diff-905c8f054808213577c0a92d1b704615

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Gaël Portay <gael.portay@collabora.com>
[yann.morin.1998@free.fr:
  - rewrite the commit log with extra details and explanations
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/gcc/9.3.0: fix host-gcc-final when ccache is used

As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.

The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.

While debuging with "make -p" we can notice that s-selftest-c target
contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

  s-selftest-c: cc1

While the build is failing, the s-selftest-c dependencies recipe is
still running and reported as a bug by make.

  "Dependencies recipe running (THIS IS A BUG)."

A change [5] in gcc 9 seems to introduce the problem since we can't
reproduce this problem with gcc 8.

As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
including language makefile fragments.

With the fix applied, the s-seltest-c dependency contains
SELFTEST_DEPS value.

  s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
[3] https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108
[4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
[5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/sysrepo: fix SysV init script

The current script (S51sysrepo-plugind) is not able to stop the daemon.

Possible options to fix the problem:

A) By adding the "-m -p $PIDFILE" option to start the pid file will be
   created but it will not contain the correct PID used by the daemon.
   This is obviously because the daemon forks.
B) By not starting the daemon in background (sysrepo-plugind -d) and
   let do it by start-stop-daemon with "-b" option. But then the log
   messages of the daemon will not longer ends in the syslog but to stderr.
C) Start the daemon without a pidfile and stop the daemon with the
   "-x" option.

The only valid option is C to fix that.

Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[yann.morin.1998@free.fr: introduce EXECUTABLE]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

DEVELOPERS: remove Carlos Santos

Goodbye!

Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/xen: security bump to version 4.13.1

- Fix CVE-2020-11739: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service or possibly gain
privileges because of missing memory barriers in read-write unlock
paths. The read-write unlock paths don't contain a memory barrier. On
Arm, this means a processor is allowed to re-order the memory access
with the preceding ones. In other words, the unlock may be seen by
another processor before all the memory accesses within the "critical"
section. As a consequence, it may be possible to have a writer executing
a critical section at the same time as readers or another writer. In
other words, many of the assumptions (e.g., a variable cannot be
modified after a check) in the critical sections are not safe anymore.
The read-write locks are used in hypercalls (such as grant-table ones),
so a malicious guest could exploit the race. For instance, there is a
small window where Xen can leak memory if XENMAPSPACE_grant_table is
used concurrently. A malicious guest may be able to leak memory, or
cause a hypervisor crash resulting in a Denial of Service (DoS).
Information leak and privilege escalation cannot be excluded.

- Fix CVE-2020-11740: An issue was discovered in xenoprof in Xen through
4.13.x, allowing guest OS users (without active profiling) to obtain
sensitive information about other guests. Unprivileged guests can
request to map xenoprof buffers, even if profiling has not been enabled
for those guests. These buffers were not scrubbed.

- Fix CVE-2020-11741: An issue was discovered in xenoprof in Xen through
4.13.x, allowing guest OS users (with active profiling) to obtain
sensitive information about other guests, cause a denial of service, or
possibly gain privileges. For guests for which "active" profiling was
enabled by the administrator, the xenoprof code uses the standard Xen
shared ring structure. Unfortunately, this code did not treat the guest
as a potential adversary: it trusts the guest not to modify buffer size
information or modify head / tail pointers in unexpected ways. This can
crash the host (DoS). Privilege escalation cannot be ruled out.

- Fix CVE-2020-11742: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service because of bad
continuation handling in GNTTABOP_copy. Grant table operations are
expected to return 0 for success, and a negative number for errors. The
fix for CVE-2017-12135 introduced a path through grant copy handling
where success may be returned to the caller without any action taken. In
particular, the status fields of individual operations are left
uninitialised, and may result in errant behaviour in the caller of
GNTTABOP_copy. A buggy or malicious guest can construct its grant table
in such a way that, when a backend domain tries to copy a grant, it hits
the incorrect exit path. This returns success to the caller without
doing anything, which may cause crashes or other incorrect behaviour.

- Fix CVE-2020-11743: An issue was discovered in Xen through 4.13.x,
allowing guest OS users to cause a denial of service because of a bad
error path in GNTTABOP_map_grant. Grant table operations are expected to
return 0 for success, and a negative number for errors. Some misplaced
brackets cause one error path to return 1 instead of a negative value.
The grant table code in Linux treats this condition as success, and
proceeds with incorrectly initialised state. A buggy or malicious guest
can construct its grant table in such a way that, when a backend domain
tries to map a grant, it hits the incorrect error path. This will crash
a Linux based dom0 or backend domain.

https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-1

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/mp4v2: fix build with gcc <= 5

Fixes:
 - http://autobuild.buildroot.org/results/14937c96a82fb3d10e5d83bd7b2905b846fb09f9

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: expand the patch' commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

boot/arm-trusted-firmware: ignore licencing check for user defined official version

The commit [1] "licensing info is only valid for v1.4" fixed the legal-info
issues when a custom ATF tarball or a version from git is used.
But we need to ignore licencing for a used defined official ATF version.

Althougt the ATF version are licensed under BSD-3-Clause, the license
file can be updated between version (for example between v1.4 and v2.0).

Ignore the licencing check if the user provide a custom official version.

[1] d1a61703f728340ec894c367398d2a3a394a3360

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: use positive logic with the _LATEST option]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/{fmc,fmlib}: change repository location

Now that Freescale has been wholly swallowed into NXP, the public-facing
git repositories that were hosting those two packages are no longer
available.

Fortunately, they had been mirrored on Code Aurora forge (a Linux
Foundation project, so relatively stable and trustworthy), which has the
tags we need, and that generates the exact same archives.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Update for 2020.05-rc3

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/mp4v2: security bump to version 4.1.3

- Switch site to an active fork
- Send patch upstream
- Update indentation in hash file (two spaces)
- Fix the following CVEs:
  - CVE-2018-14054: A double free exists in the MP4StringProperty class
    in mp4property.cpp in MP4v2 2.0.0. A dangling pointer is freed again
    in the destructor once an exception is triggered.
    Fixed by
    https://github.com/TechSmith/mp4v2/commit/f09cceeee5bd7f783fd31f10e8b3c440ccf4c743
  - CVE-2018-14325: In MP4v2 2.0.0, there is an integer underflow (with
    resultant memory corruption) when parsing MP4Atom in mp4atom.cpp.
    Fixed by
    https://github.com/TechSmith/mp4v2/commit/e475013c6ef78093055a02b0d035eda0f9f01451
  - CVE-2018-14326: In MP4v2 2.0.0, there is an integer overflow (with
    resultant memory corruption) when resizing MP4Array for the ftyp
    atom in mp4array.h.
    Fixed by
    https://github.com/TechSmith/mp4v2/commit/70d823ccd8e2d7d0ed9e62fb7e8983d21e6acbeb
  - CVE-2018-14379: MP4Atom::factory in mp4atom.cpp in MP4v2 2.0.0
    incorrectly uses the MP4ItemAtom data type in a certain case where
    MP4DataAtom is required, which allows remote attackers to cause a
    denial of service (memory corruption) or possibly have unspecified
    other impact via a crafted MP4 file, because access to the data
    structure has different expectations about layout as a result of
    this type confusion.
    Fixed by
    https://github.com/TechSmith/mp4v2/commit/73f38b4296aeb38617fa3923018bb78671c3b833
  - CVE-2018-14403: MP4NameFirstMatches in mp4util.cpp in MP4v2 2.0.0
    mishandles substrings of atom names, leading to use of an
    inappropriate data type for associated atoms. The resulting type
    confusion can cause out-of-bounds memory access.
    Fixed by
    https://github.com/TechSmith/mp4v2/commit/51cb6b36f6c8edf9f195d5858eac9ba18b334a16

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/matio: add upstream security fixes

Fix the following CVEs:
 - CVE-2019-17533: Mat_VarReadNextInfo4 in mat4.c in MATIO 1.5.17 omits
   a certain '\0' character, leading to a heap-based buffer over-read in
   strdup_vprintf when uninitialized memory is accessed.
 - CVE-2019-20017: A stack-based buffer over-read was discovered in
   Mat_VarReadNextInfo5 in mat5.c in matio 1.5.17.
 - CVE-2019-20018: A stack-based buffer over-read was discovered in
   ReadNextCell in mat5.c in matio 1.5.17.
 - CVE-2019-20020: A stack-based buffer over-read was discovered in
   ReadNextStructField in mat5.c in matio 1.5.17.
 - CVE-2019-20052: A memory leak was discovered in Mat_VarCalloc in
   mat.c in matio 1.5.17 because SafeMulDims does not consider the
   rank==0 case.

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/gnupg: fix build with gcc 10

This commit backports an upstream patch made for gnupg2 into gnupg, in
order to fix build failures with gcc 10 due to the use of
-fno-common. Due to the code differences between upstream gnupg2 and
the old gnupg 1.x, the backport is in fact more a rewrite than an
actual backport.

Fixes:

  http://autobuild.buildroot.net/results/496a18833505dc589f7ae58f2c7e5fe80fe9af79/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/qt5/qt5declarative: fix parallel install

Installing qt5declarative examples on fast/fast/multicore machines sometimes
failes with a variation of the following error messages:

 - Cannot touch [...]/chapter5-listproperties/app.qml: No such file or directory
 - Error copying [...]/chapter2-methods/app.qml: Destination file exists

Fix it by using OTHER_FILES instead of a seperate qml files install target
to fix the race between install_target, install_qml and install_sources.

Fixes:

 - https://gitlab.com/buildroot.org/buildroot/-/jobs/565470221

Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Reworked patch and commit log]
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/efl: fix -fno-common build failure

Added upstream patch for fixing build failure when using GCC10 as a host
compiler (-fno-common is now default).

Fixes:
http://autobuild.buildroot.net/results/47f/47fcf9bceba029accdcf159236addea3cb03f12f/

Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/erlang: fix -fno-common build failure

Added upstream patch for fixing build failure when using GCC10 as a host
compiler (-fno-common is now default).

Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

linux: fix COPYING file hash

In version 5.6 a minor change was made to this file, stating tht "[a]ll
contributions to the Linux Kernel are subject to this COPYING file",
and hence the hash changed.

We can update the hash, because the licensing information is only
accounted for the "latest" version, so the hash change will not impact
older kernel versions as the user would have to switch to a non-latest
kernel.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/gerbera: fix static linking with libmagic

This patch was wrongly removed when bumping the version to 1.4.0 in
commit 6976f312fa84d4a9c4bbf99ed3b173085780dcd9

Fixes:
 - http://autobuild.buildroot.org/results/7a53a59dd08c043f371bea967c3b450a7bddcde8

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

board/freescale: increase the vfat size

The default iamge size is 32MiB, which is quite low by today's standards.
Besides, the AArch64 kernels are relatively big, which leaves not much
room, if at all, for users to experiment on the default image.

Increase the vfat size to a more reasonable 64MiB.

Note that users who derive an in-tree defconfig for their own case will
allways hit any arbitarary size we put here, so they will anyway have to
also derive this template for their own use-cases.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/uboot-tools: tools/env/fw_env.h: remove env.h

As reported by Nicolas Carrier on the Buildroot mailing list [1],
there is a new build issue while building a program which interacts with
the u-boot environment. This program uses the headers of the ubootenv
library provided by uboot-tools.

This is an upstream change from uboot [2] adding "#include <env.h>" to
fw_env.h. Adding env.h require a board configuration to build.

But only fw_env.h header is installed in the staging directory by
uboot-tools package, but since it now include env.h the build is broken
because env.h is missing from the staging directory.

It's seems an upstream bug since env_set() is not used in fw_env tool.
Nicolas removed env.h from fw_env tool and fixed it's build issue.

This problem is present since uboot v2019.10, so the uboot version
present in Buildroot 2020.02 is affected.

It's probably not a problem for upstream uboot but it's a problem
for uboot-tools package that build uboot tools without a board
configuration for the target.

[1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html
[2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e

Reported-by: Nicolas Carrier <nicolas.carrier@orolia.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[yann.morin.1998@free.fr: add URL to upstream commit]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/audit: fix -fno-common build failure

Added upstream patch for fixing build failure when using GCC10 as a host
compiler (-fno-common is now default).

Fixes:
http://autobuild.buildroot.net/results/c4b/c4bba80e9fc476247c7ba28850831c6a8edd559f/build-end.log

Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/leveldb: fix detection of the snappy library

Pull a patch pending in an upstream pull request to fix the detection
of the snappy library when we are in static linking configurations.

Fixes:

  https://bugs.busybox.net/show_bug.cgi?id=12671

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/leveldb: turn snappy into an optional dependency

snappy is not a mandatory dependency to build leveldb. Back when it
was introduced in Buildroot, as of version 1.18, the build logic
already made snappy an optional dependency.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/mesa3d: propagate missing libdrm-freedreno deps

Libdrm freedreno depends on BR2_arm || BR2_aarch64 || BR2_aarch64_be
as such we need to propagate those dependencies to mesa's gallium
freedreno driver.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/prosody: use correct bit32 package

According to https://prosody.im/doc/depends#bitop the correct bitop
package to use with prosody for Lua 5.1 is:
https://luarocks.org/modules/siffiejoe/bit32

As such replace BR2_PACKAGE_LUABITOP with BR2_PACKAGE_LUA_BIT32

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

docs/website/sponsors.html: show 2020 sponsors

So far in 2020, Logilin and Tap2Open made some financial donations to
the Buildroot Association, so let's thank them on our sponsors page.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/lrzip: fix hash

Hash was not updated by commit 18079e20a712c4a7d539ead52b0a0c725ec7f7e2

Fixes:
 - http://autobuild.buildroot.org/results/0f7179ed4706f05551af330d7f12b3efaeffd278

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

{linux, linux-headers}: bump 4.{4, 9, 14, 19}.x / 5.{4, 6}.x series

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/pkg-generic.mk: enable hash checks for svn tarbals

With commit 89f5e989323ace815a32fced27eaefee2f4666de support for
reproducible archives was added. Thus archives generated from svn do no
longer needs to be added to BR_NO_CHECK_HASH_FOR.

Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/lrzip: bump to 7f3bf46203bf45ea115d8bd9f310ea219be88af4

This bump contains only one commit that fix a build failure with asm:
https://github.com/ckolivas/lrzip/commit/844b8c057c8c7372ca41ad2efdbf849f45c24506

Fixes:
 - http://autobuild.buildroot.org/results/800d8a97966ef75dbf20e85ec8a02766ba02cc76

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/qemu: remove csky fork

We have a qemu fork for csky cpus [1] but since qemu version
bump to 4.2.0 [2] and libssh2/libssh change the csky build is
broken.

The csky fork is based on Qemu 3.0.0 but unlike autotools packages
any unknown option is handled as error.

Since we don't want to support all options from previous qemu
release and the github repository has been removed [3] and the
only remaining archive is located on http://sources.buildroot.net,
remove the qemu csky fork as suggested by [4].

[1] https://git.buildroot.net/buildroot/commit/?id=f816e5b276f1ef15840bec6667f1e8219717ab7d
[2] https://git.buildroot.net/buildroot/commit/?id=0ea17054ce7dfc54efca5634133cef786445e7b1
[3] https://github.com/c-sky/qemu
[4] http://lists.busybox.net/pipermail/buildroot/2020-May/281885.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Guo Ren <ren_guo@c-sky.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
[Peter: move patches out of 4.2.0 subdir]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/wiringpi: remove

The author has completely ripped off the git tree, so the sources
are no longer available, with that message:
    "Please look for alternatives for wiringPi"

And indeed there is a better alternative, using the kernel GPIO
subsystem and drivers.

Note that queezelite looses that functionality now, but upstream
squeezelite has done changes to do without wiringpi (hint for an
upgrade?).

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Hiroshi Kawashima <kei-k@ca2.so-net.ne.jp>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/speexdsp+tremor: switch to new git repository

The original git server on git.xiph.org died, and the Xiph project has
now moved on to host their repositories on gitlab.comn instead.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package: don't use BR2_KERNEL_MIRROR for git downloads

The git repositories are not served on the kernel.org CDN:

    fatal: repository 'https://cdn.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/' not found

Switch to explicitly use the git.kernel.org server.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/ffmpeg: bump version to 4.2.3

Removed patch included in upstream release, reformatted hashes.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/wireshark: security bump to version 3.2.4

Fix CVE-2020-13164: In Wireshark 3.2.0 to 3.2.3, 3.0.0 to 3.0.10, and
2.6.0 to 2.6.16, the NFS dissector could crash. This was addressed in
epan/dissectors/packet-nfs.c by preventing excessive recursion, such as
for a cycle in the directory graph on a filesystem.

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/fio: fix build on sh4

Fixes:
 - http://autobuild.buildroot.org/results/6dc82572ae1369aa5c9954b6e61777766c5aa3b4

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

docs/manual: new chapter on release engineering

Describe release engineering and development phases of the project.

Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/ltrace: directly use s.b.o to fetch the archive

During the migration from alioth to gitlab, the git repository for ltrace
was not migrated. There is a repository on gitlab.com, owned by the debian
maintainer, but that repository does not contain the sha1 we know of:
    https://gitlab.com/cespedes/ltrace

s.b.o. is the only known location so far to host the archive, so switch
to it.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/bind: security bump to version 9.11.19

Fixes the following security issues:

- (9.11.18) DNS rebinding protection was ineffective when BIND 9 is
  configured as a forwarding DNS server.  Found and responsibly reported by
  Tobias Klein.  [GL #1574]

- (9.11.19) To prevent exhaustion of server resources by a maliciously
  configured domain, the number of recursive queries that can be triggered
  by a request before aborting recursion has been further limited.  Root and
  top-level domain servers are no longer exempt from the
  max-recursion-queries limit.  Fetches for missing name server address
  records are limited to 4 for any domain.  This issue was disclosed in
  CVE-2020-8616.  [GL #1388]

- (9.11.19) Replaying a TSIG BADTIME response as a request could trigger an
  assertion failure.  This was disclosed in CVE-2020-8617.  [GL #1703]

Also update the COPYRIGHT hash for a change of copyright year and adjust the
spacing for the new agreements.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

packages/systemd: fix double getty on console

When selecting "console" for the automatic getty, the buildroot logic
would collide with systemd's internal console detection logic, resulting
in two getty being started on the console.

This commit fixes that by doing nothing when "console" is selected and
letting systemd-getty-generator deal with starting the proper getty.

Note that if something other than the console is selected
* Things will work properly, even if the selected terminal is also the
  console
* A getty will still be started on the console.
  This is what systemd has been doing on buildroot since the beginning. it
  could be disabled but I left it for backward compatibility

Fixes: #12361
Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/dovecot: security bump to version 2.3.10.1

- Fix CVE-2020-10957: In Dovecot before 2.3.10.1, unauthenticated
  sending of malformed parameters to a NOOP command causes a NULL
  Pointer Dereference and crash in submission-login, submission, or
  lmtp.
- Fix CVE-2020-10958: In Dovecot before 2.3.10.1, a crafted SMTP/LMTP
  message triggers an unauthenticated use-after-free bug in
  submission-login, submission, or lmtp, and can lead to a crash under
  circumstances involving many newlines after a command.
- Fix CVE-2020-10967: In Dovecot before 2.3.10.1, remote
  unauthenticated attackers can crash the lmtp or submission process by
  sending mail with an empty localpart.
- Drop first patch (already in version) and so autoreconf
- Update indentation in hash file (two spaces)

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/dovecot: drop first patch

First patch is not needed since version 2.3.0 and
https://github.com/dovecot/core/commit/08259c1f206026ca9b9f4b4e97603943c6093def

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/unbound: bump version to 1.10.1 for security fixes

Fixes the following security vulnerabilities:

CVE-2020-12662: Unbound can be tricked into amplifying an incoming query
  into a large number of queries directed to a target.

CVE-2020-12663: Malformed answers from upstream name servers can be used
  to make Unbound unresponsive.

Signed-off-by: Stefan Ott <stefan@ott.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Update for 2020.05-rc2

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/freerdp: security bump to version 2.1.1

>From ChangeLog:
- CVE: GHSL-2020-100 OOB Read in ntlm_read_ChallengeMessage
- CVE: GHSL-2020-101 OOB Read in security_fips_decrypt due to
  uninitialized value
- CVE: GHSL-2020-102 OOB Write in crypto_rsa_common
- Enforce synchronous legacy RDP encryption count (#6156)
- Fixed some leaks and crashes missed in 2.1.0
- Removed dynamic channel listener limits
- Lots of resource cleanup fixes (clang sanitizers)

https://github.com/FreeRDP/FreeRDP/blob/2.1.1/ChangeLog

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

DEVELOPERS: remove python-pycrypto

Commit 7ef76ed32fcd447391e26d33a555ff5dab6dc48e forgot to remove
python-pycrypto entry from DEVELOPERS

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/libpam-tacplus: fix build when time_t is 64 bits

Fixes:
 - http://autobuild.buildroot.org/results/874433d8cb30d21332f23024081a8b6d7b3254ae

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/vboot-utils: fix -fno-common build failure

Added upstream patch for fixing build failure when using GCC10 as a host
compiler (-fno-common is now default).

Fixes:
http://autobuild.buildroot.net/results/aca662d9fd7052f3b361b731cd266edb3b6c41b0
http://autobuild.buildroot.net/results/6546b284cf306a2fde3c69d67daf9aacffa9e143
http://autobuild.buildroot.net/results/db20bb3c11a1a9558a5d8021015c6915f99097c8

Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/python-pycrypto: remove package

This package doesn't work with Python 3.8 since the code contains
time.clock() that was deprecated in Python 3.3 and removed in Python 3.8.

Instead of applying non upstream patches from Fedora [1], python-pycrypto
was replaced by python-pycryptodomex for crda and optee-os package.
Now we can remove safely this package.

[1] http://lists.busybox.net/pipermail/buildroot/2020-April/280683.html

Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/498144209

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

boot/optee-os: replace pycrypto by pycryptodomex

>From [1] included in optee-os release 3.7.0:
"PyCryptodome is a fork of PyCrypto, which is not maintained any more
(the last release dates back to 2013 [2]). It exposes almost the same
API, but there are a few incompatibilities [3]."

pem_to_pub_c.py/sign.py scripts still use pycrypto that is replaced
by pycryptodomex. Add a patch to use pycryptodomex but don't use
upstream commit since it also switches from the algorithm
TEE_ALG_RSASSA_PKCS1_V1_5_SHA256 to TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256
when replacing pycrypto to pycryptodomex [4].

[1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0
[2] https://pypi.org/project/pycrypto/#history
[3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html
[4] https://github.com/OP-TEE/optee_os/commit/ababd72d2fd76cb2ded8e202b49db28d6545f6eb

Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/526035730

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/crda: replace pycrypto by pycryptodomex

>From [1]:
"PyCryptodome is a fork of PyCrypto, which is not maintained any more
(the last release dates back to 2013 [2]). It exposes almost the same
API, but there are a few incompatibilities [3]."

[1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0
[2] https://pypi.org/project/pycrypto/#history
[3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html

Update the patch 0001-crda-support-python-3-in-utils-key2pub.py.patch
since it add pycrypto.

>From [4]
"CRDA is no longer needed as of kernel v4.15 since commit 007f6c5e6eb45
("cfg80211: support loading regulatory database as firmware file") added
support to use the kernel's firmware request API which looks for the
firmware on /lib/firmware. Because of this CRDA is legacy software for
older kernels. It will continue to be maintained."

[4] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/tree/README?id=9856751feaf7b102547cea678a5da6c94252d83d#n8

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/python-pycryptodomex: add host variant

Adding a host variant will allow to replace host-python-pycrypto by
host-python-pycryptodomex for the crda and optee-os packages.

From [1]:
"PyCryptodome is a fork of PyCrypto, which is not maintained any more
(the last release dates back to 2013 [2]). It exposes almost the same
API, but there are a few incompatibilities [3]."

[1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0
[2] https://pypi.org/project/pycrypto/#history
[3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

DEVELOPERS: add Stephan Hoffmann for libhttpserver

I added this package while working for Grandcentrix but
am willing to maintain it further.

Signed-off-by: Stephan Hoffmann <sho@relinux.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/mtdev2tuio: remove package

mtdev2tuio breaks the builds every now and then and is not
maintained upstream. It does not seem to be useful any more.

Signed-off-by: Stephan Hoffmann <sho@relinux.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/mariadb: security bump to 10.3.23

Add two spaces in hash file.

Remove patch 0002 as it has been applied upstream.

Release notes:
https://mariadb.com/kb/en/library/mariadb-10323-release-notes/

Changelog:
https://mariadb.com/kb/en/library/mariadb-10323-changelog/

Fixes the following security vulnerabilities:
CVE-2020-2752 - Vulnerability in the MySQL Client product of Oracle MySQL
(component: C API). Supported versions that are affected are 5.6.47 and
prior, 5.7.27 and prior and 8.0.17 and prior. Difficult to exploit
vulnerability allows low privileged attacker with network access via
multiple protocols to compromise MySQL Client. Successful attacks of this
vulnerability can result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of MySQL Client.

CVE-2020-2812 - Vulnerability in the MySQL Server product of Oracle MySQL
(component: Server: Stored Procedure). Supported versions that are affected
are 5.6.47 and prior, 5.7.29 and prior and 8.0.19 and prior. Easily
exploitable vulnerability allows high privileged attacker with network
access via multiple protocols to compromise MySQL Server. Successful attacks
of this vulnerability can result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of MySQL Server.

CVE-2020-2814 - Vulnerability in the MySQL Server product of Oracle MySQL
(component: InnoDB). Supported versions that are affected are 5.6.47 and
prior, 5.7.28 and prior and 8.0.18 and prior. Easily exploitable
vulnerability allows high privileged attacker with network access via
multiple protocols to compromise MySQL Server. Successful attacks of this
vulnerability can result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of MySQL Server.

CVE-2020-2760 - Vulnerability in the MySQL Server product of Oracle MySQL
(component: InnoDB). Supported versions that are affected are 5.7.29 and
prior and 8.0.19 and prior. Easily exploitable vulnerability allows high
privileged attacker with network access via multiple protocols to compromise
MySQL Server. Successful attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently repeatable crash
(complete DOS) of MySQL Server as well as unauthorized update, insert or
delete access to some of MySQL Server accessible data.

Signed-off-by: Ryan Coe <bluemrp9@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/libexif: security bump to version 0.6.22

- Switch site to github
- Drop patches (already in version)
- Fix the following CVEs:
  - CVE-2020-13114: Time consumption DoS when parsing canon array
    markers
  - CVE-2020-13113: Potential use of uninitialized memory
  - CVE-2020-13112: Various buffer overread fixes due to integer
    overflows in maker notes
  - CVE-2020-0093: read overflow
  - CVE-2020-12767: fixed division by zero

https://github.com/libexif/libexif/releases/tag/libexif-0_6_22-release

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/bison: make installation relocatable

Our current host-bison installation is not relocatable, so if you
generate the SDK, and install it in a different location, bison will
no longer work with failures such as:

bison: /home/user/buildroot/output/host/share/bison/m4sugar/m4sugar.m4: cannot open: No such file or directory

This particular issue is already resolved upstream by the addition of
"relocatable" support, which we enable using --enable-relocatable.

Once this issue is fixed, a second one pops up: the path to the m4
program itself is also hardcoded. So we add a patch to fix that as
well. The patch has been submitted upstream, which have requested for
further refinements not applicable to the Buildroot context; in the
meantime, we carry that patch.

Fixes:

  https://bugs.busybox.net/show_bug.cgi?id=12656

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: add reference to the upstream submission]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

Revert "package/cracklib: add python3 support"

This reverts commit f584595424137399dd06f73c6f04c759e04b879e.
It in fact depends on a previous patch to python that was not applied
[0], as upstream believes it is dangerous [1], and is still debating the
proper solution [2].

[0] https://patchwork.ozlabs.org/project/buildroot/patch/20200202205306.1785085-1-fontaine.fabrice@gmail.com/
[1] https://bugs.python.org/issue39026#msg369309
[2] https://bugs.python.org/issue39026

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/cracklib: add python3 support

python bindings supports python3 since version 2.8.19 and
https://github.com/cracklib/cracklib/commit/219de98766b9f1e4c8c5b174de770158ffda3a93

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/p7zip: fix build with gcc 10

Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/openldap: security bump to version 2.4.50

Security fixes:
 CVE-2020-12243: Fixed slapd to limit depth of nested filters

Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
[yann.morin.1998@free.fr: two spaces in hash file]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

DEVELOPERS: drop Stephan Hoffmann

His e-mail is no longer working:

<stephan.hoffmann@ext.grandcentrix.net>: host aspmx.l.google.com[74.125.133.26]
    said: 550-5.2.1 The email account that you tried to reach is disabled.
    Learn more at 550 5.2.1  https://support.google.com/mail/?p=DisabledUser
    o3si10331209wre.302 - gsmtp (in reply to RCPT TO command)

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/openocd: fix -fno-common build failure

Added upstream patch for fixing build failure when using GCC10 as a host
compiler (-fno-common is now default)

Fixes:
http://autobuild.buildroot.org/results/0fc/0fcb11a40bcff78e8084335114af390d2fac31e1

Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Tested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/stella: needs gcc >= 6

stella converted most of its C-Style arrays to std::array since version
6.1:
https://github.com/stella-emu/stella/commit/0c0f732e5f50b08cfcbdc5ad96c4e18ad230c04b

However, gcc 5.x does not accept a = {} initialization for std::array:

In file included from src/emucore/ConsoleIO.hxx:18:0,
                 from src/emucore/Console.hxx:34,
                 from src/gui/AudioDialog.cxx:22:
src/emucore/Control.hxx:331:71: error: array must be initialized with a brace-enclosed initializer
     std::array<bool, 5> myDigitalPinState{true, true, true, true, true};
                                                                       ^

So add a dependency on gcc >= 6 instead of trying to patch the numerous
array initializations to make them compliant with C++11

Fixes:
 - http://autobuild.buildroot.org/results/dfd9b901fabf310ed9033b8a012466c565d58684

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/qt5base: disable feature-relocatable

Disable feature-relocatable to avoid a path mismatch while searching qml
files and buildroot BR2_ROOTFS_MERGED_USR feature enabled.

As described in [1] with feature-relocatable Qt determines the search
pathes relative to the location of libQt5Core.so, with BR2_ROOTFS_MERGED_USR
enabled found first under the symlink path '/lib' instead of the install
path '/usr/lib' and searches sequentially for qml files under '/qml' instead
of the correct '/usr/qml'.

Fixes:
  - https://bugs.busybox.net/show_bug.cgi?id=12906

[1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4ac872639ed0dd3ae6627e05bdda821f7d128500

Reported-by: Joonas Harjumäki <jharjuma@gmail.com>
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/rustc: RUSTC_TARGET_NAME is needed to build host-rust

As reported on bugzilla [1], the host-rust package fail when
the target architecture or the target libc is not supported.

The error is the following:
failed to parse TOML configuration 'config.toml': expected a table key, found a right bracket at line 15

In such case BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is
not set thus RUSTC_TARGET_NAME is also not set [2].

But RUSTC_TARGET_NAME is needed to generate the file config.toml [3]

Add BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS in the host-rust
dependency.

The commit [4] that allowed to select host-rust when the target
architecture or the target libc is not supported, should have
allowed to select only host-rustc-bin.

Fixes:
Bug #12691

[1] https://bugs.busybox.net/show_bug.cgi?id=12691
[2] https://git.buildroot.net/buildroot/tree/package/rustc/rustc.mk?h=2020.05-rc1#n10
[3] https://git.buildroot.net/buildroot/tree/package/rust/rust.mk?h=2020.05-rc1#n41
[4] 025b863e6facb7b219b82ee6ee7a7916c2c3c47e

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Sam Voss <sam.voss@gmail.com>
Reviewed-by: Sam Voss <sam.voss@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/ezxml: remove package

ezXML is affected by several CVEs and is not maintained anymore (no
release since 2006) so remove it.

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/meson: use wrappers for g-ir-scanner and g-ir-compiler

We need to backport a commit to allow us to override the g-ir-scanner
and g-ir-compiler binaries in the gnome module.

By default since meson looks for these binaries as native: true
dependencies it would use the host versions instead of the wrappers
which are not useable for target package builds. Override this behavior
by specifying the correct wrapper binaries in cross-compilation.conf.

Fixes:
http://autobuild.buildroot.net/results/f49/f49bb57a6ec2890f489fbd55ced9c9249d066334/build-end.log

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
  - expand on why the backported patch does not closely match upstream
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/meson: bump to version 0.54.2

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

configs/raspberrypi{3, 4}_64: enabling BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT no longer needed

BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT is now forcefully selected by
BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS when the kernel is in
charge of building DTBs (BR2_LINUX_KERNEL_DTS_SUPPORT=y). So enabling
BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT is no longer needed in the 64-bit
defconfigs for Raspberry Pi 3 and 4.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/rpi-firmware: select BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT when needed

When BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS is enabled, and the
DTBs are built by Linux (i.e BR2_LINUX_KERNEL_DTS_SUPPORT is enabled),
these DTBs should be built with the -@ Device Tree compiler option, so
that they can be used together with DTB overlays. So let's select
BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT in this situation.

Fixes:

  https://bugs.busybox.net/show_bug.cgi?id=12831

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/libssh2: fix autoreconf comment

The comment explaining the autoreconf says that we are building from a git
clone - but we are not, currently.  However, the reconf is still needed due
to patches modifying ac files.

This commit corrects the comment.

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
[yann.morin.1998@free.fr: also mention acincludes.m4]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/lrzip: security bump to 8781292dd5833c04eeead51d4a5bd02dc6432dc7

Bump to latest upstream commit as it fixes a huge number of CVEs. Some
of them can't be linked to a given commit (e.g.
https://github.com/ckolivas/lrzip/issues/67). Moreover, upstream does
not plan to tag a new release any time soon:
https://github.com/ckolivas/lrzip/issues/99

- Fix CVE-2017-8842: The bufRead::get() function in libzpaq/libzpaq.h in
  liblrzip.so in lrzip 0.631 allows remote attackers to cause a denial
  of service (divide-by-zero error and application crash) via a crafted
  archive.
- Fix CVE-2017-8843: The join_pthread function in stream.c in
  liblrzip.so in lrzip 0.631 allows remote attackers to cause a denial
  of service (NULL pointer dereference and application crash) via a
  crafted archive.
- Fix CVE-2017-8844: The read_1g function in stream.c in liblrzip.so in
  lrzip 0.631 allows remote attackers to cause a denial of service
  (heap-based buffer overflow and application crash) or possibly have
  unspecified other impact via a crafted archive.
- Fix CVE-2017-8845: The lzo1x_decompress function in lzo1x_d.ch in LZO
  2.08, as used in lrzip 0.631, allows remote attackers to cause a
  denial of service (invalid memory read and application crash) via a
  crafted archive.
- Fix CVE-2017-8846: The read_stream function in stream.c in
  liblrzip.so in lrzip 0.631 allows remote attackers to cause a denial
  of service (use-after-free and application crash) via a crafted
  archive.
- Fix CVE-2017-8847: The bufRead::get() function in libzpaq/libzpaq.h in
  liblrzip.so in lrzip 0.631 allows remote attackers to cause a denial
  of service (NULL pointer dereference and application crash) via a
  crafted archive.
- Fix CVE-2017-9928: In lrzip 0.631, a stack buffer overflow was found
  in the function get_fileinfo in lrzip.c:979, which allows attackers to
  cause a denial of service via a crafted file.
- Fix CVE-2017-9929: In lrzip 0.631, a stack buffer overflow was found
  in the function get_fileinfo in lrzip.c:1074, which allows attackers
  to cause a denial of service via a crafted file.
- Fix CVE-2018-5747: In Long Range Zip (aka lrzip) 0.631, there is a
  use-after-free in the ucompthread function (stream.c). Remote
  attackers could leverage this vulnerability to cause a denial of
  service via a crafted lrz file.
- Fix CVE-2018-11496: In Long Range Zip (aka lrzip) 0.631, there is a
  use-after-free in read_stream in stream.c, because decompress_file in
  lrzip.c lacks certain size validation.

Also:
 - update indentation of hash file (two spaces)
 - drop patch (already in version)
 - manage host-nasm dependency which is enabled by default and has been
   fixed by:
   https://github.com/ckolivas/lrzip/commit/9f16f65705e2f1e11c41647405adcce6a12d286c

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/python-pyqt5: fix QtLocation module dependency

The QT module location from qt5location depends on
QT quick from qt5declarative.

>From qt5location-5.14.2/src/src.pro:

  qtHaveModule(quick) {
      SUBDIRS += positioningquick location
      ...
  }

Adjust pyqt5 QtLocation module dependency accordingly.

Fixes:

  - http://autobuild.buildroot.net/results/122bb0a37d968cd79dc043b48f90f1ba4135491f

  Reading .../build/python-pyqt5-5.7/QtLocation/QtLocation.pro
  Project ERROR: Unknown module(s) in QT: location

Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/mesa3d: reorder platforms to fix EGL

Mesa chooses the first platform specified in -Dplatforms as the default
EGL native platform. [0]

    Configure Options

    -D platforms=...
        List the platforms (window systems) to support. Its argument is
        a comma separated string such as -D platforms=x11,drm. It
        decides the platforms a driver may support. The first listed
        platform is also used by the main library to decide the native
        platform.

This has the effect of breaking EGL applications running on X11 and
possibly Wayland when the first platform specified isn't x11 or wayland,
and EGL_PLATFORM isn't set.

Reorder the specified platforms to use x11, wayland, and drm before
surfaceless, as this is the order chosen by other common distributions,
such as Arch Linux [1], Debian [2], and Fedora [3].

Users preferring drm or surfaceless over x11 or wayland likely know how
to override the native EGL platform, and likely have x11 and wayland
disabled anyway.

[0] https://www.mesa3d.org/egl.html
[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa#n45
[2] https://salsa.debian.org/xorg-team/lib/mesa/-/blob/fb8c1efb57ea8106525ed01c41218164f8be7f3b/debian/rules#L38
[3] https://src.fedoraproject.org/rpms/mesa/blob/master/f/mesa.spec#_337

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

configs/nanopi_neo4: fix U-Boot dependencies

In fact, nanopi_neo4 does not need pylibfdt or pyelftools, but only a
host Python interpreter, to run
./arch/arm/mach-rockchip/make_fit_atf.py.

Since upstream U-Boot commit f05d5743567984b4fff6a862fc0f42760ff135da,
this script no longer needs pyelftools. However, since upstream commit
6d06ea34239ab5099783ce588ad4aead96e1fccb (merged in U-Boot 2020.01),
it requires Python 3.x.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: update with the new NEEDS_PYTHON semantics]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

configs/roc_pc_rk3399: fix U-Boot dependencies

In fact, roc_pc_rk3399 does not need pylibfdt or pyelftools, but only
a host Python interpreter, to run
./arch/arm/mach-rockchip/make_fit_atf.py.

Since upstream U-Boot commit f05d5743567984b4fff6a862fc0f42760ff135da,
this script no longer needs pyelftools. However, since upstream commit
6d06ea34239ab5099783ce588ad4aead96e1fccb (merged in U-Boot 2020.01),
it requires Python 3.x.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: update with the new NEEDS_PYTHON semantics]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

configs/beelink_gs1: use Python 3.x

Since the bump to U-Boot 2020.01 in commit
e210080d2ab4d77862c42d2b318e21fab461f127, it needs Python 3.x on the
host.

Fixes:

  https://gitlab.com/buildroot.org/buildroot/-/jobs/535054357

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Clément Péron <peron.clem@gmail.com>
[yann.morin.1998@free.fr: update with the new NEEDS_PYTHON semantics]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

configs/olimex_a20_olinuxino_lime{, 2}: use Python 3.x

The olimex_a20_olinuxino_lime{,2}_defconfig uses U-Boot 2020.04 since
commit 6b805c3ab70b5ee63c7dcd3a4aa48a999a8a43c3. This new U-Boot
version needs Python 3.x for pylibfdt.

Fixes:

  https://gitlab.com/buildroot.org/buildroot/-/jobs/535054468
  https://gitlab.com/buildroot.org/buildroot/-/jobs/535054466

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: update with the new NEEDS_PYTHON semantics]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

boot/uboot: support building U-Boot with Python 3.x

U-Boot versions newer than 2020.01 use Python 3.x instead of Python
2.x in various scripts.

We already had the BR2_TARGET_UBOOT_NEEDS_PYLIBFDT and
BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS options, but depending on the U-Boot
version, we now need to indicate if Python 2.x or Python 3.x should be
used.

In addition, it turns out that some U-Boot configurations need a
Python interpreter, without needing pylibfdt or pyelftools. Some of
our defconfigs were abusing the BR2_TARGET_UBOOT_NEEDS_PYLIBFDT option
to make sure a Python interpreter was built.

To solve this issue, we introduce a choice, that let the users specify
what, if any, host python version is needed. The default is 'no', to
preserve the previous behaviour, unless any of the pylibfdt or the
pyelftools options is enabled, in which case we hide the 'no' option,
and use python 2 by default. This dfault is guaranteed by the order of
options in the choice.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
  - explicitly make the choice a bool
  - make BR2_TARGET_UBOOT_NEEDS_PYTHON a blind option
  - introduce the 'no' option in the choice
  - reword the commit log accordingly
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/python3-pyelftools: new package

We will need this Python 3.x variant of the host-python-pyelftools
package to be able to build some recent versions of U-Boot (>=
2020.01).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/python-argon2-cffi: bump to version 20.1.0

Drop patch that is now upstream.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/kmod: modinfo support of signature details

Add conditional support to allow the module tools to use openssl
on target to inspect the signature of signed modules. If openssl
is not enabled the modinfo will show a hash algo as unknown.

Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Tested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/exfatprogs: bump to version 1.0.3

Drop patches that are now upstream.

We don't need to autoreconf since we are using a release tarball.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/{mesa3d, mesa3d-headers}: bump version to 20.0.7

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/elf2flt: add support for XTENSA_[PN]DIFF relocations

Xtensa have added new relocation types R_XTENSA_[NP]DIFF{8,16,32} with
the same properties as the existing types R_XTENSA_DIFF{8,16,32}.
Add them to the list of ignored relocation types.

This fixes the following error when invoking elf2flt on xtensa binaries
built with the recent binutils:

  ERROR: reloc type R_XTENSA_PDIFF32 unsupported in this context

Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/php: security bump version to 7.4.6

Changelog: https://www.php.net/ChangeLog-7.php#7.4.6

Fixes CVE 2019-11048.

Reformatted hashes.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

package/cegui: remove tinyxml2 dependency

Remove tinyxml2 dependency as tinyxml2 is not a part of version 0.8.7.

Indeed, tinyxml2 has been added in September 2016 with
https://github.com/cegui/cegui/commit/49b3fd9d6f0d7555198379514b155bcd61daef67
whereas version 0.8.7 has been released in April 2016

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/fakeroot: fix for fchownat/fchmodat

fakeroot does mask out necessary flags, instead pass through
the flags that are supported by fstatat

Upstream BR: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959876

Signed-off-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/clamav: security bump version to 0.102.3

Fixes CVE-2020-3327 & CVE-2020-3341.

Release notes:
https://blog.clamav.net/2020/05/clamav-01023-security-patch-released.html

Reformatted hashes.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

package/binutils: install libopcodes to target/

libopcodes was installed in staging/ in commit 6a508d93610 (binutils:
Also install libopcodes in staging), but was not installed in target/

Starting with linux-5.6, perf (linux-tools) will link to libopcodes when
it is present. Since it is available in staging, the build succeeds.
However, libopcodes missing in target, perf fails at runtime:

    perf: ...libopcodes-2.33.1.so: cannot open shared object file

Install libopcodes to target as well.

Signed-off-by: Lecopzer Chen <lecopzer@gmail.com>
[yann.morin.1998@free.fr: reword commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

docs/website: update for 2020.02.2

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Update for 2020.02.2

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 2f7183d13133f2ded97fee273bd0cbed10226e4e)
[Peter: drop Makefile changes]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/localedef: bump version to stay in sync with glibc

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/glibc: bump version for additional post-2.30 security fixes

Fixes the following security vulnerabilities:

CVE-2020-10029: Trigonometric functions on x86 targets suffered from stack
  corruption when they were passed a pseudo-zero argument.  Reported by Guido
  Vranken / ForAllSecure Mayhem.

CVE-2020-1751: A defect in the PowerPC backtrace function could cause an
  out-of-bounds write when executed in a signal frame context.

CVE-2020-1752: A use-after-free vulnerability in the glob function when
  expanding ~user has been fixed.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/docker-cli: bump version to 19.03.8

Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/docker-engine: bump version to 19.03.8

From the release notes:
- Improve mitigation for CVE-2019-14271 for some nscd configuration.

Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/c-ares: security bump to version 1.16.1

Prevent possible use-after-free and double-free in ares_getaddrinfo() if
ares_destroy() is called prior to ares_getaddrinfo() completing.

https://c-ares.haxx.se/changelog.html#1_16_1

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

package/python-markdown2: fix CVE-2020-11888

python-markdown2 through 2.3.8 allows XSS because element names are
mishandled unless a \w+ match succeeds. For example, an attack might use
elementname@ or elementname- with an onclick attribute.

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>