| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
fixes #9984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
