linux-kernel - Re: script relative shebang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Jun 2016 05:19:34 +0100
From:	Ken Moffat <zarniwhoop@...world.com>
To:	Boris Rybalkin <ribalkin@...il.com>
Cc:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>,
	Nicolai Stange <nicstange@...il.com>,
	linux-kernel@...r.kernel.org,
	Vladimir Sapronov <vladimir.sapronov@...il.com>
Subject: Re: script relative shebang

On Thu, Jun 02, 2016 at 01:04:46AM +0100, Boris Rybalkin wrote:
> Sorry for insisting, but I would like to explore potential solutions
> for fixing the root problem (missing relative shebang),
> I know there are ways to workaround that, but I would like to make
> sure the proper fix is not possible.
> I understood that it is too late to introduce additional keywords
> after #! as existing systems expect fs path there, OK.
> But what about changing #! itself, is it possible to introduce another
> special sequence like #? to denote a relative mode:
> 
> #?python/bin/python
> 
If you are able to get that accepted, it will only work on linux
systems running such recent kernels.  For your own systems, you can
of course do whatever you wish.  But for public availability you
will then need to wait several years until your target linux users
can be expected to have moved to a suitable kernel (presumably the
*next* long-term stable kernel after the change is accepted : I
guess that version is perhaps the best part of a year away even if
your change got accepted into 4.8, and then you need your users'
distros to move to it).

To me, that doesn't seem worth the trouble (to you) of coding it,
getting it reviewed and eventually accepted, and then fixing up
whatever problems arise after it gets into linux-next [ problems
will always appear, even if the new code turns out not to be the
cause ].

And first, you have to persuade somebody influential that this is a
good thing to do, particularly when people have suggested
alternative approaches.  I don't count, but at the moment I've not
seen any good reasons why the kernel should be changed to support
this.

But it's your time, and your itch to scratch.

ĸen
-- 
I had to walk fifteen miles to school, barefoot in the snow.  Uphill both ways.