Otherwise, user-set environment variables can leak into the container
and cause spurious build/test failures. A common example is the value of
the SHELL environment variable which is used by a lot of software.
Outside of the bwrap container I use ksh and my SHELL environment
variable points to /bin/ksh, however, inside the container /bin/ksh is
not available and hence software relying on $SHELL doesn't work
properly. This can cause annoying to debug test failures, e.g. !43430.
format-security warns of usage such as `printf(x)`, which is usually a
security hole.
int-conversion is very useful to find cases such as
```
error: assignment to 'const char *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
msg = strerror_r(errnum, buf, buflen);
```
where the usage of things like the wrong strerror_r are legitimate
errors in the application that cause it to crash. it makes more sense
for the compiler to reject it instead, and this does that.
apk 2.14 now warns on missing deps in the same repo even with --quiet:
WARNING: No provider for the dependencies:
/bin/sh aardvark-dns abseil-cpp-dev acl acl-dev alsa-lib-dev android-tools aom-dev apache2 at-spi2-core at-spi2-core-dev atomicparsley attr attr-dev
audacious autoconf avahi avahi-dev aws-c-cal-dev aws-c-compression-dev aws-checksums-dev baloo-dev bash bc binutils binutils-dev black blas-dev bluez
The abuild-tar binary can read past the end of an invalid tar header if
the contained link name does not end with a terminating NUL character.
In this case it reads past the end of hdr.linkname and maybe even past
the end of the header if no further NUL bytes are contained.
The strnlen function is used in apk-tools for such cases as well, so I
recommend to use it here too.
How to reproduce (compile abuild-tar with -fsanitize=address):
cat > poc.tar.b64 << EOF
b3dvAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMDAAMDAwMDAw
MAAwMDAwMDAwADAwMDAwMDAwMDAwADAwMDAwMDAwMDAwADAwMDAwMAAAMm93b29vb29vb29vb29v
b29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29v
b29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29v
b29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29v
b29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29v
b29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29v
b29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb29vb28=
EOF
base64 -d < poc.tar.b64 | abuild-tar --hash
use a fake openssl for abuild-keykey and pre-generate the abuild keys.
This makes tests run significantly faster as we dont need to generate
new keys for each abuild-keygen test.
-v outputs everything from the tests, which has a lot of very
uninteresting and spammy data. all we really care about is failures, so
print only the errorlogs on failure by default. this is analogous to the
cmake output on failure
As demonstrated in b7813c3 (abump: demonstrate abump environment
polution, 2022-10-15), sourcing APKBUILDs in abump polutes it's
environment.
Address that by sourcing the APKBUILD in a subshell as well as some of
the checks following it that need the information from the APKBUILD.
That information is not used any later, it's not an issue that it's
discarded outside of the subshell.
abump sources the APKBUILD to be able to check some variables. When the
APKBUILD exports variables in the global scope, that affects the abump
environment as well.
When abump then executes abuild, it will inherrit the environment from
abump. This is an issue under the following circumstances:
* The APKBUILD only updates the value of an exported variable if it's
not set
* The default value includes a variable set by abuild, like `$srcdir`.
Because the variable is set by abuild, but not abump, the resulting
exported variable is different. Because it's then set incorrectly in the
abump environment, it's no longer updated with the correct variable when
abuild is invoked.
Some languages (such as Hare) do not support position-independent
executables. Such cases require extra care and scrutiny, but should not
be entirely disallowed.
