Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60498
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <2d366ed2f445f9a48ce1a19e43bca3f2.squirrel@www.l-i-e.com>
References: <CAGa2bXYdfTuXAwQK6i0hk9jZGZsM1KaXsQqMAFsrBKbERTX9_w@mail.gmail.com>
 <2d366ed2f445f9a48ce1a19e43bca3f2.squirrel@www.l-i-e.com>
Date: Mon, 7 May 2012 09:14:57 +0900
Message-ID: <CAGa2bXbm3_gJ1VTD4SsQ8sFaHsPOwTvecqmPdnZjsC38Hy2Azw@mail.gmail.com>
To: Richard Lynch <ceo@l-i-e.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Optional PHP tags by php.ini and CLI options
 (Ver. 1.4)
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

2012/5/6 Richard Lynch <ceo@l-i-e.com>:
> On Wed, April 11, 2012 5:14 pm, Yasuo Ohgaki wrote:
>> I think my RFC confused people on this list due to improper
>> descriptions
>> and too much information. Sorry for the confusion. I revised the RFC
>> so
>> that most important points can be understood at a glance.
>>
>> https://wiki.php.net/rfc/nophptags
>
> We all know there are a LOT of bad scripts out there.
>
> A *LOT* of bad scripts.
>
> With major security holes in them.
>
> I do not see your average PHP scripter changing that behavior: It's
> just so easy to write a PHP script, which is why it's so popular.
>
> Now, you are going to open up all the inexperienced scripters to code
> exposure when they start using this cool new feature of being lazy and
> not typing that silly <?php tag.
>
> And that code being exposed will have major security holes in it.
>
> This is just not a good idea...

PHP users are used to this. You know short tags and they are optional.
Besides, "<?php" may always be top of scripts and wrong configuration
can be detected by simply viewing scripts.

LFI is more serious, since it's involves arbitrarily code execution (i.e. fatal
security error) and may not be detected by  simple code search.

It would be much better to have this from security point of view.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net