Agreed, I will respond only on the RFC thread.
On Mon, Apr 9, 2012 at 4:45 PM, Kris Craig wrote:
>
> On Mon, Apr 9, 2012 at 4:11 AM, Pierre Joye wrote:
>>
>> hi!
>>
>> On Mon, Apr 9, 2012 at 12:48 PM, Tom Boutell wrote:
>> > I agree, which is why the rfc does not call for a php.ini option.
>>
>
On Mon, Apr 9, 2012 at 4:11 AM, Pierre Joye wrote:
> hi!
>
> On Mon, Apr 9, 2012 at 12:48 PM, Tom Boutell wrote:
> > I agree, which is why the rfc does not call for a php.ini option.
>
> Can we kill this thread and focus only on the RFC one please? Thanks.
>
>
+1
We've got 2 active threads disc
Hi,
2012/4/10 Ángel González :
> On 09/04/12 21:17, Yasuo Ohgaki wrote:
>> Please do not tell me that programmer should
>> learn not to, since it's not a protection but education.
> Hire a more competent programmer? If he writes such code,
> he will be completely unaware of the subtleties of XSS,
On 09/04/12 21:17, Yasuo Ohgaki wrote:
> Please do not tell me that programmer should
> learn not to, since it's not a protection but education.
Hire a more competent programmer? If he writes such code,
he will be completely unaware of the subtleties of XSS, or how
SQL should be escaped, and his c
Hi,
2012/4/10 Tom Boutell :
> I agree that the security argument is bogus, but it was never one of
> my reasons for this proposal.
The risk is there and it is hard to get rid of it.
The risk will not go anywhere by telling the risk bogus.
If programmers/administrators could disable embed mode,
t
Hi,
2012/4/9 Tom Boutell :
> I agree, there should be no limiting of unrelated language features to
> half-protect people who can't plan where uploads go.
You misunderstood the problem.
File upload does not matter.
Mandatory embed feature makes PHP vulnerable.
See my script injection example in
Such code would have the .phpc extension, so it wouldn't get loaded at
all by most autoloaders that aren't prepared for it I imagine.
This feature would certainly make the most sense as part of a new
version of PHP that introduces other new functionality. "I'm going to
use feature X in this code,
From: Tom Boutell [mailto:t...@punkave.com]
>
> On Mon, Apr 9, 2012 at 12:43 PM, John Crenshaw
> wrote:
> > interoperability is somewhat reduced in the sense that all 3rd party
> > code would have to be checked for the
> I'm not sure what you mean by this part exactly?
Suppose a code library
On Mon, Apr 9, 2012 at 12:43 PM, John Crenshaw wrote:
> interoperability is somewhat reduced in the sense that all 3rd party code
> would have to be checked for the http://www.php.net/unsub.php
From: Tom Boutell [mailto:t...@punkave.com]
> John, please take a look at the RFC:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> I am not proposing any backwards-incompatible changes that would affect
> existing code. Code that isn't interested need not ever take advantage of
John, please take a look at the RFC:
https://wiki.php.net/rfc/source_files_without_opening_tag
I am not proposing any backwards-incompatible changes that would
affect existing code. Code that isn't interested need not ever take
advantage of the feature and can interoperate with code that does. I
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki
> There were full of embedded PHP pages 10 years ago.
> Only template pages require embedded PHP script now.
There are legions of sites that use PHP "on the metal". No framework, no MVC,
no CMS, just direct code files mi
hi!
On Mon, Apr 9, 2012 at 12:48 PM, Tom Boutell wrote:
> I agree, which is why the rfc does not call for a php.ini option.
Can we kill this thread and focus only on the RFC one please? Thanks.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals
I agree, which is why the rfc does not call for a php.ini option.
Sent from my iPhone
On Apr 9, 2012, at 3:20 AM, Arvids Godjuks wrote:
> And you get same issues that existed with magic quotes, register variables,
> safe mode and other optional stuff that was required to run application when
I agree, there should be no limiting of unrelated language features to
half-protect people who can't plan where uploads go.
Sent from my iPhone
On Apr 9, 2012, at 6:11 AM, Ferenc Kovacs wrote:
>
> On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki wrote:
> Hi,
>
> The only valid reason for remov
On 08/04/12 14:31, Tom Boutell wrote:
> This is an attempt to protect people who have written inherently insecure
> code anyway. One should never do a dynamic require to any untrusted location,
> if ever at all, yes?
>
Obviously. But that include vulnerabilty seems a precondition to the
scenari
On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki wrote:
> Hi,
>
> The only valid reason for removing security.
>
>
I disagree here.
What you are talking about here is
https://www.owasp.org/index.php/Unrestricted_File_Upload
So a malicious user can upload a file containing php code and fire a
reques
The only benefit of ' wrote:
> Hi,
>
> 2012/4/9 Arvids Godjuks :
> > And you get same issues that existed with magic quotes, register
> variables,
> > safe mode and other optional stuff that was required to run application
> when
> > set specificaly and it would break if something set differently.
Hi,
2012/4/9 Arvids Godjuks :
> And you get same issues that existed with magic quotes, register variables,
> safe mode and other optional stuff that was required to run application when
> set specificaly and it would break if something set differently. PHP just
> got rid of it and you want to int
And you get same issues that existed with magic quotes, register variables,
safe mode and other optional stuff that was required to run application
when set specificaly and it would break if something set differently. PHP
just got rid of it and you want to introduce a new optional feature that
will
Hi,
2012/4/9 Tom Boutell :
> Vulnerabilities in include/require should be fixed there, IMHO, not by
> limiting the feature set of the language.
I'm not insisting to remove embed feature, but give a option
for programmers/administrators for better security.
If one is comfortable with current beha
Vulnerabilities in include/require should be fixed there, IMHO, not by
limiting the feature set of the language.
On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/9 Arvids Godjuks :
>> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki написал:
>>
>>> 2012/4/8 Ángel González :
>>>
Hi,
2012/4/9 Arvids Godjuks :
> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki написал:
>
>> 2012/4/8 Ángel González :
>> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
>> >> Hi,
>> >>
>> >> The only valid reason for removing > >> security.
>> >>
>> >> Since the null byte detection for fopen, remote/lo
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki написал:
> 2012/4/8 Ángel González :
> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
> >> Hi,
> >>
> >> The only valid reason for removing >> security.
> >>
> >> Since the null byte detection for fopen, remote/local script inclusion
> >> became much hard
2012/4/9 Yasuo Ohgaki :
> Hi,
>
> You are missing my points.
>
> 2012/4/8 Ángel González :
>> 2012/4/8, Yasuo Ohgaki:
>>> 2012/4/8 Ángel González :
How does it help security?
If any, requiring '>>> out malicious files on apps with uploads in case there's a local
inclusion vulnerabili
Hi,
You are missing my points.
2012/4/8 Ángel González :
> 2012/4/8, Yasuo Ohgaki:
>> 2012/4/8 Ángel González :
>>> How does it help security?
>>> If any, requiring '>> out malicious files on apps with uploads in case there's a local
>>> inclusion vulnerability somewhere.
>>>
>> Attackers may inj
This is an attempt to protect people who have written inherently insecure code
anyway. One should never do a dynamic require to any untrusted location, if
ever at all, yes?
Sent from my iPhone
On Apr 8, 2012, at 8:00 AM, Ángel González wrote:
> 2012/4/8, Yasuo Ohgaki:
>> 2012/4/8 Ángel Gonzá
2012/4/8, Yasuo Ohgaki:
> 2012/4/8 Ángel González :
>> How does it help security?
>> If any, requiring '> out malicious files on apps with uploads in case there's a local
>> inclusion vulnerability somewhere.
>>
> Attackers may inject PHP script almost anything/anywhere since
> PHP code may be embe
2012/4/8 Ángel González :
> On 07/04/12 22:48, Yasuo Ohgaki wrote:
>> Hi,
>>
>> The only valid reason for removing > security.
>>
>> Since the null byte detection for fopen, remote/local script inclusion
>> became much harder than before. However, it's still possible and very
>> easy compare to oth
While anything even resembling censorship naturally makes me cringe, it is
a reasonable expectation I think that this list be a place where people can
suggest ideas without being called "stupid" and childishly berated.
Bullying, it could be argued, is also a form of censorship.
So despite my insti
On 07/04/12 22:48, Yasuo Ohgaki wrote:
> Hi,
>
> The only valid reason for removing security.
>
> Since the null byte detection for fopen, remote/local script inclusion
> became much harder than before. However, it's still possible and very
> easy compare to other languages. Script execution is cr
Hi,
The only valid reason for removing :
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change.
On 04/07/2012 01:07 PM, Ángel González wrote:
> On 07/04/12 19:29, Rasmus Lerdorf wrote:
>> On 04/07/2012 10:23 AM, Ángel González wrote:
>>
>>> And I like the idea of providing a function for auto escaping > Turn on your default input filter and all data that comes from the user
>> will automatica
On 07/04/12 19:29, Rasmus Lerdorf wrote:
> On 04/07/2012 10:23 AM, Ángel González wrote:
>
>> And I like the idea of providing a function for auto escaping Turn on your default input filter and all data that comes from the user
> will automatically be escaped.
>
> -Rasmus
I'm not interested in fil
I will. And thanks for your work maintaining gd- I should have mentioned that
earlier.
Sent from my iPhone
On Apr 7, 2012, at 12:47 PM, Pierre Joye wrote:
> hi Tom,
>
>
> On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell wrote:
>> Now that the flamewar has died down a little I'd like to try to ha
On Apr 7, 2012, at 15:26, Tom Boutell wrote:
> * If the CLI sees a .phpc file extension, the parser starts out in PHP
> mode (no opening into HTML mode after that with ?>.
>
> * If a require/include statement sees a .phpc file extension, the
> parser starts out in PHP mode.
I don't think such
On 04/07/2012 10:23 AM, Ángel González wrote:
> And I like the idea of providing a function for auto escaping http://www.php.net/unsub.php
On 07/04/12 16:56, John Bafford wrote:
> On Apr 7, 2012, at 10:00, Tom Boutell wrote:
>> .phpc is then just a convention for naming PHP files that start out
>> with code - a convention that autoloaders should respect, just as they
>> now respect the .php convention. "The user asked for the Monkey c
On 07/04/12 17:22, John Bafford wrote:
> On Apr 7, 2012, at 10:53, John Crenshaw wrote:
>> What if you have just ONE function with a variety of options? Something like:
>>
>> execute_file('path/to/foo.php', array(
>>'require'=>true,
>>'once'=>true,
>>'begin_code'=>'>'shorttags'=>arr
Hi Tom
2012/4/7 Tom Boutell :
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change. The parser
hi Tom,
On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell wrote:
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
Please put that in a R
On Apr 7, 2012, at 9:04 AM, Tom Boutell wrote:
> A thoughtful suggestion. But the trouble with a php.ini setting is that you
> can't tell if it is enabled when writing your class file. That makes it
> impossible to write portable libraries. The keywords would always be
> available. And no one
A thoughtful suggestion. But the trouble with a php.ini setting is that you
can't tell if it is enabled when writing your class file. That makes it
impossible to write portable libraries. The keywords would always be available.
And no one has to type them outside of an auto loader (:
Sent from
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> ...
Tom, sorry! For some reason I thought Tony :). On my phone... Not as
intuitive as my desktop...
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
>
> .phpc is then
He's done.
On 04/07/2012 08:27 AM, Kiall Mac Innes wrote:
> On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans wrote:
>
>> You repeatly call people stupid, or "like a child" or "what terrible
>> happened in your life" and that is *not* allowed behaviour here. If you
>> (or anyone else for that matte
On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans wrote:
> You repeatly call people stupid, or "like a child" or "what terrible
> happened in your life" and that is *not* allowed behaviour here. If you
> (or anyone else for that matter) can't refrain from that, you have no
> place on this list.
>
>
On Apr 7, 2012, at 10:53, John Crenshaw wrote:
> I don't like this, but it's closer. I hate the idea of adding a whole mess of
> one-off functions just to support a single coding style feature that doesn't
> seem to have very much support. There are a variety of other ideas that have
> been fl
On Sat, 7 Apr 2012, Reindl Harald wrote:
> Am 07.04.2012 16:07, schrieb Derick Rethans:
> > On Sat, 7 Apr 2012, Reindl Harald wrote:
> >
> >> and no the world is not turning around you or even around PHP
> >
> > I will once more suggest you tune down your language on the
> > mailinglists. It's
Am 07.04.2012 16:23, schrieb Tom Boutell:
> On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald wrote:
>> why do you simply not realize that you have way too few knowledge
>> and tchnical education to partly understand the side effects
>> small changes in a general behavior are having
>
> *Sigh*
>
>
On Apr 7, 2012, at 10:00, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
Those might be ni
> From: Tom Boutell [mailto:t...@punkave.com]
>
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start out in
> PHP mode.
>
I don't like
On 07/04/12 16:06, Reindl Harald wrote:
> Am 07.04.2012 16:00, schrieb Tom Boutell:
>> That's a good point too.
>>
>> I think this is a better proposal:
>>
>> include_code, require_code, and require_code_once would work just like
>> include, require and require_once, except that the parser would st
Am 07.04.2012 16:07, schrieb Derick Rethans:
> On Sat, 7 Apr 2012, Reindl Harald wrote:
>
>> and no the world is not turning around you or even around PHP
>
> I will once more suggest you tune down your language on the
> mailinglists. It's often rude and offensive. Let this be your last
> war
On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald wrote:
>
>
> would you please leave this world in peace?
>
> what do you think happens with hundret thousands of existing
> include-files out there which are containing only HTML?
Nothing happens to them whatsoever. They work exactly the way they did
On Sat, Apr 07, 2012 at 04:06:17PM +0200, Reindl Harald wrote:
>
>
> Am 07.04.2012 16:00, schrieb Tom Boutell:
> > That's a good point too.
> >
> > I think this is a better proposal:
> >
> > include_code, require_code, and require_code_once would work just like
> > include, require and require_
On Sat, 7 Apr 2012, Reindl Harald wrote:
> and no the world is not turning around you or even around PHP
I will once more suggest you tune down your language on the
mailinglists. It's often rude and offensive. Let this be your last
warning.
cheers,
Derick
--
PHP Internals - PHP Runtime Devel
Am 07.04.2012 16:00, schrieb Tom Boutell:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
would you please lea
That's a good point too.
I think this is a better proposal:
include_code, require_code, and require_code_once would work just like
include, require and require_once, except that the parser would start
out in PHP mode.
.phpc is then just a convention for naming PHP files that start out
with code
On Apr 7, 2012, at 09:39, Tom Boutell wrote:
>> From the viewpoint of someone writing reusable classes, the need to
> start with above it is a silly annoyance they don't experience with other tools.
>
> That said, you are making valid points, I'm not convinced myself that
> "file extensions" ne
Am 07.04.2012 15:43, schrieb Stuart Dallas:
> On 7 Apr 2012, at 14:39, Tom Boutell wrote:
>
>> From the viewpoint of someone writing reusable classes, the need to
>> start with > above it is a silly annoyance they don't experience with other tools.
>>
>> That said, you are making valid points, I
wrote:
> you are not making valid points
> you are proposing DANGEROUS changes!
>
> what happens if PHP 5.4.x will follow your wishes
> (what never will happen) and your file without
> php-version?
>
> what you also do not realize is that the world is not turning
> around your windows machine - i
you are not making valid points
you are proposing DANGEROUS changes!
what happens if PHP 5.4.x will follow your wishes
(what never will happen) and your file without
From the viewpoint of someone writing reusable classes, the need to
> start with above it is a silly annoyance they don't experien
On 7 Apr 2012, at 14:39, Tom Boutell wrote:
> From the viewpoint of someone writing reusable classes, the need to
> start with above it is a silly annoyance they don't experience with other tools.
>
> That said, you are making valid points, I'm not convinced myself that
> "file extensions" neces
>From the viewpoint of someone writing reusable classes, the need to
start with wrote:
> Hello, Tom...
>
> Are you seriously that bothered with ' you serious when talking changing reguire/include behaviour just to satisfy
> your wish?
>
> To be also serious, I would mention the possibility of incl
Hello, Tom...
Are you seriously that bothered with '
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doe
On Sat, Apr 07, 2012 at 09:26:01AM -0400, Tom Boutell wrote:
> Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default beha
I'm +1 on this.
Now that the flamewar has died down a little I'd like to try to have a
> civil discussion about this idea - *without* my admittedly
> inflammatory suggestion to kill
> So here is what I am seriously suggesting:
>
> * The default behavior doesn't change. The parser starts out in
Now that the flamewar has died down a little I'd like to try to have a
civil discussion about this idea - *without* my admittedly
inflammatory suggestion to kill .
* If a require/include statement sees a .phpc file extension, the
parser starts out in PHP mode.
* If mod_php and FPM are able to see
69 matches
Mail list logo
