/bin/bash just doesn't exist on a number of systems, e.g. FreeBSD, Interix, IRIX. We don't want to use it, but since most systems /do/ provide one, we don't notice if one slips through. Add a QA check for non-prefixed shebangs. This is not trivial, but some ideas: - use hardcoded list, e.g. /usr/bin/perl, /usr/bin/bash (Solaris), /bin/bash, bin/sh, /usr/bin/awk * con: hard to manage the list (manual and needs portage update) * pro: probably matches 99% of the cases in a simple way - search for "unprefixed" paths, e.g. /usr, /bin * con: are /usr and /bin sufficient? Do we need /usr/local/? * pro: catches all, if it works - find suspects, looking for $EPREFIX in shebang * con: symlinks can result in different paths (canonical issue), q: how often is this the case? * pro: should catch everything suspicious IMO we can't die on this violation, because: - some she-bangs we accept (/bin/sh for real bourne scripts, e.g. like configure) - some scripts are really of the kind "I don't care, totally broken anyway, so don't patch"
i'd rather use a whitelist. i.e. /bin/env, /bin/sh, /usr/bin/env are ok, all others must have $EPREFIX. is there any other executable to be on the whitelist?
(In reply to comment #0) > IMO we can't die on this violation, because: IMO it would be better to die, because: > - some she-bangs we accept (/bin/sh for real bourne scripts, e.g. like > configure) those would be on the whitelist anyway, right? > - some scripts are really of the kind "I don't care, totally broken anyway, so > don't patch" those should be removed before merging, so the user doesn't accidently gets to think it is usable. if it's there, it's just a matter of time, until somebody tries to use it, and if it's just the typical "uh, what is this? let's try ... *boom*".
hehe, you got me
ok, I implemented a warnlist and whitelist. /usr/bin/env is on the whitelist (note: /bin/env is not valid: it doesn't exist on many systems!), while /bin/sh is on the warnlist. Reason is that some scripts assume /bin/sh to be POSIX sh, which is a wrong assumption for most of our systems.
first runs show a quite dramatic landscape wrt shebangs :(
/usr/share/doc stuff is now ignored /etc/{init,conf}.d stuff is now removed (no longer installed, waiting for someone to take up bug #196294)
should we do autofixing for things like e.g. /bin/bash, /usr/bin/python, ... ?
given the gigantic amount of cases where this is a problem I skipped the WARNLIST, and now automatically convert everything that I see that would be valid (e.g. binary exists) at the time of installing, or right after it. Portage /is/ noisy about it, so it will show up. Left are the cases where stupid python packages use shebangs like this: "#!python"
sounds like _many_ future troubles on ~x86-winnt just went away :) thanks!
and on ~x86-interix mainly of course... man - keyword [kc]onfusion
I just changed the code to only scan executable files. This should reduce the number of "fixed" and offending files drastically, limiting to only what really matters
this is going to hit the tree (hard) as version 2.2.00.14277
Since symlinks are checked for valid shebang too[1], native-cctools breaks on AIX, as there is a symlink to /usr/ccs/bin/ranlib, which is a /bin/ksh-script. But I'm unsure how best to handle that: Ignore symlinks pointing to outside prefix, or explicitly ignore sys-devel/native-cctools? [1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=807fbb504a3edba375f31d6ca80eec36b88bb1aa Also I want to keep the ld-wrapper for "-soname" support a /bin/ksh-script to be useable outside prefix too: this can be done with "#!/usr/bin/env /bin/ksh"
Created attachment 264183 [details, diff] Patch to ignore symlinks pointing to outside prefix. (In reply to comment #13) > But I'm unsure how best to handle that: > Ignore symlinks pointing to outside prefix, This patch ignores symlinks pointing to outside prefix...
I thought I already implemented something like that
After fixing baselayout this is the next showstopper for AIX bootstrap. As there was a portage update recently - any chance to get this in too? I could add a portage patch meanwhile - but also I could wrap ranlib like done for Darwin already (even for different reason), but don't like the latter...
The patch just ignores files that happen to be symlinks, and that point to outside the prefix, right? Although one would like to check that too, to a certain extent, I can agree with that. As such the patch looks ok. Modulo the forget-factor, I'll apply it ASAP.
(In reply to comment #17) > The patch just ignores files that happen to be symlinks, and that point to > outside the prefix, right? This is the idea, yes. But reading the patch again, eventually we should also $(canonicalize "${rf}"), in case there's a symlink pointing to sth. like //////the/../the/prefix/. This additional diff seems to work: -[[ ${rf} != ${EPREFIX}/* && ${rf} != ${eprefix}/* ]] && continue +[[ ${rf} != ${EPREFIX}/* && $(canonicalize "${rf}") != ${eprefix}/* ]] && continue
committed now, so next release includes it (at last)
released for ages
