[pacman-dev] [PATCH] makepkg: only strip files that are writable
Signed-off-by: Allan McRae <allan@archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5120feb..0ca5e36 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -869,7 +869,7 @@ tidy_install() { if [[ $(check_option strip) = y && -n ${STRIP_DIRS[*]} ]]; then msg2 "$(gettext "Stripping unneeded symbols from binaries and libraries...")" local binary - find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do + find ${STRIP_DIRS[@]} -type f -writable 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *compressed-encoding*) # Skip compressed binaries ;; -- 1.6.6.1
On 26.01.2010 14:30, Allan McRae wrote:
Signed-off-by: Allan McRae <allan@archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5120feb..0ca5e36 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -869,7 +869,7 @@ tidy_install() { if [[ $(check_option strip) = y && -n ${STRIP_DIRS[*]} ]]; then msg2 "$(gettext "Stripping unneeded symbols from binaries and libraries...")" local binary - find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do + find ${STRIP_DIRS[@]} -type f -writable 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *compressed-encoding*) # Skip compressed binaries ;;
Seems reasonable (strip fails for non-writable files, right?). However, according to my quick search, the writable flag is not available on BSD [1,2]. So we have to use -perm or is there a better option? Cedric [1] http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=find [2] http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Reference/ManPag...
On 27/01/10 00:49, Cedric Staniewski wrote:
On 26.01.2010 14:30, Allan McRae wrote:
Signed-off-by: Allan McRae<allan@archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5120feb..0ca5e36 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -869,7 +869,7 @@ tidy_install() { if [[ $(check_option strip) = y&& -n ${STRIP_DIRS[*]} ]]; then msg2 "$(gettext "Stripping unneeded symbols from binaries and libraries...")" local binary - find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do + find ${STRIP_DIRS[@]} -type f -writable 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *compressed-encoding*) # Skip compressed binaries ;;
Seems reasonable (strip fails for non-writable files, right?). However, according to my quick search, the writable flag is not available on BSD [1,2]. So we have to use -perm or is there a better option?
Cedric
[1] http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=find [2] http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Reference/ManPag...
Ah, stupid incompatible implementations of core utilities... So, changing that find to: find ${STRIP_DIRS[@]} -type f -perm -u+x should work everywhere. Allan
On Tue, Jan 26, 2010 at 3:56 PM, Allan McRae <allan@archlinux.org> wrote:
Ah, stupid incompatible implementations of core utilities... So, changing that find to:
find ${STRIP_DIRS[@]} -type f -perm -u+x
should work everywhere.
A bunch of stupid questions : - shouldn't it be rw rather than x ? - why don't we just let strip handle that ? (i.e. let it fail if it doesn't have the permission) Also if makepkg and that command were run as root, the permissions don't seem to matter - would anyone want to strip everything regardless of their permissions (and running strip as root for that reason) ?
On 27/01/10 03:56, Xavier Chantry wrote:
On Tue, Jan 26, 2010 at 3:56 PM, Allan McRae<allan@archlinux.org> wrote:
Ah, stupid incompatible implementations of core utilities... So, changing that find to:
find ${STRIP_DIRS[@]} -type f -perm -u+x
should work everywhere.
A bunch of stupid questions : - shouldn't it be rw rather than x ?
Brain spasm... I had actually put -u+w in my updated patch. The "r" does not seem to be needed, not even for the file command.
- why don't we just let strip handle that ? (i.e. let it fail if it doesn't have the permission)
That will return 1 and should set of our error trap (untested...). It also prints an error message in the part of packaging makepkg handles which is not good.
Also if makepkg and that command were run as root, the permissions don't seem to matter
I did not realize that. Looks like I need a root check there...
- would anyone want to strip everything regardless of their permissions (and running strip as root for that reason) ?
I have no idea why libraries/binaries are installed without 644/755 permissions anyway. Configuration files I understand... That said, the do get installed that way and so this needs dealt with. Allan
Am 27.01.2010 00:24, schrieb Allan McRae:
- would anyone want to strip everything regardless of their permissions (and running strip as root for that reason) ?
I have no idea why libraries/binaries are installed without 644/755 permissions anyway. Configuration files I understand... That said, the do get installed that way and so this needs dealt with.
I have seen cases where applications require certain helper applications or plugins to be 555 or 500, so not writable by anyone (for security reasons, but I don't remember exactly where I saw this). Instead of not stripping them at all, wouldn't it be desirable to make them writable, strip them and remove the writable permissions again?
On 03/02/10 03:02, Thomas Bächler wrote:
Am 27.01.2010 00:24, schrieb Allan McRae:
- would anyone want to strip everything regardless of their permissions (and running strip as root for that reason) ?
I have no idea why libraries/binaries are installed without 644/755 permissions anyway. Configuration files I understand... That said, the do get installed that way and so this needs dealt with.
I have seen cases where applications require certain helper applications or plugins to be 555 or 500, so not writable by anyone (for security reasons, but I don't remember exactly where I saw this).
Instead of not stripping them at all, wouldn't it be desirable to make them writable, strip them and remove the writable permissions again?
Sure, consider that a stage 2. For this stage I just want to avoid the error trap that should (untested) be set off in these cases. Allan
participants (4)
-
Allan McRae
-
Cedric Staniewski
-
Thomas Bächler
-
Xavier Chantry