[PHP-DEV] [RFC] Optional PHP tags by php.ini and CLI options (Ver. 1.4)

Hi all,

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

Please read again if you've read already and give comments.
Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/4/12 Yasuo Ohgaki <[email protected]>:
> Hi all,
>
> 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
>
> Please read again if you've read already and give comments.
> Thank you.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi, Yasuo

Now this discussion became interesting also for me :)

Currently I have some questions:

What is FLI? Is it a typo and should be LFI?
Is the closing php-tag ignored or denied if the setting is "off"?
What would you advice in further versions as default-value of this
ini-option? Should I leave it "on" or should I switch it "off" in my
ini-file? May this should be checked by the programmer per script?
What about the starting php-tag? Can it be skipped or is this not part
of this RFC?
In the patch you're deleting stuff for asp-tags and the
php-short-open-tags ... Will this be in the final patch?
You addressed that finding the <script language="php"> could be
difficult, but this should be addressed in an extra RFC, right?

Bye
Simon

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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...

Instead of random bots attacking random URLs hoping to hit pay dirt
for an SQL injection, you will have bots that:

Use google to find stuff that looks like raw PHP code.
Scape page to look for mysql.*$_POST
Attack site.

Unless I'm really missing something here, you put a few million
people's code at risk, for a feature that has dubious value in the
first place.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi,

2012/5/6 Richard Lynch <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php