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
| ||
|
Date: Thu, 02 Jun 2016 23:41:44 +0100 From: Boris <ribalkin@...il.com> To: Ken Moffat <zarniwhoop@...world.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 I still think it is a good thing to do. I will try to implement it on github and may be some day someone influential will help me with that :) On 2 June 2016 05:19:34 BST, Ken Moffat <zarniwhoop@...world.com> wrote: >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists