On Wed, Jan 4, 2012 at 3:47 PM, Laruence larue...@php.net wrote:
Hi:
I have submitted a patch, you can have a try:
https://bugs.php.net/patch-display.php?bug=60627patch=bug60627.patchrevision=1325663174
thanks
After I test, the patch is okey, so I commited it,
however, lucas, lbarnaud
On 03/01/12 18:17, Matthew Weier O'Phinney wrote:
On 2011-12-29, David Soria Parrad...@php.net wrote:
here is a short update on the current status of the
git migration.
Thanks for all the ground work you're doing making this happen!
Thanks too!
- php-src will be migrated after PHP 5.4
On Wed, Jan 4, 2012 at 2:59 PM, Laruence larue...@php.net wrote:
Hi dmitry:
it seems you have fix the issue that error in register_variable
will cause php process exit.
here is a fix I made before: http://pastebin.com/7BLAVaWr , I
think maybe this is a lighter fix.
could you
Hi:
I have updated the patch, make it works in case of sub arrays.
http://pastebin.com/yPTUZuNe
thanks
On Wed, Jan 4, 2012 at 5:59 PM, Laruence larue...@php.net wrote:
On Wed, Jan 4, 2012 at 2:59 PM, Laruence larue...@php.net wrote:
Hi dmitry:
it seems you have fix the issue that
On Wed, Jan 4, 2012 at 7:34 PM, Laruence larue...@php.net wrote:
Hi:
I have updated the patch, make it works in case of sub arrays.
http://pastebin.com/yPTUZuNe
this patch only restrict the post variables number, since GET and
Cookie all have their length limit.
and it's also easy to
On Wed, Jan 4, 2012 at 12:52 PM, Laruence larue...@php.net wrote:
On Wed, Jan 4, 2012 at 7:34 PM, Laruence larue...@php.net wrote:
Hi:
I have updated the patch, make it works in case of sub arrays.
http://pastebin.com/yPTUZuNe
this patch only restrict the post variables number,
hi,
There is no other option.
This value is used before a script even get the hand. So we have to
set a value by default, but we cannot force it, that's why we have to
use an ini setting.
Cheers,
On Wed, Jan 4, 2012 at 2:30 PM, jpauli jpa...@php.net wrote:
On Wed, Jan 4, 2012 at 12:52 PM,
I dont seem to have the karma for doing this in RFC so ill propose it here,
and once karma make an RFC
Is it possible to have a 2nd option on file_exists so that it returns the
path you specified
--Example
$cFile = file_exists(/file/located/here.php, true);
and if that exists it will return
realpath function do this for you. It returns the absolute path, if
file exists. Otherwise, returns null.
On Wed, Jan 4, 2012 at 2:18 PM, Keloran ava...@gmail.com wrote:
I dont seem to have the karma for doing this in RFC so ill propose it here,
and once karma make an RFC
Is it possible to
On Wed, Jan 4, 2012 at 5:18 PM, Keloran ava...@gmail.com wrote:
I dont seem to have the karma for doing this in RFC so ill propose it here,
and once karma make an RFC
Is it possible to have a 2nd option on file_exists so that it returns the
path you specified
--Example
$cFile =
pretty sure it's a bad idea because this function expected to return
true/false
Not to mention it is completely unnecessary since you can assign path to a
var
$file = '/path/file.txt';
if(!file_exists($file)){
// you already have access to $file
}
Dmitri Snytkine
Web Developer
Ultra Logistics,
I agree with Dmitri and Ferenc.
-1 on this idea, it's unnecessary.
the reason for this is simple actually at the moment if you want to include
a file for usage but want to check it exists you have todo the following
if (file_exists(/file/located/here.php)) {
$cFile = /file/located/here.php;
Hi!
Hi:
I have updated the patch, make it works in case of sub arrays.
http://pastebin.com/yPTUZuNe
I'm sorry, I'm not sure still I understand - what is this patch fixing?
I.e. what is the problem with the current PHP that needs this patch?
--
Stanislav Malyshev, Software Architect
On Wed, Jan 4, 2012 at 6:18 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Hi:
I have updated the patch, make it works in case of sub arrays.
http://pastebin.com/yPTUZuNe
I'm sorry, I'm not sure still I understand - what is this patch fixing?
I.e. what is the problem with the
Hi!
From the comments by Laruence it seems that he thinks that we only need
to limit post, as get and cookie has external limits.
I don't think it's a big problem if we limit all of them. It's not like
anybody needs a million cookies in their http request.
And I guess at least the
And I guess at least the information disclosure part would be needed
here also (
https://twitter.com/#!/i0n1c/**status/152356767601393665https://twitter.com/#!/i0n1c/status/152356767601393665)
Could you please elaborate on that part - where is the disclosure and what
exactly is being
Hi!
Could you please elaborate on that part - where is the disclosure
and what exactly is being disclosed?
I would guess that the value of that said limit. (it is the only
variable in the error message).
This is an error message, it's not visible to anybody. Even if it were,
I
On Wed, Jan 4, 2012 at 8:37 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Could you please elaborate on that part - where is the disclosure
and what exactly is being disclosed?
I would guess that the value of that said limit. (it is the only
variable in the error message).
On 01/04/2012 11:46 AM, Ferenc Kovacs wrote:
On Wed, Jan 4, 2012 at 8:37 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Could you please elaborate on that part - where is the disclosure
and what exactly is being disclosed?
I would guess that the value of that said limit. (it
On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf ras...@php.net wrote:
Since it is one of these remotely-triggered errors that you can't
program around, it should probably be suppressed when display_errors is
on. There is another precedence for this, but I am drawing a blank on
where else we did
On 01/04/2012 11:54 AM, Nikita Popov wrote:
On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf ras...@php.net wrote:
Since it is one of these remotely-triggered errors that you can't
program around, it should probably be suppressed when display_errors is
on. There is another precedence for this,
Inline.
On Wed, Jan 4, 2012 at 8:02 PM, Rasmus Lerdorf ras...@php.net wrote:
On 01/04/2012 11:54 AM, Nikita Popov wrote:
On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf ras...@php.net wrote:
Since it is one of these remotely-triggered errors that you can't
program around, it should probably be
Le 04/01/2012 10:05, Laruence a écrit :
After I test, the patch is okey, so I commited it,
Thanks for the patch, works well.
Only a autoload bug with APC in ZTS, but this is another issue.
Remi
P.S. APC bug https://bugs.php.net/60658
--
PHP Internals - PHP Runtime Development Mailing List
Am 04.01.2012 21:02, schrieb Rasmus Lerdorf:
But there is a very valid security concern here. People can usually run
safely with display_errors enabled if their code is well-written.
if it is well written there would be nor errors displayed
but you miss - in production you MUST NOT dispaly
On Wed, Jan 4, 2012 at 9:07 PM, Paul Dragoonis dragoo...@gmail.com wrote:
Inline.
On Wed, Jan 4, 2012 at 8:02 PM, Rasmus Lerdorf ras...@php.net wrote:
On 01/04/2012 11:54 AM, Nikita Popov wrote:
On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf ras...@php.net wrote:
Since it is one of these
Am 04.01.2012 21:07, schrieb Paul Dragoonis:
I agree with Rasmus here. A lot of people keep display_errors on, even
when they shouldn't.
it is not the job of a programming language stop admins
from beeing stupid - the defaults have to be sane and this
is display_error OFF, if somebody
Hi!
But there is a very valid security concern here. People can usually run
safely with display_errors enabled if their code is well-written. They
Oh no. Nobody should or can safely run production with display_errors.
Everybody thinks their code is well-written, but display_errors should
On Wed, 2012-01-04 at 12:29 -0800, Stas Malyshev wrote:
Hi!
But there is a very valid security concern here. People can usually run
safely with display_errors enabled if their code is well-written. They
Oh no. Nobody should or can safely run production with display_errors.
Everybody
Hi Johannes,
as far as I understood the issue, this error would be triggered before the
application's code is executed, so that would not solve this issue.
Cheers
Jannik
Am 04.01.2012 um 21:46 schrieb Johannes Schlüter:
On Wed, 2012-01-04 at 12:29 -0800, Stas Malyshev wrote:
Hi!
But
On Wed, 2012-01-04 at 21:49 +0100, Jannik Zschiesche wrote:
Hi Johannes,
as far as I understood the issue, this error would be triggered before
the application's code is executed, so that would not solve this
issue.
That's the point. Thanks for making it clear. :-)
johannes
Cheers
Hi!
as far as I understood the issue, this error would be triggered before
the application's code is executed, so that would not solve this
issue.
That's the point. Thanks for making it clear. :-)
Hmm... shared hosts. OK, let's make it the same way as the other input
message then. I don't
On 01/04/2012 12:19 PM, Reindl Harald wrote:
Am 04.01.2012 21:07, schrieb Paul Dragoonis:
I agree with Rasmus here. A lot of people keep display_errors
on, even when they shouldn't.
it is not the job of a programming language stop admins from
beeing stupid - the defaults have to be
Hi again,
Am 04.01.2012 um 21:52 schrieb Johannes Schlüter:
On Wed, 2012-01-04 at 21:49 +0100, Jannik Zschiesche wrote:
Hi Johannes,
as far as I understood the issue, this error would be triggered before
the application's code is executed, so that would not solve this
issue.
That's
On 01/04/2012 12:46 PM, Johannes Schlüter wrote:
On Wed, 2012-01-04 at 12:29 -0800, Stas Malyshev wrote:
Hi!
But there is a very valid security concern here. People can usually run
safely with display_errors enabled if their code is well-written. They
Oh no. Nobody should or can safely run
On Wed, Jan 4, 2012 at 9:56 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/04/2012 12:19 PM, Reindl Harald wrote:
Am 04.01.2012 21:07, schrieb Paul Dragoonis:
I agree with Rasmus here. A lot of people keep display_errors
on, even when they shouldn't.
it is not the job of a
On Tue, 27 Dec 2011, Stas Malyshev wrote:
3. $d-setTimestamp(1000) is not ever going to work as
zend_parse_parameters simply gives me long: 1215752192. This I find
really strange actually. Any clue?
That's probably float to long conversion, since 1000 is float on
On 01/04/2012 01:01 PM, Ferenc Kovacs wrote:
I just got the tip that this error is only shown
if display_startup_errors is set to true, and because it is in the
startup routine the file path in the error message (which is the real
infoleak) would only point to unknown 0.
If somebody has the
Hi!
Right, like I said in my previous message, if this is caught by
display_start_errors, I am ok with it. We need the default/no php.ini
file case to not leak information like this.
Just checked - it does not display error if display_startup_errors if
off, does display if it's on.
--
On 01/04/2012 01:27 PM, Stas Malyshev wrote:
Hi!
Right, like I said in my previous message, if this is caught by
display_start_errors, I am ok with it. We need the default/no php.ini
file case to not leak information like this.
Just checked - it does not display error if
On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
On 01/04/2012 01:27 PM, Stas Malyshev wrote:
Hi!
Right, like I said in my previous message, if this is caught by
display_start_errors, I am ok with it. We need the default/no php.ini
file case to not leak information like this.
Just checked -
On 04/01/12 17:18, Keloran wrote:
which can if your doing lots of checking alot of extra code for no reason,
or if you want to use variables, lots of louse variables just for something
that could be pulled from the request
I don't think it would mean 'a lot of code', but if it bothers you in
On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
On 01/04/2012 01:27 PM, Stas Malyshev wrote:
Hi!
Right, like I said in my previous message, if this is caught by
display_start_errors, I am ok with it. We need the
On 01/04/2012 08:13 PM, Laruence wrote:
On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
On 01/04/2012 01:27 PM, Stas Malyshev wrote:
Hi!
Right, like I said in my previous message, if this is caught by
On Thu, Jan 5, 2012 at 12:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/04/2012 08:13 PM, Laruence wrote:
On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
On 01/04/2012 01:27 PM, Stas Malyshev wrote:
Hi!
Right,
Hi!
and different with the fix which was commited now, this patch count
the num vars in a global scope, that means if there are 2 elements
which both have 500 elements in post, the restriction will also
affect,
Why? The point of the limitation is to avoid hash collisions and related
Hi!
I really don't think this manual per-feature limiting is going to cut it
here. The real problem is the predictability of the hashing which we can
address by seeding it with a random value. That part is easy enough, the
hard part is figuring out where people may be storing these hashes
On Thu, Jan 5, 2012 at 3:01 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
and different with the fix which was commited now, this patch count
the num vars in a global scope, that means if there are 2 elements
which both have 500 elements in post, the restriction will also
affect,
On 01/04/2012 11:09 PM, Stas Malyshev wrote:
Hi!
I really don't think this manual per-feature limiting is going to cut it
here. The real problem is the predictability of the hashing which we can
address by seeding it with a random value. That part is easy enough, the
hard part is figuring
Hi!
Yes, but we still need an actual case to look at. Opcode caches
shouldn't be a problem unless they store some representation on disk
that live across server restarts. In the APC world, nobody does that. Is
It's not that simple. Take example of FastCGI setup where processes can
live and
Hi:
there is one way maybe is a good try.
when resize hashtable, we don't just dobule the size, instead, we
increase the hashtable size with a random delta
what do you think?
thanks
On Thu, Jan 5, 2012 at 3:33 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Yes, but we still
On 01/04/2012 11:33 PM, Stas Malyshev wrote:
Hi!
Yes, but we still need an actual case to look at. Opcode caches
shouldn't be a problem unless they store some representation on disk
that live across server restarts. In the APC world, nobody does that. Is
It's not that simple. Take example
On 01/04/2012 11:49 PM, Laruence wrote:
Hi:
there is one way maybe is a good try.
when resize hashtable, we don't just dobule the size, instead, we
increase the hashtable size with a random delta
what do you think?
Sorry, you lost me. How does that help? The problem is when we
52 matches
Mail list logo
