Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Reviewed-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Notable changes in this new version include support for the Apple
Aarch64 ABI, and compare-and-swap atomic instructions.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
[Peter: drop _AUTORECONF]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop no longer required setuptools runtime dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The git package in Buildroot is quite lagging behind (v2.31.4, released
on July 12, 2022 while the baseline v2.31.0 was released on March 15,
2021). Bump the package to v2.39.0 (released December 12, 2022).
While at it, also replace patch fixing uclibc no threads build with two
patches cherry-picked from upstream next branch, which fixes the same
issue by fixing the handling of flockfile(), funlockfile(), and
getc_unlocked() declarations. These patches missed the release but
planned for next maintenance release (v2.39.1).
The reason for replacing the patch is when original fix patch was
upstreamed [1], Jeff King noted that the build failure root cause
was flockfile() is defined regardless of whether uclibc is configured with
threads support or not [2].
Release notes for v2.39.0 is available on release announcement on Git
mailing list at [3].
[1]: https://lore.kernel.org/git/20221125092339.29433-1-bagasdotme@gmail.com/
[2]: https://lore.kernel.org/git/Y4RAr04vS%2FTOM5uh@coredump.intra.peff.net/
[3]: https://lore.kernel.org/git/xmqqlencspnl.fsf@gitster.g/
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit 3712e1dee7.
gperf -- the GNU perfect hash function generator
https://www.gnu.org/software/gperf/
and
gperftools -- the Google Performance Tools
https://github.com/gperftools/gperftools
are two different and unrelated projects.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Use official tarball and so drop autoreconf
- libcap is an optional dependency since
923f123a28https://github.com/royhills/arp-scan/releases/tag/1.10.0
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following security issues:
- Fix potential heap buffer overread and overwrite in DTLS if
MBEDTLS_SSL_DTLS_CONNECTION_ID is enabled and
MBEDTLS_SSL_CID_IN_LEN_MAX > 2 * MBEDTLS_SSL_CID_OUT_LEN_MAX.
- An adversary with access to precise enough information about memory
accesses (typically, an untrusted operating system attacking a secure
enclave) could recover an RSA private key after observing the victim
performing a single private-key operation if the window size used for
the exponentiation was 3 or smaller.
Drop patch (already in version:
9d9d45c6b2)
https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
remove merged patch
diff LICENSE.md
- Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler
+ Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler
- Copyright (c) 2008-2018, Dave Benson and the protobuf-c authors.
+ Copyright (c) 2008-2022, Dave Benson and the protobuf-c authors.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When creating a filesystem, mkfs.ext will chose the inode size depending
on the size of the filesystem. Small filesystem get 128-bytes inodes,
while bigger filesystems use 256-byte inodes (inode must be a power of 2
larger or equal to 128, and smaller or equal to the blocksize).
However, 128-byte inodes can't store timestamps past the dreaded
2038-01-19 03:14:07Z deadline, while inodes larger than or equal to 256
do not have the issue.
It turns out that the tipping point to decide whether a filesystem is
small or big, is about around the size of the filesystems we generate
for our runtime tests. This causes the kernel to emit warning like:
ext2 filesystem being remounted at / supports timestamps until 2038 (0x7fffffff)
We add a new option to our ext2 filesystem, so that user can specify the
size of the inode. That new option defaults to 256 to be resilient to
the Y2K38 problem.
Note: it was already possible for users to explicitly pass the -I
option, through BR2_TARGET_ROOTFS_EXT2_MKFS_OPTIONS. We could have
chosen to extend the existing value with a -I 256, but that is not
satisfactory. Indeed, we do want to ensure that the default is now
Y2K38-OK, even for existing configurations that did not have explicit
setting.
We also pass that new option before the user-specified arbitrary ones,
so that BR2_TARGET_ROOTFS_EXT2_MKFS_OPTIONS still wins (in case -I was
set there).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Peter: tweak help text]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add an upstream patch to fix CVE-2020-35492:
A flaw was found in cairo's image-compositor.c in all versions prior to
1.17.4. This flaw allows an attacker who can provide a crafted input
file to cairo's image-compositor (for example, by convincing a user to
open a file in an application using cairo, or if an application uses
cairo on untrusted input) to cause a stack buffer overflow ->
out-of-bounds WRITE. The highest impact from this vulnerability is to
confidentiality, integrity, as well as system availability.
Important note: this is not the exact upstream patch. Indeed, the
upstream patch[1] contains a png file which appears as a binary diff
inside the patch. The `patch` tool which is used by Buildroot to apply
patches does not handle that kind of diff. Since it is just a test, it
shouldn't impact the quality of the CVE fix and all changes related to
the test are removed from the patch.
[1] 03a820b173
Cc: Quentin Schulz <foss+buildroot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add an upstream patch to fix CVE-2019-6462:
An issue was discovered in cairo 1.16.0. There is an infinite loop in
the function _arc_error_normalized in the file cairo-arc.c, related to
_arc_max_angle_for_tolerance_normalized.
Cc: Quentin Schulz <foss+buildroot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is now based on Linux 6.1-rc3. We don't have an option for 6.1 yes, so
mark it as 6.0 headers.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The D1 support is now upstream, so we can use the upstream 1.1 release
instead of a custom version.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is now based on U-Boot 2022.10 and has gained SPL support, so use that
instead of sun20-d1-spl. With this we can also drop the u-boot patch and
patch directory.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
