Mail archive
alpine-devel

Re: [alpine-devel] [PATCH] testing/unix-privesc-check: new aport

From: Natanael Copa <ncopa_at_alpinelinux.org>
Date: Thu, 27 Nov 2014 13:49:14 +0100

On Wed, 26 Nov 2014 19:33:39 +0000
Fabio Aires <fabioaires.web_at_gmail.com> wrote:

> ---
> testing/unix-privesc-check-svn/APKBUILD | 51 +++++++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 testing/unix-privesc-check-svn/APKBUILD
>
> diff --git a/testing/unix-privesc-check-svn/APKBUILD b/testing/unix-privesc-check-svn/APKBUILD
> new file mode 100644
> index 0000000..672dfaa
> --- /dev/null
> +++ b/testing/unix-privesc-check-svn/APKBUILD
> _at_@ -0,0 +1,51 @@
> +# Contributor: Fabio Aires <fabioaires.web_at_gmail.com>
> +# Maintainer: Fabio Aires <fabioaires.web_at_gmail.com>
> +
> +_pkgname="unix-privesc-check"
> +pkgname="$_pkgname-svn"
> +pkgver=362
> +pkgrel=1

unlike archlinux, we start pkgrel from 0.

> +pkgdesc="Shell script to check for simple privilege escalation vectors on Unix systems."
> +url="https://aur.archlinux.org/packages/unix-privesc-check-svn/"
> +arch="noarch"
> +license="GPL2"
> +depends=""
> +depends_dev="subversion"
> +makedepends="$depends_dev"
> +install=""
> +subpackages=""
> +source="https://aur.archlinux.org/packages/un/$pkgname/$pkgname.tar.gz"

...

> +
> +build() {
> + cd "$_builddir"
> + svn co http://$_pkgname.googlecode.com/svn/trunk

I am not really happy with this. Lets imagine that in 1 year ahead of
time, a user reports a bug. To be able to reproduce, a developer checks
out the affected revision from aports git and rebuilds it. But guess
what, he does not get same version as user reporting the problem,
instead he gets todays svn.

Also, we normally don't want provide 2 years support for a random
development revision. Instead we want upstream maintainer make a proper
release and we ship that. If upstream don't want support a release, why
should we do it?

If we want support a random svn revision anyway, then we should make a
release tarball of it and upload it some place. In other words, we will
be doing a release for upstream. (again, if upstream don't want take
responsability for their own code, why would we want do that?)

So I'd file a bug upstream, asking them to create a release.

If they reject make release, and you still want do it for them, then
I'd recommend using pkgver=0_svn362 and either use the archlinux
tarball that you fetch with $source or have svn to check out the exact
revision/tag instead of just grabbing current trunk.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Thu Nov 27 2014 - 13:49:14 GMT