[PROPOSAL] add a leading backslash to classname when serializing/var_exporting

11 years ago by Madara Uchiha — view source

unread

Sounds good. With PHP moving in closer and closer with namespaces, this
proposal will save some confusion in the more complex application
debugging. I support. +1

Hey:
bug is described at #64554

I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

what do you think?

thanks

--
Laruence Xinchen Hui
http://www.laruence.com/

11 years ago by Marco Pivetta — view source

unread

For consistency, in strings we should already be using the FQCN implicitly.
Therefore output of serialization and var_export should not need the
leading backslash.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Sounds good. With PHP moving in closer and closer with namespaces, this
proposal will save some confusion in the more complex application
debugging. I support. +1
Hey:
bug is described at #64554

I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

what do you think?

thanks

--
Laruence Xinchen Hui
http://www.laruence.com/

11 years ago by johannes@schlueters.de — view source

unread

Hey:
bug is described at #64554

I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

what do you think?

This breaks compatibility with serialization with <=5.2.

Right now, when using no namespaces, you can serialiaze things in
5.6-dev and unserialize in older versions.

In the bug I also don't see a need for doing this in serialize.
unserialize should know those are fully qualified.

var_export is a bit more nifty. I see a similar compatibility issue as
with serialize but also the use case ...

johannes

11 years ago by Steve Clay — view source

unread

 bug is described at #64554

-> https://bugs.php.net/bug.php?id=64554

 I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

Short term: Add note to the var_export() docs:

"For full compatibility with namespaces, the representation must be executed within the
root namespace."

Proposal seems reasonable to me (as Johannes mentioned, serialize should already be OK).

I think we're under no obligation to have serialized forms created in one version work in
previous versions [1], though FC of already persisted strings are important.

Note this won't solve the problem of existing var_export strings created in past versions.
(We'll still need some kind of note.)

[1] If an app needs BC of code like \Foo::__set_state(... I would think it'd be easy
enough to strip away the escapes.

Steve Clay

http://www.mrclay.org/

11 years ago by Yasuo Ohgaki — view source

unread

2013/4/9 Laruence laruence@php.net

I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

Additional bool parameter for it would be nice for var_export/serialize.
For var_dump, I wish to have d function :)

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Derick Rethans — view source

unread

2013/4/9 Laruence laruence@php.net

I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

Additional bool parameter for it would be nice for
var_export/serialize.

No new arguments please.

cheers,
Derick

11 years ago by Stas Malyshev — view source

unread

Hi!

I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.

I'm not sure what this has to do with serialize. For var_export it may
be useful but the use case looks kind of limited. I can't think of a
common case where such change would be beneficial, and since it's a BC
break I don't think it is worth it, unless we can find a real use case
where it is necessary. In the original bug, it says that the user would
use var_export in different namespace, but why would you need to do this?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

11 years ago by Madara Uchiha — view source

unread

Well, why would you need to serialize an object in one version of PHP,
and unserialize it in another?

Hi!
I proposal to add a leading backslash to all classnames (not only ns
names, since no harm, consistent and make sense) when doing serialize,
var_export etc.
I'm not sure what this has to do with serialize. For var_export it may
be useful but the use case looks kind of limited. I can't think of a
common case where such change would be beneficial, and since it's a BC
break I don't think it is worth it, unless we can find a real use case
where it is necessary. In the original bug, it says that the user would
use var_export in different namespace, but why would you need to do this?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

11 years ago by Rasmus Lerdorf — view source

unread

Well, why would you need to serialize an object in one version of PHP,
and unserialize it in another?

Unfortunately people do that all the time. They store serialized
versions of stuff in databases and other backends and even send it
across the wire from one machine to another, so it is quite common for
something serialized in one version to need to be unserialized in another.

-Rasmus

11 years ago by Laruence — view source

unread

hey:
thanks very much for all feedbacks.

so, maybe we should document this instead of adding lead backslash?

thanks

Well, why would you need to serialize an object in one version of PHP,
and unserialize it in another?

Unfortunately people do that all the time. They store serialized
versions of stuff in databases and other backends and even send it
across the wire from one machine to another, so it is quite common for
something serialized in one version to need to be unserialized in another.

-Rasmus

--
Laruence Xinchen Hui
http://www.laruence.com/

11 years ago by Derick Rethans — view source

unread

hey:
thanks very much for all feedbacks.

so, maybe we should document this instead of adding lead backslash?

I think that's best, yes.

cheers,
Derick

11 years ago by Thomas Hruska — view source

unread

hey:
thanks very much for all feedbacks.
so,  maybe we should document this instead of adding lead backslash?
thanks

Well, why would you need to serialize an object in one version of PHP,
and unserialize it in another?

serialize()/unserialize() is a convenient, clean, and powerful data
transport mechanism for PHP across many sessions and hosts. Using
serialize() and unserialize() is an addiction - once someone starts, it
is impossible for them to stop.

json_encode()/json_decode() can be useful for cross-language support,
but they are much more limited. json_decode() has the added natural
benefit of not being as vulnerable as unserialize().

people do that all the time. They store serialized
versions of stuff in databases and other backends and even send it
across the wire from one machine to another, so it is quite common for
something serialized in one version to need to be unserialized in another.

-Rasmus

While updating the documentation, maybe also include some discussion on
the dangers of unserializing data without first establishing trust?
There was a discussion not too long ago on this list about PHP executing
__destruct() of unserialized class data from untrusted sources. Example
recent exploit:

http://packetstormsecurity.com/files/118064/invision_pboard_unserialize_exec.rb.txt

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you might find useful.

http://cubiclesoft.com/

11 years ago by Daniel Macedo — view source

unread

I've seen the usage of signing/hashing stored along side the serialized
data to prevent this sort of injection.

Still not 100% safe, but in case you really can't escape the use of
serialize, it's a start...

On Mon, Apr 15, 2013 at 2:52 PM, Thomas Hruska thruska@cubiclesoft.comwrote:

hey:
thanks very much for all feedbacks.
so,  maybe we should document this instead of adding lead backslash?
thanks

On Wed, Apr 10, 2013 at 5:36 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:

Well, why would you need to serialize an object in one version of PHP,
and unserialize it in another?
serialize()/unserialize() is a convenient, clean, and powerful data
transport mechanism for PHP across many sessions and hosts. Using
serialize() and unserialize() is an addiction - once someone starts, it is
impossible for them to stop.

json_encode()/json_decode() can be useful for cross-language support, but
they are much more limited. json_decode() has the added natural benefit of
not being as vulnerable as unserialize().

people do that all the time. They store serialized

versions of stuff in databases and other backends and even send it
across the wire from one machine to another, so it is quite common for
something serialized in one version to need to be unserialized in
another.

-Rasmus

While updating the documentation, maybe also include some discussion on
the dangers of unserializing data without first establishing trust? There
was a discussion not too long ago on this list about PHP executing
__destruct() of unserialized class data from untrusted sources. Example
recent exploit:

http://packetstormsecurity.com/files/118064/invision_
pboard_unserialize_exec.rb.txthttp://packetstormsecurity.com/files/118064/invision_pboard_unserialize_exec.rb.txt

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you might find useful.

http://cubiclesoft.com/