Not allowing --allow-untrusted is obviously a good idea, but it can be
trivially bypassed if --keys-dir is allowed:
$ abuild-apk add foo-1-r0.apk
ERROR: foo-1-r0.apk: UNTRUSTED signature
$ abuild-apk --allow-untrusted add foo-1-r0.apk
abuild-apk: --allow-untrusted: not allowed option
$ cp -rp /etc/apk/keys /tmp/keys
$ cp untrusted.pub /tmp/keys
$ abuild-apk --keys-dir /tmp/keys add foo-1-r0.apk
(1/1) Installing foo (1-r0)
OK: 4319 MiB in 806 packages
If both --allow-untrusted and --keys-dir are not allowed, then it should
no longer be possible for an unprivileged member of the abuild group to
add an untrusted package.
$ abuild-apk --keys-dir /tmp/keys add foo-1-r0.apk
abuild-apk: --keys-dir: not allowed option
if there are no controlling reminal getlogin() may return NULL. We use
getpwuid() to try figure out the username and verify that we actually
have a username before we set environment USER.
Few days ago some user on IRC pointed out that the current error message:
abuild-apk: Not a member of group abuild
is confusing. He was trying to build a package using abuild -r and
didn't know what this message means.
fixes#5408
