On Thu, Jan 5, 2012 at 3:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
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
On Thu, Jan 5, 2012 at 4:04 PM, Laruence larue...@php.net wrote:
On Thu, Jan 5, 2012 at 3:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
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
On Thu, Jan 5, 2012 at 4:11 PM, Laruence larue...@php.net wrote:
On Thu, Jan 5, 2012 at 4:04 PM, Laruence larue...@php.net wrote:
On Thu, Jan 5, 2012 at 3:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/04/2012 11:49 PM, Laruence wrote:
Hi:
there is one way maybe is a good try.
On Wed, 4 Jan 2012, Rasmus Lerdorf wrote:
On 01/04/2012 11:09 PM, Stas Malyshev wrote:
I think we'd need and API to access the seed value and to calculate
hash for given seed value. That would probably allow extensions that
store hashes with some additional work to do it properly.
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,
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
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 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 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
46 matches
Mail list logo
