The patch is pending in the upstream PR queue for a while now. Include
it here until its merged upstream and we can update.

Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

The CVE issue CVE-2020-8916 has been fixed in the upstream repo for a
long time and our recipe has this commit already included.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-8916



Mark the CVE as such.

Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

Using current meta-java in a project configured for a riscv32 machine gives
the following error:

    ERROR: ExpansionError during parsing /home/esben/ostc/openharmony/poky/meta-java/recipes-core/openjdk/openjdk-7_99b00-2.6.5.bb
    Traceback (most recent call last):
      File "Var <LLVM_CONFIGURE_ARCH>", line 1, in <module>
      File "/home/esben/ostc/openharmony/poky/meta-java/classes/openjdk-build-helper.bbclass", line 86, in openjdk_build_helper_get_llvm_configure_arch(d=<bb.data_smart.DataSmart object at 0x7fc729388940>):
             else:
        >        if 'shark' in d.getVar('PACKAGECONFIG').split():
                     bb.warn("%s does not support %s in Shark builds yet" % (d.getVar('PN'), arch) );
    bb.data_smart.ExpansionError: Failure expanding variable LLVM_CONFIGURE_ARCH, expression was ${@openjdk_build_helper_get_llvm_configure_arch(d)} which triggered exception AttributeError: 'NoneType' object has no attribute 'split'

Which is caused by the attempt to expand PACKAGECONFIG variable, which is only
set for selected architectures.  Defaulting it to empty is a sane fix to that.

A patch for meta-java doing the same have been submitted.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

We don't use meta-java in OHOS, and are re-using meta-ohos-staging in
meta-openharmony, which does use meta-java.
So in order to allow staging changes to meta-java recipes, we need this
dynamic layer to avoid breaking OHOS.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

util-linux uses autogenerated non-literal format strings in its hexdump
code. Those strings have been verified to be safe in 2.35.1.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping util-linux building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

shadow uses non-literal format strings to integrate system information
into the login prompt. This is harmless because harmful format strings
are checked for (and in the worst case, the strings come from a file
that is writable by root only).

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping shadow building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

diffutils uses non-literal format strings in a few places.
This has been verified to be harmless in 3.7

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping diffutils building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

make uses non-literal format strings in a few places.
This has been verified to be harmless in 4.3

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping make building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

bison uses non-literal format strings in a few places.
This has been verified to be harmless in 3.5.4.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping bison building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

sed uses non-literal format strings in a few places.
This has been verified to be harmless in 4.8.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping sed building.

TARGET_CFLAGS_remove = "-Werror=format-nonliteral"

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

flex uses non-literal format strings in a few places.
This has been verified to be harmless in 2.6.4.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping flex building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

gmp uses non-literal format strings to implement
its own printing functions.
This has been verified to be harmless in 6.2.0.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping gmp building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

db converter uses non-literal format strings
in a few places.
This has been verified to be harmless in 5.3.28.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping db building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

ncurses' termcap to terminfo converter uses a non-literal
format string.
This has been verified to be harmless in 6.2 (the "unsafe"
use of sscanf happens only with hardcoded, safe strings).

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping ncurses building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

openssl's opt tool uses a non-literal format string for
help texts.
This has been verified to be harmless in 1.1.1k (the "unsafe"
use of a printf style function happens only with hardcoded,
safe strings).

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping openssl building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

hdparm's sysfs I/O functions trigger warnings with
-Wformat-nonliteral, but the format strings are checked
by other means.
This has been verified to be harmless in 9.58.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping hdparm building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

busybox implements some of its own string handling that triggers
warnings with -Wformat-nonliteral.
This has been verified to be harmless in 1.31.1.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping busybox building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

unzip uses some #define trickery that triggers warnings with
-Wformat-nonliteral.
This has been verified to be harmless in 6.0.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping unzip building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

zip uses some #define trickery that triggers warnings with
-Wformat-nonliteral.
This has been verified to be harmless in 3.0.

Removing -Werror=format-nonliteral here allows us to use
-Werror=format-nonliteral globally in OPTIMIZE_FOR=security mode
while keeping zip building.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

This is a workaround for a legitimate xtc-acts bug modern compilers complain
about when extra warnings for potential security problems are enabled.

While this is not the proper fix and this should be fixed properly at some
point (reading 16 bytes from a 12-character string is not a good idea...),
this is enough to keep the build working until someone has time to fix it
properly, and it doesn't make things worse (before, this just went
unnoticed because the warning wasn't enabled).

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

gnupg uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 2.2.20; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

ltp uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 20200120; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

gtk uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 3.24.14; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

gpgme uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 1.13.1; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

pcre2test uses negative array indices which seem to confuse the array bounds
checker. The warnings look harmless.

Disable -Werror=array-bounds for libpcre2 to allow building with a global
-Werror=array-bounds.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

Use system libraries - it's better for code size as well as security
(fix bugs in one place).

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

cairo uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 1.16.0; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

mesa has a code path that could theoretically trigger an overrun;
however, this only happens if an internal (declared static) function
is called with incorrect parameters. This doesn't seem to be
exploitable.

There's also a harmless format-nonliteral warning.

Removing -Werror=array-bounds and -Werror=format-nonliteral here allows
us to use these flags globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

socat uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 1.7.3.4; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

grub's MD-RAID1 implementation uses zero-length array tricks causing
array-bounds warnings.

The warnings have been verifited to be harmless in 2.06; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

liburcu uses zero-length array tricks causing array-bounds warnings.

The warnings have been verifited to be harmless in 0.11.1; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

libgcrypt uses zero-length array tricks causing array-bounds warnings.

The warnings have been verified to be harmless in 1.8.5; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

Remove -Wformat-security and -Wformat-nonliteral from compiler flags for
incompatible code in gcc so we can enable those flags globally.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

libxml uses zero-length array tricks causing array-bounds warnings.

The warnings have been verified to be harmless in 2.9.10; for extra
security, this should be re-checked after updating.

Removing -Werror=array-bounds here allows us to use -Werror=array-bounds
globally in OPTIMIZE_FOR=security mode.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

Don't pass potentially unknown strings as first argument to printf-like
functions. This fixes the build with toolchain security options
(-Werror=format-string) enabled.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

argv needs to hold 2 char pointers, not 2 chars.
Found by enabling toolchain security options.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

This allows use of meta-ohos-staging without meta-intel layer, without
changing behaviour when used together with meta-intel.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This allows use of meta-ohos-staging without meta-st-stm32mp layer, without
changing behaviour when used together with meta-st-stm32mp.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

To avoid build breaks to stay unnoticed (as happened recently) a simple
image build for the blueprint image is added.

Fixes https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/111



Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

This backports a set of patches from upstream to fix build error:

| ../strace-5.5/xlat/inet_protocols.h:232:1: error: static assertion
failed: "IPPROTO_MAX != 256"
|   232 | static_assert((IPPROTO_MAX) == (256), "IPPROTO_MAX != 256");

It also adds a patch to regenerate the headers based on the
updated/modified .in files.

Fixes https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/102



Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>