Oops,
There are several language mistakes in previous mail, but this should be noted.
Prepared query is not a perfect SQL injection countermeasure as it
never escape nor
parameterize identifiers/SQL literals.
should be
Prepared query is not a perfect SQL injection countermeasure as it
never esc
Hi,
2012/4/11 Stas Malyshev :
> 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 that you
> are
Pierre,
On Tue, Apr 10, 2012 at 10:42 PM, Pierre Joye wrote:
> Kris,
>
> On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig wrote:
>
> > Given the number of RCs we've seen in the past, I remain skeptical that
> > your approach will prove sustainable. But I'd say let's just try it and
> > see how it g
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 that you
are presenting (I am still not convinced it's
Hi,
2012/4/11 Stas Malyshev :
> 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 improvement?
When template_mode=off, the only PHP tags that is allowed it
open t
Kris,
On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig wrote:
> Given the number of RCs we've seen in the past, I remain skeptical that
> your approach will prove sustainable. But I'd say let's just try it and
> see how it goes.
Saying that is totally ignoring the main point in the new way: Very
li
Hi!
On Wed, Apr 11, 2012 at 7:35 AM, Stas Malyshev wrote:
> Hi!
>
>> btw, It is not a realy issue as we won't use 5.4.1 tests to test the
>> release but 5.4's branch ones. Too many false positive.
>
> Who are we?
My team and I, as always when we refer to that.
> I'll definitely be using 5.4.1,
On Tue, Apr 10, 2012 at 10:31 PM, Pierre Joye wrote:
> hi Kris,
>
> On Wed, Apr 11, 2012 at 7:26 AM, Kris Craig wrote:
>
> > I must've missed that part. Who was it that said this would be a
> separate
> > forked project? If so, then yeah obviously it's not up to us one way or
> > another. And
Hi!
> btw, It is not a realy issue as we won't use 5.4.1 tests to test the
> release but 5.4's branch ones. Too many false positive.
Who are we? I'll definitely be using 5.4.1, since that's what I will be
releasing. There's no point in testing code different from one you're
releasing. Do you mean
hi Kris,
On Wed, Apr 11, 2012 at 7:26 AM, Kris Craig wrote:
> I must've missed that part. Who was it that said this would be a separate
> forked project? If so, then yeah obviously it's not up to us one way or
> another. And if he's just committing changes locally and/or pushing to an
> unmer
On Tue, Apr 10, 2012 at 10:12 PM, Stas Malyshev wrote:
> Hi!
>
> > Well, technically it's discussion /and/ vote. I know we've been wanting
> > to get out of the habit of "push first, ask later," which is precisely
> > what RFC helps us avoid. Personally, I think any commits for a
>
> Nobody's pu
hi Stas,
On Wed, Apr 11, 2012 at 12:24 AM, Stas Malyshev wrote:
> Hi!
>
>> However, as you won't merge the tests fixes either, we won't 5.4.1's
>> tests at all to valid the build (way too many false positive), it does
>> not really matter anymore.
>
> Wait, are we talking about new test fixes or
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 http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
Hi,
2012/4/11 Stas Malyshev :
> Hi!
>
>> https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now
>
> I'm sorry, but I do not understand how your proposal prevents LFI. Let's
> say you had this file kill.php:
>
> and you were afraid that somebody would write the code "include
> $_GET['foo
On Tue, Apr 10, 2012 at 8:35 PM, Tom Boutell wrote:
> On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig wrote:
> > This shouldn't be used to load libraries that dump raw HTML output! That
> > literally defeats the entire purpose. You're also assuming that all PHP
> > developers do 100% of their cod
Hi!
> Well, technically it's discussion /and/ vote. I know we've been wanting
> to get out of the habit of "push first, ask later," which is precisely
> what RFC helps us avoid. Personally, I think any commits for a
Nobody's pushing anything. We're talking about implementing it in a
fork, it's
Hi!
> https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now
I'm sorry, but I do not understand how your proposal prevents LFI. Let's
say you had this file kill.php:
http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig wrote:
> This shouldn't be used to load libraries that dump raw HTML output! That
> literally defeats the entire purpose. You're also assuming that all PHP
> developers do 100% of their coding through pre-existing frameworks.
Consider a .phpp file th
On Apr 10, 2012, at 6:59 PM, Tom Boutell wrote:
> On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott wrote:
>> - I would like to see an INCLUDE_SILENT method to prevent warnings from
>> being thrown with include/include_once statements. Currently doing
>> something like @include "/path/to/file.php"; no
Hi,
I've reorganized benefits in the RFC and would like to share
https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now
2012/4/11 John Crenshaw :
> From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki
>>
>> Hi,
>>
>> It seems motivation of this RFC is better to
On Tue, Apr 10, 2012 at 6:50 PM, Tom Boutell wrote:
> On Tue, Apr 10, 2012 at 7:59 PM, Kris Craig wrote:
> > Tom,
> >
> > Much better, though I'm still very troubled by allowing non-pure PHP
> code to
> > be mixed-in with pure PHP (by means of includes). The problem I have
> with
> > this, as a
On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott wrote:
> - I would like to see an INCLUDE_SILENT method to prevent warnings from
> being thrown with include/include_once statements. Currently doing
> something like @include "/path/to/file.php"; not only hides these
> warnings, but warnings/errors/noti
On Tue, Apr 10, 2012 at 7:59 PM, Kris Craig wrote:
> Tom,
>
> Much better, though I'm still very troubled by allowing non-pure PHP code to
> be mixed-in with pure PHP (by means of includes). The problem I have with
> this, as a developer, is that this means I can't really trust that what I
> will
On Tue, Apr 10, 2012 at 5:46 PM, Stas Malyshev wrote:
> Hi!
>
> > Err isn't this something that should go through the RFC process first?
> > I think it's a good idea and I'll probably vote for it, but as I
> > understand the RFC process was created specifically for stuff like this.
>
> One doesn't
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 langua
Hi!
> Err isn't this something that should go through the RFC process first?
> I think it's a good idea and I'll probably vote for it, but as I
> understand the RFC process was created specifically for stuff like this.
One doesn't preclude the other. Pull is code, RFC is discussion, they
can go
Hi,
As I stated already, the only valid reason to have pure php source
(non embed mode) would be better security than now.
Writing start tags is not burden. Unless it provides better security
like my proposal,
https://wiki.php.net/rfc/nophptags
I cannot support it.
Regards,
--
Yasuo Ohgaki
yo
Sent from my iPad
在 2012-4-11，6:54，Nikita Popov 写道：
> Hey internals!
>
> Currently the empty() language construct only works on variables. You
> can write if (empty($array)) but not empty if (empty(getSomeArray()).
>
> The original reason for this restriction probably is that - in a way -
> it "
Tom Boutell wrote:
* Forbade the use of ?> entirely in "pure PHP" files (without
restricting it at all in other PHP files)
Just as long as we can just carry on ignoring that rule if we want to ...
And I don't have to worry about major libraries slipping this in and screwing up
'old fashioned
On 4/10/12 4:53 PM, "Tom Boutell" wrote:
>Please see:
>
>https://wiki.php.net/rfc/source_files_without_opening_tag
>
>After following the discussion I have updated the RFC with the
>following major changes:
>
>* Forbade the use of ?> entirely in "pure PHP" files (without
>restricting it at all in
On Tue, Apr 10, 2012 at 4:51 PM, Stas Malyshev wrote:
> Hi!
>
> > Currently the empty() language construct only works on variables. You
> > can write if (empty($array)) but not empty if (empty(getSomeArray()).
> >
> > The original reason for this restriction probably is that - in a way -
> > it "d
Tom,
On Tue, Apr 10, 2012 at 4:53 PM, Tom Boutell wrote:
> Please see:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> After following the discussion I have updated the RFC with the
> following major changes:
>
> * Forbade the use of ?> entirely in "pure PHP" files (without
> r
Please see:
https://wiki.php.net/rfc/source_files_without_opening_tag
After following the discussion I have updated the RFC with the
following major changes:
* Forbade the use of ?> entirely in "pure PHP" files (without
restricting it at all in other PHP files)
* Replaced my original new requir
Hi!
> Currently the empty() language construct only works on variables. You
> can write if (empty($array)) but not empty if (empty(getSomeArray()).
>
> The original reason for this restriction probably is that - in a way -
> it "doesn't make sense" to pass anything but a variable to empty() as
>
2012/4/10 Johannes Schlüter
> On Tue, 2012-04-10 at 19:12 -0400, Jelle Zijlstra wrote:
> > I think this is a useful simplification of the language, removing an
> > unnecessary exception. Would it also make sense to make empty() into a
> > library function instead of a language construct? That wou
On Tue, 2012-04-10 at 19:12 -0400, Jelle Zijlstra wrote:
> I think this is a useful simplification of the language, removing an
> unnecessary exception. Would it also make sense to make empty() into a
> library function instead of a language construct? That would not
> result in
> any BC break as f
On Tue, Apr 10, 2012 at 4:12 PM, Jelle Zijlstra wrote:
> 2012/4/10 Nikita Popov
>
> > Hey internals!
> >
> > Currently the empty() language construct only works on variables. You
> > can write if (empty($array)) but not empty if (empty(getSomeArray()).
> >
> > The original reason for this restric
On Tue, Apr 10, 2012 at 3:46 PM, Stas Malyshev wrote:
> Hi!
>
> > I think my main point still stands: if the git emails are too obscure to
> > follow, let us know what goes in via email to internals.
> >
> > Do you want to bring the NEWS updating process into this discussion?
>
> Sure, though that
2012/4/10 Nikita Popov
> Hey internals!
>
> Currently the empty() language construct only works on variables. You
> can write if (empty($array)) but not empty if (empty(getSomeArray()).
>
> The original reason for this restriction probably is that - in a way -
> it "doesn't make sense" to pass an
Hey internals!
Currently the empty() language construct only works on variables. You
can write if (empty($array)) but not empty if (empty(getSomeArray()).
The original reason for this restriction probably is that - in a way -
it "doesn't make sense" to pass anything but a variable to empty() as
y
Hi!
> I think my main point still stands: if the git emails are too obscure to
> follow, let us know what goes in via email to internals.
>
> Do you want to bring the NEWS updating process into this discussion?
Sure, though that would be another discussion IMHO. In this discussion,
I just wanted
On Tue, Apr 10, 2012 at 9:20 AM, Adir Kuhn wrote:
> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link
> for
> you guys
"Ideally, don’t tell me anything!"
That's doable. No point trying to talk to a ranter.
-Ronabop
--
PHP Internals - PHP Runtime Develop
Hi!
> However, as you won't merge the tests fixes either, we won't 5.4.1's
> tests at all to valid the build (way too many false positive), it does
> not really matter anymore.
Wait, are we talking about new test fixes or about tests that are broken
in RC1 and need fixing? I was assuming it's the
Hi!
> Those were the files with svn:eol-style = LF in SVN. I've committed a
> change to .gitattributes that disables EOL conversion in those files. I'm
> told this could also be accomplished with a eol=lf attribute.
>
> See
> https://github.com/php/php-src/commit/112a476b683a634390b23fe7509
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 "Mandatory embed mode"
3. Non mandatory embed mode gives option users to better securi
I'm using the line:
PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD)
Where the path is /phpdev/lib. But my extension is actually linking to
/v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even
though /v8/out/x64.release no longer exists.
What am I doing
>
>> 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
On 10/04/12 19:22, Chris Stockton wrote:
> Hello,
> I understand your point that you are trying to make, but forward
> compatibility I am not sure shares the same critical nature as
> backwards.
Sure, but if we can help with that when designing the feature, that's
much better, and I think would al
hi Tom,
On Tue, Apr 10, 2012 at 8:18 PM, Tom Boutell wrote:
> Scroll down a bit; he gets into valid points about the == operator,
> for instance. It's not a useless post. He does cite too many things
> that he has to follow up himself by saying "this was fixed in PHP
> 5.x.y." If it was fixed, w
hi Stas,
This is zero code or tests change. This is pure restoring what we are
supposed to have, like it was in svn.
However, as you won't merge the tests fixes either, we won't 5.4.1's
tests at all to valid the build (way too many false positive), it does
not really matter anymore.
Cheers,
On
On Tue, 10 Apr 2012 18:32:37 +0100, Stas Malyshev
wrote:
On another area, we cruelly need:
http://nebm.ist.utl.pt/~glopes/misc/lf_phpt
applied to all branches, incl. 5.3.11/5.4.1.
I'm not sure I understand what is that and why we can't release 5.4.1
without it? I see a list of files in th
Kris Craig wrote:
PERL is like the duct-tape
of scripting languages; it can be used for just about anything, though
there's almost always a more specialized solution. It serves a purpose.
Perhaps not the most ideal of comparisons ... The last thing you use 'duct-tape'
for is sealing ducts ...
Hi!
> Another important thing i didn't mention - there is a lot of test fixes
> going to be commited, they should be merged into release branches too.
Test fixes are definitely not critical bugs. So I would prefer handling
them as usual fixes.
--
Stanislav Malyshev, Software Architect
SugarCRM:
On Tue, Apr 10, 2012 at 11:12 AM, Ralf Lang wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > It always amuses me when PERL developers go on their little
> > soapboxes about how "real" programmers all think PHP is stupid
> > lol.
>
> It always amuses me PHP people think perl is stupi
Hi!
> Scroll down a bit; he gets into valid points about the == operator,
> for instance. It's not a useless post. He does cite too many things
> that he has to follow up himself by saying "this was fixed in PHP
> 5.x.y." If it was fixed, why is it on your laundry list still?
What exactly valid p
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki
>
> Hi all,
>
> This is the RFC as in the title.
> Although it's not a direct security measure, but it's related to critical
> security problem prevention.
>
> If you are not familiar to how to execute arbitrary PHP co
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying "this was fixed in PHP
5.x.y." If it was fixed, why is it on your laundry list still?
On Tue, Apr 10, 2012 at 12:31 PM,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> It always amuses me when PERL developers go on their little
> soapboxes about how "real" programmers all think PHP is stupid
> lol.
It always amuses me PHP people think perl is stupid and vice versa.
Both languages have their use case, sometimes I
On Tue, Apr 10, 2012 at 9:38 AM, Stas Malyshev wrote:
> Hi!
>
> > today I read this post, I think that some points are valid, follow the
> link for
> > you guys
> >
>
> Could you name a few and explain why you think they are valid and what
> you propose to do to fix them? This article is huge and
Hello,
On Tue, Apr 10, 2012 at 12:59 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> This is the RFC as in the title.
> Although it's not a direct security measure, but it's related
> to critical security problem prevention.
>
> If you are not familiar to how to execute arbitrary PHP code,
> steal data fro
Hi!
> On another area, we cruelly need:
>
> http://nebm.ist.utl.pt/~glopes/misc/lf_phpt
>
> applied to all branches, incl. 5.3.11/5.4.1.
I'm not sure I understand what is that and why we can't release 5.4.1
without it? I see a list of files in that link - what are these files,
what is supposed
Hello,
2012/4/10 Ángel González :
> Luke Scott wrote:
>>> if ( version_compare(PHP_VERSION, '5.5', '<') )
>>> include_once $file;
>>> else
>>> require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
>> I'm fairly certain that wouldn't work either. Require and friends are
>> constructs,
hi,
On another area, we cruelly need:
http://nebm.ist.utl.pt/~glopes/misc/lf_phpt
applied to all branches, incl. 5.3.11/5.4.1.
That restores the force LF EOL we did in SVN.
Cheers,
On Tue, Apr 10, 2012 at 6:39 PM, Stas Malyshev wrote:
> Hi!
>
>> They are critical as they break BC with previo
Hi!
> They are critical as they break BC with previous versions. The
> breakages are introduced with the previous security fix. Please merge
> it.
Could you please describe what exactly was broken?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 22
Hi!
> today I read this post, I think that some points are valid, follow the link
> for
> you guys
>
Could you name a few and explain why you think they are valid and what
you propose to do to fix them? This article is huge and if you want to
start a discussion that makes sense (as opposed to a
On Tue, 10 Apr 2012 17:20:41 +0100, Adir Kuhn wrote:
Hi folks,
today I read this post, I think that some points are valid, follow the
link for you guys
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
This is really long. I stopped reading in full when he complained abo
hi,
On Tue, Apr 10, 2012 at 6:20 PM, Adir Kuhn wrote:
> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link
> for
> you guys
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Sorry but this list is not a SEO booster. Thanks for your und
Hi,
On Tue, Apr 10, 2012 at 6:08 PM, Anatoliy Belsky wrote:
> those are not critical, but they break some tests. Thease bugs seem to be
> already present before, nonetheless they've been fixed after libmagic
> security upgrade to 5.11
They are critical as they break BC with previous versions. T
Hi folks,
today I read this post, I think that some points are valid, follow the link for
you guys
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Adir Kuhn
ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
PSMI - Professional Scrum Master I
Hi,
On Tue, April 10, 2012 16:39, Stas Malyshev wrote:
> Hi!
>
>> This fixes should be merged into the current 5.3.11 and 5.4.1 branches.
>> The info about the changes is in the following tickets:
>>
>> https://bugs.php.net/bug.php?id=61565
>> https://bugs.php.net/bug.php?id=61566
>
> Are those cr
Hello Chris,
Chris Stockton wrote:
> I am not sure I am following you here Angel, are you confusing
> backwards and forward compatibility?
It can probably be termed both ways, depending on which version you stay.
I'm refering to the ability of a php file to work in both version 5.4
and 5.5 yet
ta
Luke Scott wrote:
>> if ( version_compare(PHP_VERSION, '5.5', '<') )
>> include_once $file;
>> else
>> require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
> I'm fairly certain that wouldn't work either. Require and friends are
> constructs, not functions.
>
> Luke
I had assumed requi
Yes, those points (keep the same keywords, optional second parameter,
OR'd constants) have been made a few times, and I plan to edit the RFC
accordingly.
On Tue, Apr 10, 2012 at 10:53 AM, Luke Scott wrote:
> Tom,
>
> On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:
>
>> The "second part" in the R
Tom,
On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:
> The "second part" in the RFC is just a suggested filename convention,
> it is not a hardcoded requirement. I'm not sure that's what you're
> talking about here.
>
> The RFC I'm referring to does not propose completely removing the
> availabi
Hi!
> This fixes should be merged into the current 5.3.11 and 5.4.1 branches.
> The info about the changes is in the following tickets:
>
> https://bugs.php.net/bug.php?id=61565
> https://bugs.php.net/bug.php?id=61566
Are those critical bugs that break all fileinfo functionality?
--
Stanislav M
On Tue, Apr 10, 2012 at 3:36 PM, John LeSueur wrote:
> On Tue, Apr 10, 2012 at 4:51 AM, Yasuo Ohgaki wrote:
>
> > Hi all,
> >
> > I've written most of thing that I would like to mention for this RFC.
> > I tried to be precise and understandable for anyone. If you have
> > questions, you are welco
The "second part" in the RFC is just a suggested filename convention,
it is not a hardcoded requirement. I'm not sure that's what you're
talking about here.
The RFC I'm referring to does not propose completely removing the
availability of the https://wiki.php.net/rfc/source_files_without_opening_t
On Tue, Apr 10, 2012 at 4:51 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> I've written most of thing that I would like to mention for this RFC.
> I tried to be precise and understandable for anyone. If you have
> questions, you are welcomed both on this list and in private.
>
> Regards,
>
> P.S. Directl
IMHO, both parts can be separated. My personal opinion: the require_path
with the php mode only can be useful, a mime type or extension for these
files too, but I'm not sure about removing " wrote:
> An important clarification: the RFC has two parts, NOT two options.
> Yasuo Ohgaki made many edits
During the flattening process, is a copy made of the trait
code (or bytecode or whatever)?
...
Or is the code shared so the memory use will be roughly the same?
...
I realise the use cases for traits and inheritance are
different, and often the situation will dictate the design,
but sometimes
On 10/04/12 5:42 PM, Stefan Marr wrote:
Hi Ben:
On 10 Apr 2012, at 03:34, Ben Schmidt wrote:
During the flattening process, is a copy made of the trait code (or
bytecode or whatever)?
Thanks to Dmitry, the op_array, i.e., the methods op codes are not
copied but shared between the methods.
Th
An important clarification: the RFC has two parts, NOT two options.
Yasuo Ohgaki made many edits to the RFC before deciding to create his
own RFC. He backed out most of his edits but somewhere along the line
he introduced the words "Option 1" and "Option 2" for two things that
are meant to go teget
Another important thing i didn't mention - there is a lot of test fixes
going to be commited, they should be merged into release branches too.
thanks )
On Tue, April 10, 2012 13:23, Anatoliy Belsky wrote:
> Hi guys,
>
> I wanted just ask about the latest fileinfo fixes as I see so far nothing
> w
Hi guys,
I wanted just ask about the latest fileinfo fixes as I see so far nothing
was merged.
This fixes should be merged into the current 5.3.11 and 5.4.1 branches.
The info about the changes is in the following tickets:
https://bugs.php.net/bug.php?id=61565
https://bugs.php.net/bug.php?id=615
Hi all,
I've written most of thing that I would like to mention for this RFC.
I tried to be precise and understandable for anyone. If you have
questions, you are welcomed both on this list and in private.
Regards,
P.S. Directly fixing bad English on wiki is certainly appreciated.
--
Yasuo Ohgak
hi,
On Tue, Apr 10, 2012 at 9:24 AM, Flavius Aspra wrote:
> I also subscribe to the opinion of object persistency not being worth it. In
> an application server, you could probably achieve more by keeping the entire
> phar in RAM.
>
> Currently, you can also simulate that by putting the phar on
hi,
2012/4/10 Johannes Schlüter :
> 0f180a6 - Fixed bug in new stream_get_line() when using NUL as a delimiter.
> (This is a regression from 5.3.10)
> 9bf8cd4 - Fixed bug #61650 (ini parser crashes when using ${} ini
> variables (without apache2))
> (Crash fix)
> ca58cd0 - Cherry-pi
On Tue, Apr 10, 2012 at 10:54 AM, Yasuo Ohgaki wrote:
> Hi,
>
> First of all, the proposal is threat mitigation and not for a
> complete countermeasure for LFI.
>
yep, and I think that there is no transparent solution which would make
impossible to havi LFI vulnerability without seriously crippl
On Sun, 2012-04-08 at 23:54 -0700, Stas Malyshev wrote:
> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.
As will 5.3.11.
> 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
>
Hi,
First of all, the proposal is threat mitigation and not for a
complete countermeasure for LFI.
2012/4/10 Ferenc Kovacs :
>>
>> "allow_url_include" and "template_mode" is similar to me.
>>
>> allow_url_include: enable only when url include is needed.
>> template_mode: enable only when tem
>
>
> "allow_url_include" and "template_mode" is similar to me.
>
> allow_url_include: enable only when url include is needed.
> template_mode:enable only when template mode is needed.
>
> allow_url_include prevents RFI which may result in critical security
> incident.
> template_mode prevent
Hi,
I'm not oppose to create a C module for OO template, but
new syntax is overkill.
Anyway, I would rather to have dedicated escape API for
- JavaScript strings
- JavaScript Identifiers
- CSS params
- CSS Identifiers
- what else?
It would be better to have dedicated escape functions so th
On Apr 10, 2012, at 12:24 AM, Flavius Aspra wrote:
> On 04/09/2012 10:30 PM, Luke Scott wrote:
>> Yeah it would be. He also mentioned something about preloading
>> framework classes.. Would like to hear his thoughts on that!
>
> I also subscribe to the opinion of object persistency not being wort
On 10 April 2012 15:30, Yasuo Ohgaki wrote:
> "allow_url_include" and "template_mode" is similar to me.
>
> allow_url_include: enable only when url include is needed.
> template_mode: enable only when template mode is needed.
>
> allow_url_include prevents RFI which may result in critical sec
Hi all,
This is the RFC as in the title.
Although it's not a direct security measure, but it's related
to critical security problem prevention.
If you are not familiar to how to execute arbitrary PHP code,
steal data from RDBMS via SQL injection and LFI, it may be
interesting.
This RFC will not
Hi Ben:
On 10 Apr 2012, at 03:34, Ben Schmidt wrote:
> During the flattening process, is a copy made of the trait code (or
> bytecode or whatever)?
Thanks to Dmitry, the op_array, i.e., the methods op codes are not copied but
shared between the methods.
Thus, there is a certain memory benefi
Hi,
2012/4/10 Kris Craig :
>
>
> 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 n
Hi,
2012/4/10 Luke Scott :
> 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
On 04/09/2012 10:30 PM, Luke Scott wrote:
Yeah it would be. He also mentioned something about preloading
framework classes.. Would like to hear his thoughts on that!
I also subscribe to the opinion of object persistency not being worth it. In an
application server, you could probably achieve m
99 matches
Mail list logo
