| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
This prevents clang from issuing a warning here.
|
|
|
|
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.
|
|
This patch is based on earlier work by Timo Teräs.
|
|
|
|
|
|
set our gid to root so apk commit hooks run with the same gid as when
running "sudo apk add ..." from command line.
|
|
|
|
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
|
|
It means that home built packages cannot be installed with abuild-apk
unless the key is installed system-wide.
|
|
|
|
|
|
seems like it moved in recent busybox. we need to support both variants
|
|
|
|
mini sudo that checks if user is in "abuild" group and allows it to
run apk, adduser adn addgroup as root
ref #951
|
