Edit report at https://bugs.php.net/bug.php?id=45573&edit=1
ID: 45573
Comment by: josh at josheaton dot org
Reported by: t_mueller_stolzenhain at yahoo dot de
Summary: unserialize does not work if a linebreak is inside
the input string
Status: Not a bug
Type: Bug
Package: CGI/CLI related
Operating System: windows2003
PHP Version: 5.2CVS-2008-07-23
Assigned To: fb-req-jani
Block user comment: N
Private report: N
New Comment:
I'm wondering why this issue never got any attention even with a reduced test case that
reproduced the issue? I recently ran into this issue with a WordPress site and found this bug.
WordPress ticket: https://core.trac.wordpress.org/ticket/23275#comment:7
netweb was kind enough to provide a link that tests the issue in many different PHP versions, and it
appears to break in all of them. Any windows line endings within a serialized string break when
unserialized.
http://3v4l.org/X0pFQ
Is it possible to reopen this issue?
Previous Comments:
------------------------------------------------------------------------
[2008-07-25 19:18:45] t_mueller_stolzenhain at yahoo dot de
sample to reproduce the error I had:
<?php
//the original array
$a = array(
'a23' => 'abcdefg
hij'
);
//make it serial
$s = serialize($a);
//just to see the serial string
var_dump($s);
//the serialized array
$s1 = 'a:1:{s:3:"a23";s:11:"abcdefg
hij";}';
//the same with linux line end character
$s2 = "a:1:{s:3:\"a23\";s:11:\"abcdefg\12hij\";}";
//the same with windows line end character, same I had in my PEAR files
$s3 = "a:1:{s:3:\"a23\";s:11:\"abcdefg\15\12hij\";}";
//turn it back to an array
$a1 = unserialize($s1); // ok
$a2 = unserialize($s2); // ok
$a3 = unserialize($s3); // not ok
?>
------------------------------------------------------------------------
[2008-07-24 23:04:14] jani@php.net
As long as there is no preproducing script, there is no problem either.
------------------------------------------------------------------------
[2008-07-24 21:10:21] t_mueller_stolzenhain at yahoo dot de
I don't have a sample script (I'm not able to create an text with two different line
endings in it), but I found the reason for that issue:
As you know, PEAR is storing some information inside the .registry directory in *.reg files. Some of
these files I found converted to the windows style, means they had a windows line ending
("\15\12") instead of the linux line ending ("\12").
After reformating these files with the linux line ending, the error messages disappeared, and the
PEAR update was running without any error messages.
I asume, the most of the files on a windows computer have the windows line ending included, not the
linux line ending.
PHP is able to detect that it is running on a windows computer, and unserialize should be able to
handle the windows line ending without error message.
------------------------------------------------------------------------
[2008-07-24 00:31:50] jani@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
------------------------------------------------------------------------
[2008-07-23 21:40:29] t_mueller_stolzenhain at yahoo dot de
I tried the package from http://snaps.php.net/win32/php5.2-win32-latest.zip,
but the error is still there.
I changed the category for this bug, because the PEAR update was not running inside the browser, it
was running inside a dos window.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=45573
--
Edit this bug report at https://bugs.php.net/bug.php?id=45573&edit=1