On Sun, Mar 31, 2013 at 6:25 AM, Laruence wrote:
> Hey:
>
>there are some issues when people run some codes in a php which is
> compiled with --with-curlwrappers, like #61336, or the recently test script
> for #64433 (failed when curl wrappers enabled).
>
>I know, that the curl wrapper sho
On 31/03/13 23:18, ALeX wrote:
>> JSON and serialize() are (inherently) different serialization formats with
>> different use-cases [...]
> Yes, and json requires that all strings (including the keys) has to be
> valid utf-8, and I'm sure that's not always the case (serialize can
> use binary data
> JSON and serialize() are (inherently) different serialization formats with
> different use-cases [...]
Yes, and json requires that all strings (including the keys) has to be
valid utf-8, and I'm sure that's not always the case (serialize can
use binary data in both places).
--
PHP Internals -
Hi,
there seems to be a bug in array_column function. Look at this:
http://3v4l.org/kZahr
The variables $column_key and $index_key are strings after calling
array_column which is probably wrong... :)
I have fixed that - pull request:
https://github.com/php/php-src/pull/316
Regards
Jakub
I think this RFC would worsen the problem of misusing the serialize round-trip.
Even if we make the docs clearer, we'd still be sending the message that there's a new
"safer" unserialize and some would certainly use that new feature to be more lax about
guarding serialized structures.
It also
On Sun, Mar 31, 2013 at 5:27 AM, Stas Malyshev wrote:
> > I think Stas proposes a solution to the problem and I think Anthony
> > proposes a viable alternative. I would say that Anthony has found the
> > shortest distance between the two points (the problem and the solution),
> > however.
>
> The
Hey:
there are some issues when people run some codes in a php which is
compiled with --with-curlwrappers, like #61336, or the recently test script
for #64433 (failed when curl wrappers enabled).
I know, that the curl wrapper should act the same as php http wrapper,
but for now, we need to
Stas,
The fact is that people do use serialize() for data that may be
> accessible by the user (or made accessible by unrelated security issues,
> which may be upgraded in severity by this - e.g. from SQL injection to
> persistent code backdoor on the server). There are many ways to do
> things d
>> And what about automatic un/serialize() of objects in $_SESSION?
>> People don't even see those function calls in their code, so dropping
>> the function/ality would be a wildly drastic move.
> Nothing about it, the change is for unserialize() function.
OK. I thought of this as one core securi
