My original bpftools package made "variant" builds of bpftool and libbpf
as a convenience, since both used the same local kernel sources with the
same versioning. This is no longer the case, since the commit below
switched to using an out-of-tree build mirror hosting repos for each.
Replace bpftools with separate bpftool and libbpf packages, each simplified
and correctly versioned. Also fix the broken libbpf ABI introduced in the
same commit. Existing build .config files are not impacted.
Fixes: 00cbf6f6ab ("bpftools: update to standalone bpftools + libbpf, use the latest version")
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Fixes errors in the form of:
/Users/user/src/openwrt/openwrt/build_dir/hostpkg/json-c-0.16/json_util.c:63:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
const char *json_util_get_last_err()
^
void
1 error generated.
ninja: build stopped: subcommand failed.
Reported-by: Paul Spooren <mail@aparcar.org>
Suggested-by: Paul Spooren <mail@aparcar.org>
Signed-off-by: Nick Hainke <vincent@systemli.org>
Based on Paul Fertser <fercerpav@gmail.com>'s guidance:
Change AUTORELEASE in rules.mk to:
```
AUTORELEASE = $(if $(DUMP),0,$(shell sed -i "s/\$$(AUTORELEASE)/$(call commitcount,1)/" $(CURDIR)/Makefile))
```
then update all affected packages by:
```
for i in $(git grep -l PKG_RELEASE:=.*AUTORELEASE | sed 's^.*/\([^/]*\)/Makefile^\1^';);
do
make package/$i/clean
done
```
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
With the update of selinux no package depends anymore on pcre in the
base repository. Move it to packages feed.
Signed-off-by: Nick Hainke <vincent@systemli.org>
musl 1.2.4 deprecated legacy "LFS64" ("large file support") interfaces so
just having _GNU_SOURCE defined is not enough anymore.
_LARGEFILE64_SOURCE has to be defined in the source, or CFLAGS can be used
to pass -D_LARGEFILE64_SOURCE to allow to keep using LFS64 definitions.
Fixes: fff878c5bc ("toolchain/musl: update to 1.2.4")
Signed-off-by: Robert Marko <robimarko@gmail.com>
musl 1.2.4 deprecated legacy "LFS64" ("large file support") interfaces so
just having _GNU_SOURCE defined is not enough anymore.
_LARGEFILE64_SOURCE has to be defined in the source, or CFLAGS can be used
to pass -D_LARGEFILE64_SOURCE to allow to keep using LFS64 definitions.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Running autoreconf or autogen.sh is causing
the gettext-runtime subdirectory to have a configure script
that looks for and attempts to link to an external libunistring.
However, the macros and symbols for supporting that configuration
are not present in this subdirectory yet.
This results in some host machines to not build the
included libunistring objects for libgrt,
but at the same time, also not input the proper flag to the linker
for linking to an external library when it is found or even when
explicitly setting configuration to use a prefix for libunistring,
resulting in the common linking failure "undefined reference".
Some similar (and old...) upstream commits do the same thing,
but only for gettext-tools and libgettextpo.
Ref: ae943bcc1 ("Link with libunistring, if it exists.") # gettext.git
Ref: 61e21a72f ("Avoid link error in programs that use libgettextpo.") # gettext.git
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Add libunistring in order to link to gettext
and other packages directly
instead of the built-in substitute for it.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Using the local gnulib source during autogen.sh
allows for fine-grained control over the macros
and source files for use with gettext
but part of gnulib instead of gettext,
without having to wait for a release
or deal with gnulib as a git submodule.
This is an alternative to running autoreconf.
It also removes the need to patch macros
in the case where there is a conflict
between the source and our aclocal directory.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Some users have reported that gettext builds
are attempting to link to libxml2
while it was supposed to be configured
to use it's own built-in substitute.
Configure gettext to require and link
to our local libxml2 explicitly.
Add a patch to revert upstream commit 87927a4e2
which forces libtextstyle to use the built-in libxml,
no matter what the configuration is,
making that option configurable again
after the configure script is regenerated.
Reported-by: Tianling Shen <cnsztl@immortalwrt.org>
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Instead of editing the SUBDIRS variable with a patch,
it can be overriden at the end of the command line when invoking Make.
This tool has a series of recursive Makefiles in each subdirectory,
therefore SUBDIRS is set to a pattern of Make functions
so that the result is variable depending on the current subdirectory
that Make is being invoked in.
Some of the subdirectories don't have a Makefile and are just storing files
for another subdirectory Makefile target,
therefore we have to place a fake Makefile that does nothing.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
This applies commit 02ac9c94 to fix this OpenSSL Security Advisory
issued on 20th April 2023[1]:
Input buffer over-read in AES-XTS implementation on 64 bit ARM
(CVE-2023-1255)
==============================================================
Severity: Low
Issue summary: The AES-XTS cipher decryption implementation for 64 bit
ARM platform contains a bug that could cause it to read past the input
buffer, leading to a crash.
Impact summary: Applications that use the AES-XTS algorithm on the 64
bit ARM platform can crash in rare circumstances. The AES-XTS algorithm
is usually used for disk encryption.
The AES-XTS cipher decryption implementation for 64 bit ARM platform
will read past the end of the ciphertext buffer if the ciphertext size
is 4 mod 5 in 16 byte blocks, e.g. 144 bytes or 1024 bytes. If the
memory after the ciphertext buffer is unmapped, this will trigger a
crash which results in a denial of service.
If an attacker can control the size and location of the ciphertext
buffer being decrypted by an application using AES-XTS on 64 bit ARM,
the application is affected. This is fairly unlikely making this issue a
Low severity one.
1. https://www.openssl.org/news/secadv/20230420.txt
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Apply two patches fixing low-severity vulnerabilities related to
certificate policies validation:
- Excessive Resource Usage Verifying X.509 Policy Constraints
(CVE-2023-0464)
Severity: Low
A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints. Attackers may be able to exploit
this vulnerability by creating a malicious certificate chain that
triggers exponential use of computational resources, leading to a
denial-of-service (DoS) attack on affected systems.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
- Invalid certificate policies in leaf certificates are silently ignored
(CVE-2023-0465)
Severity: Low
Applications that use a non-default option when verifying certificates
may be vulnerable to an attack from a malicious CA to circumvent
certain checks.
Invalid certificate policies in leaf certificates are silently ignored
by OpenSSL and other certificate policy checks are skipped for that
certificate. A malicious CA could use this to deliberately assert
invalid certificate policies in order to circumvent policy checking on
the certificate altogether.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
Note: OpenSSL also released a fix for low-severity security advisory
CVE-2023-466. It is not included here because the fix only changes the
documentation, which is not built nor included in any OpenWrt package.
Due to the low-severity of these issues, there will be not be an
immediate new release of OpenSSL.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
