On Mon, Apr 9, 2012 at 10:35 PM, Luke Scott wrote:
> On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki wrote:
>
> > I strongly discourage settingallow_url_include=on, too.
>
> Good.
>
> > Enabling it only when it is needed is okay.
>
> No it's not. There is no reason to do so other than backwards
> comp
On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki wrote:
> I strongly discourage settingallow_url_include=on, too.
Good.
> Enabling it only when it is needed is okay.
No it's not. There is no reason to do so other than backwards
compatibility for very old code.
> I think you are concerned about secur
Hi,
2012/4/10 Luke Scott :
> On Apr 9, 2012, at 9:08 PM, Yasuo Ohgaki wrote:
>
>>> I would actually suggest that require/include stop supporting remote
>>> files all together. But that can be a different RFC.
>>>
>>> This "security problem" isn't a problem with common sense.
>>
>> Requiring/Inclu
On 4/9/12 3:21 PM, Stas Malyshev wrote:
Hi!
I would like to see clarity on when fixes have been merged to the RC
branch (git emails are still a bit hard to grok). It would help to
have early communication about fixes you have decided against so we
can argue their merits and so we don't assum
Hi,
2012/4/10 Chris Stockton :
>> People does this should not security issues, though.
I should have written
People does this should know security issues, though.
then you might make sense with it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailin
On Apr 9, 2012, at 9:08 PM, Yasuo Ohgaki wrote:
>> I would actually suggest that require/include stop supporting remote
>> files all together. But that can be a different RFC.
>>
>> This "security problem" isn't a problem with common sense.
>
> Requiring/Including remote file is not bad, just lik
Hi,
2012/4/10 Chris Stockton :
> Hello,
>
> On Mon, Apr 9, 2012 at 8:25 PM, Yasuo Ohgaki wrote:
>> Hi,
>>
>> There is valid usage for allow_url_include=on.
>>
>> For instance, if both server and client is PHP, we could use var_export()
>> to receive messages.
>>
>> Client
>>
>> > include('ht
Hello,
On Mon, Apr 9, 2012 at 8:25 PM, Yasuo Ohgaki wrote:
> Hi,
>
> There is valid usage for allow_url_include=on.
>
> For instance, if both server and client is PHP, we could use var_export()
> to receive messages.
>
> Client
>
> include('http://server/send_my_data.php');
> ?>
>
>
>
Hi,
2012/4/10 Luke Scott :
>> It's easy to say "write correct code. don't write stupid code", but
>> we cannot enforce it in real world.
>>
>> I'm concerning both arbitrarily script execution and arbitrarily
>> information disclosure. Good example is LFI and SQL injection
>> attack.
>
> Uh yeah t
> It's easy to say "write correct code. don't write stupid code", but
> we cannot enforce it in real world.
>
> I'm concerning both arbitrarily script execution and arbitrarily
> information disclosure. Good example is LFI and SQL injection
> attack.
Uh yeah there is. I won't employ someone who i
On Apr 9, 2012, at 8:26 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
>> On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
>>
>>> Please don't repeat mistakes for allow_url_include or allow_url_include.
>>> If admin would like to enforce programmer not to change php.ini.
>>> They should
Hi,
2012/4/10 Luke Scott :
> On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
>
>> Please don't repeat mistakes for allow_url_include or allow_url_include.
>> If admin would like to enforce programmer not to change php.ini.
>> They should use Apache httpd and admin_flag/admin_value.
>>
>> Programm
Hi,
2012/4/10 Stas Malyshev :
> Hi!
>
>> LFI risk is unique to PHP. The cause of risk is mandatory embedded script.
>
> No it's not. If you write Python code that loads code from random file
> and evaluates it, it will be "vulnerability in Python". If you write in
> in Bash, it would be "vulnerabi
Hi,
2012/4/10 Luke Scott :
> On Apr 9, 2012, at 7:44 PM, Yasuo Ohgaki wrote:
>
>> Hi,
>>
>> 2012/4/10 Luke Scott :
>> That said, allowing the skipping of an initial > the file probably wouldn't be a big deal to implement in code mode.
>
>
> OK. If you can agree to this then I'
Hi!
> LFI risk is unique to PHP. The cause of risk is mandatory embedded script.
No it's not. If you write Python code that loads code from random file
and evaluates it, it will be "vulnerability in Python". If you write in
in Bash, it would be "vulnerability in bash". If you write it in C, it
wi
On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
> Please don't repeat mistakes for allow_url_include or allow_url_include.
> If admin would like to enforce programmer not to change php.ini.
> They should use Apache httpd and admin_flag/admin_value.
>
> Programmers should have as much control as p
Hi!
> It's a design vulnerability. It is not has to be attack-able security hole
> without broken code. There are many security issues and countermeasure
> like this. e.g. register globals in PHP, stack smashing attack in C, etc.
It's not stack smashing. It's like saying because you can call exte
Hi,
2012/4/10 Luke Scott :
> On Apr 9, 2012, at 6:22 PM, Kris Craig wrote:
>
> If the default is "template mode" and the "> top) in "code" mode there shouldn't be any problems.
>>
>> We don't need to change or leave out the tag entirely.
>>
>> Is there a problem with people being able to choose "
On Apr 9, 2012, at 7:44 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
> That said, allowing the skipping of an initial the file probably wouldn't be a big deal to implement in code mode.
OK. If you can agree to this then I'm good. Perhaps only allow white space
There is probably a performance hit there when your view offers a lot
of methods, but that is nevertheless a very clever solution (:
On Mon, Apr 9, 2012 at 9:51 PM, Jared Williams
wrote:
>> -Original Message-
>> From: Tom Boutell [mailto:t...@punkave.com]
>> Sent: 09 April 2012 16:10
>> T
Hi,
2012/4/10 Luke Scott :
That said, allowing the skipping of an initial >>> the file probably wouldn't be a big deal to implement in code mode.
>>>
>>>
>>> OK. If you can agree to this then I'm good. Perhaps only allow white space
>>> before it (which is ignored - everything else throws a p
On Apr 9, 2012, at 6:22 PM, Kris Craig wrote:
If the default is "template mode" and the " top) in "code" mode there shouldn't be any problems.
>
> We don't need to change or leave out the tag entirely.
>
> Is there a problem with people being able to choose "template mode" or
> "code mode" as the
Hi,
2012/4/10 Kris Craig :
>
>
> On Mon, Apr 9, 2012 at 7:02 PM, Yasuo Ohgaki wrote:
>>
>> 2012/4/10 Kris Craig :
>> > On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott wrote:
>> >
>> >> On 4/9/12 5:02 PM, "Kris Craig" wrote:
>> >>
>> >> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:
>> >> >
>>
On Apr 9, 2012, at 6:22 PM, Tom Boutell wrote:
> On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott wrote:
>> Given that an autoloader just has the class name with the attached
>> namespace, how is it to know whether or not to load a .php file or a .phpc
>> file? I'm not going to add a stat in my autolo
On Mon, Apr 9, 2012 at 7:02 PM, Yasuo Ohgaki wrote:
> 2012/4/10 Kris Craig :
> > On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott wrote:
> >
> >> On 4/9/12 5:02 PM, "Kris Craig" wrote:
> >>
> >> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:
> >> >
> >> >> Let me be very clear about that... I a
2012/4/10 Kris Craig :
> On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott wrote:
>
>> On 4/9/12 5:02 PM, "Kris Craig" wrote:
>>
>> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:
>> >
>> >> Let me be very clear about that... I am NOT proposing that > >> the top be mandatory in a file loaded in cod
> -Original Message-
> From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
> Sent: 10 April 2012 02:35
> To: internals@lists.php.net
> Subject: [PHP-DEV] Traits and memory size
>
> Hi!
>
> Just a quick question about traits.
>
> During the flattening process, is a copy made of t
> -Original Message-
> From: Tom Boutell [mailto:t...@punkave.com]
> Sent: 09 April 2012 16:10
> To: PHP Internals
> Subject: [PHP-DEV] Object oriented page templates in PHP
>
> There has been talk of making PHP a better templating
> language. After all, it did start out there.
>
> Folk
Hi!
Just a quick question about traits.
During the flattening process, is a copy made of the trait code (or
bytecode or whatever)?
So, if I have
trait A {
// a bunch of methods
}
class B {
use A;
}
class C {
use A;
}
class D {
use A;
}
will I have four copies of A because it has b
On Mon, Apr 9, 2012 at 6:15 PM, Luke Scott wrote:
> On 4/9/12 5:02 PM, "Kris Craig" wrote:
>
> >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:
> >
> >> Let me be very clear about that... I am NOT proposing that >> the top be mandatory in a file loaded in code mode! I don't want to
> >> typ
On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott wrote:
> Given that an autoloader just has the class name with the attached
> namespace, how is it to know whether or not to load a .php file or a .phpc
> file? I'm not going to add a stat in my autoloader (file_exists) just to
> check for the existence o
On 4/9/12 5:02 PM, "Kris Craig" wrote:
>On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:
>
>> Let me be very clear about that... I am NOT proposing that > the top be mandatory in a file loaded in code mode! I don't want to
>> type it ever again outside of a template file, personally. See the
>
On 4/9/12 5:38 PM, "Tom Boutell" wrote:
>On Mon, Apr 9, 2012 at 8:27 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 4:47 PM, "Tom Boutell" wrote:
>>
>>>Let me be very clear about that... I am NOT proposing that >>the top be mandatory in a file loaded in code mode! I don't want to
>>>type it ever
On Mon, Apr 9, 2012 at 8:27 PM, Luke Scott wrote:
> Tom,
>
> On 4/9/12 4:47 PM, "Tom Boutell" wrote:
>
>>Let me be very clear about that... I am NOT proposing that >the top be mandatory in a file loaded in code mode! I don't want to
>>type it ever again outside of a template file, personally. See
Tom,
On 4/9/12 4:47 PM, "Tom Boutell" wrote:
>Let me be very clear about that... I am NOT proposing that the top be mandatory in a file loaded in code mode! I don't want to
>type it ever again outside of a template file, personally. See the
>title of the RFC.
See below.
>
>On Mon, Apr 9, 2012
Hi,
2012/4/10 Arvids Godjuks :
> I have a question - does it really bother people to type the kind*a don't do that for how long, 4-5 years? Every IDE and every damn
> decent code editor does that for you. Hell, they even can create a template
> file for you!
> Some arguments are just plain silly.
I have a question - does it really bother people to type the
On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:
> Let me be very clear about that... I am NOT proposing that the top be mandatory in a file loaded in code mode! I don't want to
> type it ever again outside of a template file, personally. See the
> title of the RFC.
>
But again, how then do y
Hi,
I forgot to answer a question.
2012/4/10 Yasuo Ohgaki :
> Hi,
>
> 2012/4/10 Stas Malyshev :
>> Hi!
>>
>>> 1. Find FLI vulnerable application.
>>> 2. Find a way to inject $_SESSION
>>> 3. Use session file to execute arbitrary PHP code.
>>
>> So, you assume you have broken application with no s
Let me be very clear about that... I am NOT proposing that wrote:
> On 4/9/12 3:53 PM, "Tom Boutell" wrote:
>
>>I see why you want to allow >mode,' rather than disallowed in code mode. But your purpose is to
>>allow legacy code to be autoloaded without knowing in advance whether
>>it starts with
On Mon, Apr 9, 2012 at 6:54 PM, Kris Craig wrote:
> Again though, the problem here is that you're relying on the including
> script to determine whether a PHP script is pure or not; i.e. this approach
> leaves no way for that to be determined in the file itself. For example, I
> can see perfectly
Hi,
2012/4/10 Stas Malyshev :
> Hi!
>
>> 1. Find FLI vulnerable application.
>> 2. Find a way to inject $_SESSION
>> 3. Use session file to execute arbitrary PHP code.
>
> So, you assume you have broken application with no security AND it
> allows you to inject arbitrary data in the session (which
> I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
> but the implementation is quite different.
>
> ...
>
> Anyone know what the problem could be?
>
> Luke
I figured out that v8 was being compiled in 32 bit mode... Apparently it
thinks "native" means 32 bit... Recom
> On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>>
>>> >My original goal was to stop typing >> >includes at the top. I think it's entirely reasonable to achieve it
>>> >with an option to the require keywords for this purpose and a namin
On Fri, Mar 30, 2012 at 4:06 AM, Yasuo Ohgaki wrote:
> Hi,
>
> I also would like to remove date from them.
> It seems --no-generation-date is the option for that.
*push*
Would be really nice to add this. The constantly changed files are a
bit annoying :)
Nikita
--
PHP Internals - PHP Runtime
On 4/9/12 3:53 PM, "Tom Boutell" wrote:
>I see why you want to allow mode,' rather than disallowed in code mode. But your purpose is to
>allow legacy code to be autoloaded without knowing in advance whether
>it starts with
>But that would probably lead in practice to the use of a single file
>ex
On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott wrote:
> Tom,
>
> On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>
> >My original goal was to stop typing >includes at the top. I think it's entirely reasonable to achieve it
> >with an option to the require keywords for this purpose and a naming
> >conventio
I see why you want to allow wrote:
> Tom,
>
> On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>
>>My original goal was to stop typing >includes at the top. I think it's entirely reasonable to achieve it
>>with an option to the require keywords for this purpose and a naming
>>convention to be followed by
Tom,
On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>My original goal was to stop typing includes at the top. I think it's entirely reasonable to achieve it
>with an option to the require keywords for this purpose and a naming
>convention to be followed by autoloaders. Keep in mind how rarely you
>have
Hi!
> I would like to see clarity on when fixes have been merged to the RC
> branch (git emails are still a bit hard to grok). It would help to
> have early communication about fixes you have decided against so we
> can argue their merits and so we don't assume you are planning to pick
> them up.
My original goal was to stop typing still seems unnecessary and perhaps divisive,
but if it were preferable to the majority to prohibit ?> in a pure
code file, I could live with that as long as classic PHP files are
also 100% supported and remain the default. I'm trying to craft a
broadly acceptab
Hi!
> My concern is that merge conflicts can occur when cherry-picking in this
> manner. It's just generally not a "best practices" approach when using
Which merge conflicts? Diff between 5.4 and 5.4.X will never be big
enough to have any conflicts. It's just 2 weeks of stable version code.
> c
On Mon, Apr 9, 2012 at 2:38 PM, Luke Scott wrote:
> > Obviously, it would need to be at the top of the PHP file (whitespace
> > notwithstanding). Since we don't want any BC breaks, we at very least
> need
> > it to start with " wasn't
> > mean to be parsed. So how about we keep it simple and ju
On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev wrote:
> Hi!
>
> > release candidates. I mean, we're still planning on having multiple
> > release candidates before an actual release, right? If so, then
>
> Not if we can avoid it. If we don't have critical bugs in RC1, we
> release it.
>
> > obvio
Hi!
> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then
Not if we can avoid it. If we don't have critical bugs in RC1, we
release it.
> obviously we'll need a way to commit those changes. If they're not made
>
On Mon, Apr 9, 2012 at 2:33 PM, Kiall Mac Innes wrote:
> On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig wrote:
>>
>> What I'm referring to is the same kind of bugfixes/etc that go into new
>> release candidates. I mean, we're still planning on having multiple
>> release candidates before an actual
I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
but the implementation is quite different.
I'm having trouble linking the v8 library to my extension. When I run a PHP
script via CLI I get:
dyld: lazy symbol binding failed: Symbol not found: __ZN2v86String3NewEPKci
> Obviously, it would need to be at the top of the PHP file (whitespace
> notwithstanding). Since we don't want any BC breaks, we at very least need
> it to start with " mean to be parsed. So how about we keep it simple and just use a single,
> " would be allowed after that.
> Anything before tha
On 04/08/2012 11:54 PM, Stas Malyshev wrote:
Hi!
5.4.1 will be the first release we're releasing using our new git setup.
I would like to refine a process that we used to have for releases and
make small tweaks hopefully to allow us more predictable release
schedule and faster releases.
What I
On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig wrote:
>
> What I'm referring to is the same kind of bugfixes/etc that go into new
> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then obviously
> we'll need a way to c
Lol true dat. You convinced me on the file extension, so as far as I can
tell that just leaves us with the tag itself as the viable approach. =)
--Kris
On Mon, Apr 9, 2012 at 2:24 PM, Tom Boutell wrote:
> I'm not sure you're wrong about this, but it's definitely an ironic
> suggestion (:
>
>
Stas,
On Mon, Apr 9, 2012 at 2:07 PM, Stas Malyshev wrote:
> Hi!
>
> > version of a "Release-x.xx" branch. I would suggest allowing commits on
> > that branch, but *only* if they're bugfixes or minor housekeeping. Each
>
> I don't want to do this, because this would very quickly lead us back to
I'm not sure you're wrong about this, but it's definitely an ironic
suggestion (:
On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig wrote:
>
>
> On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote:
>>
>> As others explained before the RFC was drafted, file extensions should
>> not be directly respected b
On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote:
> As others explained before the RFC was drafted, file extensions should
> not be directly respected by PHP because environments differ too much.
> Instead a convention, NOT enforced at the code level, would be
> published and encouraged: .phpc f
Hi!
> version of a "Release-x.xx" branch. I would suggest allowing commits on
> that branch, but *only* if they're bugfixes or minor housekeeping. Each
I don't want to do this, because this would very quickly lead us back to
old chaotic situation where people commit stuff at the last moment and
On Mon, Apr 9, 2012 at 1:58 PM, Rick WIdmer wrote:
> On 4/9/2012 2:41 PM, Kris Craig wrote:
>
>>
>>> Honestly, I would suggest just getting rid of "Option 1" altogether. It
>> would end up over-complicating this to such a degree that any usefulness
>> it
>> might serve would be considerably dimi
As others explained before the RFC was drafted, file extensions should
not be directly respected by PHP because environments differ too much.
Instead a convention, NOT enforced at the code level, would be
published and encouraged: .phpc for files that start out in PHP mode,
and .php for files that
On 4/9/2012 2:41 PM, Kris Craig wrote:
Honestly, I would suggest just getting rid of "Option 1" altogether. It
would end up over-complicating this to such a degree that any usefulness it
might serve would be considerably diminished.
As for embedded HTML, if you allow the ?> tag in these .php
On Mon, Apr 9, 2012 at 3:26 AM, Kiall Mac Innes wrote:
> This is a very similar process to what OpenStack uses, it seems to work
> well for them.
>
> They have a few guys on freenode in #openstack-infra that have shown
> themselves more than willing to go into detail about their setup and its
> p
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
Hello,
2012/4/9 Ángel González :
> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be great
>> considering the
Tom,
On Mon, Apr 9, 2012 at 1:20 PM, Yasuo Ohgaki wrote:
> Hi,
>
>
> 2012/4/10 Stas Malyshev :
> > Hi!
> >
> >>> I'm not sure I follow - which PHP vulnerability you are talking about?
> >>
> >> Local file includes. (LFI)
> >
> > I'm not sure I understand - where's the vulnerability?
> >
> >> The
Pierre,
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> Something I have been discussed in the past with a couple of persons
> is to have a mechanism to automatically instantiate objects on request
> start. That's not persistent objects but that could already boost a
> little it the base foot
Hi!
> 1. Find FLI vulnerable application.
> 2. Find a way to inject $_SESSION
> 3. Use session file to execute arbitrary PHP code.
So, you assume you have broken application with no security AND it
allows you to inject arbitrary data in the session (which probably means
broken authorization too)
On Apr 9, 2012, at 7:49 AM, Flavius Aspra wrote:
> On 04/07/2012 05:21 AM, Luke Scott wrote:
>> From what I've gathered thus far, it is impossible to do without copying the
>>
>> non-persistent memory into persistent memory, and then back again.
>
> Hi, glad to see you again StackOverflow user:-)
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,
Hi,
2012/4/10 Stas Malyshev :
> Hi!
>
>>> I'm not sure I follow - which PHP vulnerability you are talking about?
>>
>> Local file includes. (LFI)
>
> I'm not sure I understand - where's the vulnerability?
>
>> There is a null byte protection for LFI and I really like to the protection.
>> It's al
Tom,
On Apr 9, 2012, at 11:26 AM, Tom Boutell wrote:
> Ralph, you make good points. And Luke's opposition to my new keyword
> is probably going to be shared by others (like Chris who just chimed
> in).
>
> So the more I think about it, the more a set of constants that can be
> OR'd together is a
Hi,
2012/4/10 Stas Malyshev :
> Hi!
>
>> Tom's FRC is trying to introduce tag less PHP script.
>> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
>> IMHO, this change introduce more complexity and do not solve
>> any problem.
>
> I'm not sure I follow - which PHP vulnerability
On Apr 9, 2012, at 12:16 PM, "Ángel González" wrote:
> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be gre
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!
>> I'm not sure I follow - which PHP vulnerability you are talking about?
>
> Local file includes. (LFI)
I'm not sure I understand - where's the vulnerability?
> There is a null byte protection for LFI and I really like to the protection.
> It's also beneficial to other problems. However, i
On Apr 9, 2012, at 12:27 PM, "Ángel González" wrote:
> On 09/04/12 19:36, Luke Scott wrote:
>> On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
>>> Also, your objection - that 'require_code' is confusing - would most
>>> likely be an issue for a handful of people who write autoloaders.
>>> Those
Hi,
2012/4/10 Stas Malyshev :
> Hi!
>
>> Tom's FRC is trying to introduce tag less PHP script.
>> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
>> IMHO, this change introduce more complexity and do not solve
>> any problem.
>
> I'm not sure I follow - which PHP vulnerability
Hi!
> Tom's FRC is trying to introduce tag less PHP script.
> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
> IMHO, this change introduce more complexity and do not solve
> any problem.
I'm not sure I follow - which PHP vulnerability you are talking about?
--
Stanislav Mal
Hi,
Tom's FRC is trying to introduce tag less PHP script.
However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
IMHO, this change introduce more complexity and do not solve
any problem.
Making PHP tag a non mandatory would solve the well known
vulnerability and do not introduce any
On 09/04/12 19:36, Luke Scott wrote:
> On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
>> Also, your objection - that 'require_code' is confusing - would most
>> likely be an issue for a handful of people who write autoloaders.
>> Those clean PHP class files are almost always autoloaded.
> Not rea
autoloaders (as is typical in almost any project that would be
interested in .phpc files in the first place) rather than repeatedly
I am partial to file.p btw.
PHP without the HP, or Hypertext Pre-Processing- whatever that is! ;)
In fact, it could mean PHP without the Html Passthrough. You get
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
On 09/04/12 20:23, Chris Stockton wrote:
> Hello,
> Although I am not very interested in this feature, if it is
> implemented I like the idea of flags instead of introducing new
> keywords. Maintaining backwards compatibility would be great
> considering the benefit to the feature to be completely
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,
It definitely can be, yeah. I thought perhaps I'd hit on a way to do
it without as much redundant userland code to duplicate PHP's
templating behavior first and then make it better. But it's probably
not realistic to hardcode this one. No two people agree on templating
languages for long (:
On Mon
Ralph, you make good points. And Luke's opposition to my new keyword
is probably going to be shared by others (like Chris who just chimed
in).
So the more I think about it, the more a set of constants that can be
OR'd together is a better idea than my associative array proposal. And
it's best to k
Hello,
On Mon, Apr 9, 2012 at 10:43 AM, Ralph Schindler
wrote:
> Hey Tom,
>
> An idea, why not overload require/include with a second parameter that
> simply enforces an include mode. For example
>
> // in some autoloader (include, requires, and *_onces)
> include $pathToFile, INCLUDE_MODE_PHP_O
On Apr 9, 2012, at 10:44 AM, Ralph Schindler wrote:
> Hey Tom,
>
> An idea, why not overload require/include with a second parameter that simply
> enforces an include mode. For example
>
> // in some autoloader (include, requires, and *_onces)
> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>
> T
On 2012-04-09, Tom Boutell wrote:
> There's a reason I didn't try to kick this out as a fully formed RFC (:
>
> The choice of @ is a nonstarter, yes. I forgot that start code for PHP already so it is already valid PHP to write http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matth
Hey Tom,
An idea, why not overload require/include with a second parameter that
simply enforces an include mode. For example
// in some autoloader (include, requires, and *_onces)
include $pathToFile, INCLUDE_MODE_PHP_ONLY;
This would tell the parser/executor to start in PHP mode and never l
On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
> Also, your objection - that 'require_code' is confusing - would most
> likely be an issue for a handful of people who write autoloaders.
> Those clean PHP class files are almost always autoloaded.
Not really. Has nothing to do with auto loaders.
1 - 100 of 136 matches
Mail list logo
