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
Replace text in usage description of fetch that claims to verify sources
with a suggestion to use 'abuild fetch verify', which will actually
verify them.
'abuild fetch' alone will not verify sources, as it only executes the
fetch() function.
Since the obsolete 'cd "$builddir"' statements have been removed in [1],
build(), check() and package() can generate empty functions if no build
system is specified or if there is no default for the given build
system. newapkbuild will then fail, as it tries to parse the script it
generated:
$ cd /home/pmos && newapkbuild test
/usr/bin/abuild: /home/pmos/test/APKBUILD: line 18: syntax error: unexpected "}"
$ cat test/APKBUILD
...
build() {
}
...
Fix this by placing ":" in functions that would be empty.
[1]: f83d19ce79
Run the loop in a subshell via a pipe so we dont need a subshell for
each iteration.
Use `if ...; then` to make code slightly more readable.
Fix a whitespace before tab while at it.
- do not overwrite variables
srcdir is very important for abuild operation
- quoted various paths
- use a sub-shell to contain directory changing
Resolvesalpinelinux/abuild#58
Some projects might leave files which are not writable for the current
user. The cleanup process then fails and leaves files / directories
behind.
This can easily be fixed by making everything writable before removing
the files.
Add the option 'chmod-clean' which does just that.
Apparently there are many packages that does soemthing like:
subpackages="$pkgname-foo:_foo"
_foo() {
depends="$depends something-else"
}
and thus depend on the previous behavior. We need to revert and plan
this better.
This reverts commit 8fbbffd201.
Other subpackage such as -dev, -doc and even -openrc allow adjusting
depends of the subpackage through such a variable. This is, for
instance, useful to remove a dependency of the origin package from the
-libs subpackage.
While at it document it in APKBUILD(5).
In some cases, a simple rm -rf is not sufficent to clean srcdir.
One such case is the new go module system, that marks everything as
read-only - thus only letting root rm -rf it without a chmod.
There is a command intended to clean them - `go clean -modcache`.
However, for that to work, GOPATH must be defined and existent.
Running chmod for all srcdir cleanups makes no sense, nor does enforcing
root, or putting global overrides just for go.
This patch allows overriding what happens on `cleanup srcdir`, by
overriding cleanup_srcdir, and allows the use of default_cleanup_srcdir.
In our go example, it might be used as such:
cleanup_srcdir() {
go clean -modcache
default_cleanup_srcdir
}
we need to check if a given module currently is a part of core. Modules
which have a first_release may have been removed later, for example
Module::Build.
the generation of Makefile is comparable with running configure, which
we normally do in the build() function, not in prepare.
also fix some whitespace damamge.
tcely
Natanael Copa
Russ
Leo
Max Rees
Timothy Legge
Oliver Smith
Keith Maxwell
Kevin Daudt
Ikke
Mike Sullivan
Luca Weiss
Sören Tempel
Chloe Kudryavtsev