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
Hi Laruence,
I think your patch is right, but I've never seen this problem before.
Is it related to your own extension? What does it do? Why we didn't see
this problem with other extensions?
Finally, I think that such persistent HashTables must be very rare, so
introducing additional check wo
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 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
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.
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
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
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
pro/con's..
It would be worth asking them for their experience...
T
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
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
.phpp would be fine.
.phpp code needs to be able to interoperate with .php templates, otherwise one
can't supply reusable libraries that implement generic algorithms without
surprises for those who integrate them in older projects.
Sent from my iPhone
On Apr 9, 2012, at 1:16 AM, Kris Craig wr
On Mon, Apr 9, 2012 at 3:09 PM, Dmitry Stogov wrote:
> Hi Laruence,
>
> I think your patch is right, but I've never seen this problem before.
> Is it related to your own extension? What does it do? Why we didn't see this
> problem with other extensions?
a persistent configure extension, it loads
I think separating these rfcs makes sense, thanks.
Sent from my iPhone
On Apr 9, 2012, at 2:17 AM, Yasuo Ohgaki wrote:
> Hi Tom,
>
> It's better to distinguish security related issue and others.
> Therefore, I listed Moriyoshi's proposal to RFC list and put
> my proposal in it. His proposal is
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 would like to clarify what this RFC actually says. Let's try to keep
this thread to the pros and cons of this specific proposal.
The following new keyword would be introduced:
require_path
This keyword has two parameters of which the second is optional. The
first parameter is the path (filenam
On 09/04/12 13:29, Tom Boutell wrote:
> I would like to clarify what this RFC actually says. Let's try to keep
> this thread to the pros and cons of this specific proposal.
>
> The following new keyword would be introduced:
>
> require_path
I don't like the keyword name. Too confusing with the incl
Option 1: Introduce require_path
I think require_code is a better name. Parm 1 isn't a path, it is a
file, so require_path seems wrong to me.
I'd prefer a 'start in code mode' optional second parameter to
include[_once] and require[_once].
Option 2: Filename Convention
The PHP engine sh
On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer wrote:
>
> Option 1: Introduce require_path
>
> I think require_code is a better name. Parm 1 isn't a path, it is a file,
> so require_path seems wrong to me.
Yeah, you're not the first to say this. require_file and require_code
have both been suggeste
IDE creators will definitely be excited with this new feature.
2012/4/9 Tom Boutell
> On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer
> wrote:
> >
> > Option 1: Introduce require_path
> >
> > I think require_code is a better name. Parm 1 isn't a path, it is a
> file,
> > so require_path seems wron
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:-)
I think I've shown you the route by that [1] project, and
There has been talk of making PHP a better templating language. After
all, it did start out there.
Folks have mentioned ideas like making it easier to output escaped
content, etc., but these are all hardcoded solutions. And one of the
biggest problems with PHP as a template language is that when b
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
Tom,
As I've said before I don't think new keywords are the answer. They
will just pollute the language even further.
I also don't think an ini setting is a bad thing either. It is often
used in PHP as a way to transition from way of doing things to
another. First you introduce it with it being o
@ before a function call will simply turn off error reporting for that
particular call. You will have to choose a different syntax. And, yes,
personally, I am against this suggestion. There are template engines that
already do similar things (Blitz, for instance) without requiring changes
in the la
On Mon, Apr 9, 2012 at 5:10 PM, Tom Boutell wrote:
> What if PHP supported a short tag for calling a method of $this?
>
> Then one could write:
>
>
A big -1 on this.
If you want to roll your own template syntax, just do so. It's not
that hard to run a quick str_replace('',
$code) over the templ
-1.
PHP doesn't need more magic.
On Mon, Apr 9, 2012 at 4:53 PM, Nikita Popov wrote:
> On Mon, Apr 9, 2012 at 5:10 PM, Tom Boutell wrote:
> > What if PHP supported a short tag for calling a method of $this?
> >
> > Then one could write:
> >
> >
>
> A big -1 on this.
>
> If you want to roll you
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
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 wrote:
> -1.
>
> PHP doesn't need more magic.
>
> On Mon, Apr 9, 2012 at 4:53 PM, Nikita Popov
> wrote:
>>
>> On Mon, Apr 9, 2012 at 5:10 PM, Tom Boutell wrote:
>> > What
On 04/09/2012 05:10 PM, Tom Boutell wrote:
What if PHP supported a short tag for calling a method of $this?
Then one could write:
And 'escape' could be upgraded and modified as needed in an object
oriented way without the need to type many times.
You might be able to achieve this using the
It sounds like you are proposing to gradually kill the use of PHP for
templating entirely, which I don't think is something people would
vote for. I sometimes use perfectly good older frameworks that do use
.php files for templating in a reasonable way, and I'm one of the
advocates for migrating aw
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
On Apr 9, 2012, at 9:16 AM, Tom Boutell wrote:
> It sounds like you are proposing to gradually kill the use of PHP for
> templating entirely, which I don't think is something people would
> vote for.
I'm not saying that at all. I'm saying that PHP code should be clearly
separated from template c
I see what you're saying, but you're proposing a new keyword to
include code that does what plain old 'require' does now (assuming
it's not a nice clean class file that is being included). Which means
that valid code today is busted code once this feature comes out. That
seems like a very hard sell
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.
On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell wrote:
> I see what you're saying, but you're proposing a ne
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]
>
> 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 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.
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 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
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
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
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
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
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,
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
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/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
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
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
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
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,
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: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!
>> 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 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
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
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
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!
>
>>> 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
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 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!
> 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)
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
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
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
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
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 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
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
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 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
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 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
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
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
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 (:
>
>
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
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
> 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
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
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
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: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
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
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
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!
> 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.
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
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
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
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 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 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
> 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
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
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
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
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
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
I have a question - does it really bother people to type the
1 - 100 of 136 matches
Mail list logo
