On Wed, April 11, 2012 12:25 am, Stas Malyshev wrote:
Hi!
I'm sure you have seen the same code in JSON hijack countermeasure.
while(1){}
I think you misunderstood what I means. What I meant is you can inject
code without ? the same way you can inject code with ?, so where's
the
On 2012-04-13, David Muir davidkm...@gmail.com wrote:
On 13/04/12 14:55, Stas Malyshev wrote:
If this is a pecl module library developers cannot use it and trust
that on php 5.n, it just works. That would fork the language in an
undesirable way. It should be a core feature, no ini flag,
Wouldn't this be a significant performance hit when multiplied by
every class file in a project?
On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2012-04-13, David Muir davidkm...@gmail.com wrote:
On 13/04/12 14:55, Stas Malyshev wrote:
If this is a
(I'm referring to the streams approach. You seem to be suggesting a
PECL extension with a fallback provision. It still sounds like
something no one will seriously use because they can't count on it
running fast on a given box, although it is a clever workaround.)
On Fri, Apr 13, 2012 at 1:28 PM,
On 2012-04-13, Tom Boutell t...@punkave.com wrote:
Wouldn't this be a significant performance hit when multiplied by
every class file in a project?
Typically, you'd cache the end-result of pre-processing, so that
subsequent requests can use the processed results. In other words, you
incur the
Hi,
2012/4/14 Matthew Weier O'Phinney weierophin...@php.net:
On 2012-04-13, Tom Boutell t...@punkave.com wrote:
Wouldn't this be a significant performance hit when multiplied by
every class file in a project?
Typically, you'd cache the end-result of pre-processing, so that
subsequent
Hi,
2012/4/14 Yasuo Ohgaki yohg...@ohgaki.net:
Hi,
2012/4/14 Matthew Weier O'Phinney weierophin...@php.net:
On 2012-04-13, Tom Boutell t...@punkave.com wrote:
Wouldn't this be a significant performance hit when multiplied by
every class file in a project?
Typically, you'd cache the
Hi,
2012/4/11 Stas Malyshev smalys...@sugarcrm.com:
Hi!
If attacker can inject code at the beginning or make valid syntax
at the beginning, they can succeed injection. This is true not
only for PHP, but also Ruby/Perl/Python.
This is exactly my point. Since it does not solve the problem
Hey Rasmus,
Here are my thoughts:
On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 04/11/2012 12:59 AM, Stas Malyshev wrote:
Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security
On 04/11/2012 02:10 PM, Yasuo Ohgaki wrote:
It's also very easy to write backward compatible code also.
The 3 lines of changes to adopt this RFC do not bother
old PHP.
No compatibility issue for existing code
Just 3 lines of change to adopt
Full backward compatibility for OLD systems
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki
Hi,
It seems motivation of this RFC is better to be stated.
Motivation to have this RFC is
1. File Includes is fatal security breach.
2. The reason why PHP is unsecure to File Include than other language is
11 matches
Mail list logo
