prior to the recent reworks, this error handling path was never
triggered, because the script is ran without pipefail, and it was at
the end of a | pipe | line | sort, so all it did was be ignored for 'new
apks', when the old one would fail to fetch and be missing.
since we now do hit this path on fetch failure however, it aborts the
script when a new subpackage/package is added (since the 'old apk' won't
exist), and doesn't output a diff. since before we always ignored this,
ignore the 'old apk' perhaps not existing, which gives the currently
intended behaviour.
when apk fetch fails (a new package is added) these just say 'gzip invalid magic' or similar, as there is no old apk to compare to.
the || die is also never triggered, as it only triggers when the sort fails, since it won't trigger on earlier pipeline steps
this needs more cleaning up, but i'll leave that for the future when i write some tests.
We can't run mkusers inside the chroot because of bwrap peculiarities.
Presently, rootbld does therefore not work at all for APKBUILDs which
use $pkggroups/$pkguser. While not polluting the host is a noble goal
it isn't really useful if it causes rootbld to be incapable of building
certain packages (i.e. those using $pkggroups/$pkguser with groups
not existent on the host).
This commit therefore restores the original behavior for now. While at
it, I also added a comment to the mkusers invocation.
See: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094
This reverts commit 84d7b7693d.
In abuild's getopts loop, option variables such as "keep", "verbose",
etc are only set if the corresponding option is found. If such an option
is *not* found, any environment variable with the same name will leak
in, instead. Prevent this by explicitly unsetting almost all of them.
the previous implementation used -regex, which is subtly different between busybox and findutils
[0-9]\+ matches on busybox, but doesn't match with gnu findutils
[0-9]+ matches with findutils, but doesn't match on busybox
this means python deps were subtly broken when findutils was installed
(sometimes pulled via makedeps) vs not
Similar to suid binaries, abuild will now error out if the package
includes binaries with setcap(8) capabilities but doesn't have `setcap`
in `$options`. This eases identifying package which ship binaries
with extra capabilities.
Furthermore, if these binaries are executable by others a warning is
emitted. This warning could be changed to an error in the future.
The recommendation is to make such binaries only executable by owner
and group, thereby requiring the system administrator to explicitly
add users to a specific group in order to give them accesses to these
capabilities.
See: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/45
Discussion: This change requires abuild to depend on the `libcap`
package for the `getcap` binary. It does not seem to be possible
at the moment to use scanelf(1) to identify these binaries.
strictly speaking, it is possible for an x86_64 cpu to run 32-bit
userspace binaries without qemu emulation. it is also possible for an
aarch64 cpu to run armhf/armv7 binaries (as long as the cpu implements
it, most do). rather than check for every possible combination of when
this is allowed (host cpu + emulated target, does cpu support it, ...),
just downgrade this case to a warning, to permit non-emulated use.
ref https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/117#note_255174
these have a slight runtime hit (like fortify-source), but help find
bugs early, by making programs crash on invariants that would corrupt
memory and lead to hard to debug crashes/bugs later.
these are mostly useless and redundant given the other flags. all they
do is spam more flags onto every invocation line- things don't "only"
pass cppflags for anything in the general case.
