SquirrelMail / Bugs / #2784 squirrelmail 1.4.22 produces a lot of errors with php-5.4.0

Paul Lesniewski - 2012-02-23

We do not recommend you use E_STRICT in your PHP error reporting settings, however we appreciate the report and we will take a look at these in the near future.

Also, please specify if any of these notices (they are *not* errors) prevent SquirrelMail from functioning.

The first two warning messages (of the three at the end of your list) in particular may only be related to a specific message - you should see if you can reproduce them reliably and provide the full message source for messages that cause these warnings. (NB: May need to test for/add new MessageHeader object before using the header attribute blindly)

As for the last warning, you need to provide as many details as you can about your IMAP server, including the results of the NAMESPACE command in order for us to diagnose the issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

T.D. Corell - 2012-03-22

With a active mail_fetch plugin squirrelmail stops working:

PHP Fatal error: Cannot redeclare hex2bin() in /usr/share/squirrelmail/plugins/mail_fetch/functions.php on line 104

In PHP5.4 the function hex2bin() is new: http://de2.php.net/manual/en/function.hex2bin.php

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

T.D. Corell - 2012-03-23

After a user complaint about missing lines in emails, I removed the E_STRICT in PHP, but the error:

PHP Warning: Creating default object from empty value in /usr/share/squirrelmail/class/mime/Message.class.php on line 367

still results in missing lines in E-Mails or missing Subject-Lines.

Example (from a mail header):
Subject: =?ISO-8859-15?Q?Echtheitspr=FCfung_=7C_GERMANQualitySourcing?=

does not show up in squirrel if you view your Mails, you got a empty Subject, and no Link to the mail - you have to go to the previous or next mail and use prev/next button to see the mail.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thijs Kinkhorst - 2012-03-24

I did make some changes to SVN to address the Warnings listed in this report (also the hex2bin issue mentioned in a comment has been fixed).

The Strict ones do not or should not impact behaviour; if they do, turn them off. They are intended for development systems, not production systems.

Can you verify that you still run into the same problems with current svn? It Works For Me with PHP 5.4.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Michal Hlavinka - 2012-03-26

E_STRICT was (temporarily I guess) turned on for Fedora 17 development cycle. I've turned it off.

It seems it's working now (I've just added your changes on top of 1.4.22, I was not able to test current svn. Let me know if it's needed.)

Anyway, one change is missing. We still need this patch:
diff -up squirrelmail-webmail-1.4.22/functions/i18n.php.php54fixes squirrelmail-webmail-1.4.22/functions/i18n.php
--- squirrelmail-webmail-1.4.22/functions/i18n.php.php54fixes 2012-02-24 14:29:02.419849488 +0100
+++ squirrelmail-webmail-1.4.22/functions/i18n.php 2012-02-24 14:30:10.709423055 +0100
@@ -184,7 +184,7 @@ function charset_decode ($charset, $stri
}

/* All HTML special characters are 7 bit and can be replaced first */
- if (! $save_html) $string = htmlspecialchars ($string);
+ if (! $save_html) $string = htmlspecialchars ($string, ENT_COMPAT, 'ISO-8859-1');
$charset = strtolower($charset);

set_my_charset();

default value for htmlspecialchars changed from ISO-8859-1 to UTF-8 in php 5.4 and default htmlspecialchars behaviour is to return empty string once non-utf character is found (if utf/default encoding is used).

PS: Sorry for slow response, somehow all sf email went to junk folder.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

T.D. Corell - 2012-03-26

Wonderful! After adding this last patch from mhlavink the svn version (1.4.23 SVN) works without missing lines and subjects.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thijs Kinkhorst - 2012-04-07

Yes, I understand why that fix works but it's only a partial fix, as we use htmlspecialchars() all over the place.

htmlspecialchars() changed the default character set to UTF-8. What did not change (by default) is that if the string contains an invalid character code for the charset, the entire function returns "". This becomes a problem now with us because some isa-8859-1 chars are not valid utf-8 sequences.

This can be solved by adding a charset parameter to all our htmlspecialchars invocations. This is all over the code. Perhaps we may want to create a my_htmlspecialchars() which calls htmlspecialchars, and find and replace in the source code any occurrence of htmlspecialchars. This would mean we keep it in one place, and perhaps add a version check aswell.

BTW, some more info is in
http://nikic.github.com/2012/01/28/htmlspecialchars-improvements-in-PHP-5-4.html

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mark Sapiro - 2012-07-29

I note that my issue #3551377 has been closed and marked as a duplicate of this issue. Does that mean that the issue of Strict Standardscompliance is still considered open as implied by the first paragraph of the 2012-02-23 10:59:15 PST comment below or that it is considered "won't fix" as implied by the second paragraph of the 2012-03-24 03:48:53 PDT comment below.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-01

Apologies to those waiting for this issue to be addressed. In the interests of kick-starting this process, I am going to upload a patch that I've had in use but have hesitated to share because it is more invasive than it needs to be. That is, this patch WILL make SquirrelMail work well with PHP 5.4, but I replaced htmlspecialchars() nearly everywhere, when it isn't necessary in every instance. I haven't had the chance to sit down and analyze every location to determine its necessity -- anyone who can offer assistance in that is encouraged to let us know. I can say that these three locations are definitely necessary:

functions/forms.php lint 26
functions/i18n.php line 187, function charset_decode()
src/compose.php line 1306, 1309, 1317

Even if you cannot help us narrow down the needed patch locations, if you can apply my patch and give us any indication of any problems it may cause (performance related issues? wrongly encoded output?), we would be most grateful.

Thanks for any help anyone can offer. Thanks for everyone's patience.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-01

PHP5.4 htmlspecialchars fix (possibly too invasive)

squirrelmail-php_5.4-htmlspecialchars_update.diff

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-01

Also note, this patch is against 1.4.23-SVN (please grab a snapshot of that from our downloads page).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-01

I am also attaching a patch for SquirrelMail 1.5.2-SVN (pardon the lack of version information in the patch for version 1.4.23).

The minimal patch locations for version 1.5.2 are so far:

include/languages.php line 221, 237, 253, 259, function charset_decode()
src/compose.php line 1349, 1350, 1351, 1352, 1388, 1390, 1399

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-01

(SM 1.5.2) PHP5.4 htmlspecialchars fix (possibly too invasive)

squirrelmail_1.5.2-php_5.4-htmlspecialchars_update.diff

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mark Sapiro - 2012-12-01

I still don't know the status of this bug with respect to the "PHP Strict Standards: Non-static method" warnings or if the patches are supposed to address those, but they apparently don't.

I downloaded and installed the latest squirrelmail-20121201_0201-SVN.stab
le.tar.bz2 and the squirrelmail-php_5.4-htmlspecialchars_update.diff patch.

I first trimmed the patch to what I understood to be the minimum based on the 2012-11-30 21:53:01 PST comment and applied that. I couldn't even get a login page (see below). I then reverted that patch and applied the full patch. SquirrelMail then seemed functional, but I continued to get warnings.

Here's further information. Sorry for not attaching these as files, but I apparently don't have permission to add attachments to this bug.

The minimal patch I applied:

Index: src/compose.php

--- src/compose.php (revision 14344)
+++ src/compose.php (working copy)
@@ -1303,10 +1303,10 @@
} else {
echo "\n\n".($prefix_sig==true? "-- \n":'').decodeHeader($signature,false,false,true);
}
- echo "\n\n".htmlspecialchars(decodeHeader($body,false,false,true));
+ echo "\n\n".sm_encode_html_special_chars(decodeHeader($body,false,false,true));
}
else {
- echo "\n\n".htmlspecialchars(decodeHeader($body,false,false,true));
+ echo "\n\n".sm_encode_html_special_chars(decodeHeader($body,false,false,true));
if ($default_charset == 'iso-2022-jp') {
echo "\n\n".($prefix_sig==true? "-- \n":'').mb_convert_encoding($signature, 'EUC-JP');
}else{
@@ -1314,7 +1314,7 @@
}
}
} else {
- echo htmlspecialchars(decodeHeader($body,false,false,true));
+ echo sm_encode_html_special_chars(decodeHeader($body,false,false,true));
}
echo '</textarea><br />' . "\n" .
' </td>' . "\n" .
@@ -1763,7 +1763,7 @@
return $succes;
} else {
$msg = '<br />'.sprintf(_("Error: Draft folder %s does not exist."),
- htmlspecialchars($draft_folder));
+ sm_encode_html_special_chars($draft_folder));
plain_error_message($msg, $color);
return false;
}
Index: functions/i18n.php
===================================================================
--- functions/i18n.php (revision 14344)
+++ functions/i18n.php (working copy)
@@ -184,7 +184,7 @@
}

/* All HTML special characters are 7 bit and can be replaced first */
- if (! $save_html) $string = htmlspecialchars ($string);
+ if (! $save_html) $string = sm_encode_html_special_chars ($string);
$charset = strtolower($charset);

set_my_charset();
Index: functions/forms.php
===================================================================
--- functions/forms.php (revision 14344)
+++ functions/forms.php (working copy)
@@ -23,8 +23,8 @@
*/
function addInputField($type, $name = null, $value = null, $attributes = '') {
return '<input type="'.$type.'"'.
- ($name !== null ? ' name="'.htmlspecialchars($name).'"' : '').
- ($value !== null ? ' value="'.htmlspecialchars($value).'"' : '').
+ ($name !== null ? ' name="'.sm_encode_html_special_chars($name).'"' : '').
+ ($value !== null ? ' value="'.sm_encode_html_special_chars($value).'"' : '').
' ' . $attributes . " />\n";
}

With the above patch applied, the <head> section of the login page is the same as with no patch or with the full patch, but the <body> section is truncated to just the following two lines:

<body text="#000000" bgcolor="#ffffff" link="#0000cc" vlink="#0000cc" alink="#0000cc" onLoad="squirrelmail_loginpage_onload();">
<form action="redirect.php" method="post" name="login_form" >

With the full patch, I'm still getting warnings like:

[Sat Dec 01 11:11:04 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseStructure() should not be called statically in /usr/local/squirrelmail/www/functions/mime.php on line 36, referer: https://www.msapiro.net/mail/src/right_main.php
[Sat Dec 01 11:11:04 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseBodyStructure() should not be called statically in /usr/local/squirrelmail/www/class/mime/Message.class.php on line 296, referer: https://www.msapiro.net/mail/src/right_main.php
[Sat Dec 01 11:11:13 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseStructure() should not be called statically in /usr/local/squirrelmail/www/functions/mime.php on line 36, referer: https://www.msapiro.net/mail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX
[Sat Dec 01 11:11:13 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseBodyStructure() should not be called statically in /usr/local/squirrelmail/www/class/mime/Message.class.php on line 296, referer: https://www.msapiro.net/mail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX
[Sat Dec 01 11:11:26 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseStructure() should not be called statically in /usr/local/squirrelmail/www/functions/mime.php on line 36, referer: https://www.msapiro.net/mail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=Sent
[Sat Dec 01 11:11:26 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseBodyStructure() should not be called statically in /usr/local/squirrelmail/www/class/mime/Message.class.php on line 296, referer: https://www.msapiro.net/mail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=Sent
[Sat Dec 01 11:11:32 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseStructure() should not be called statically in /usr/local/squirrelmail/www/functions/mime.php on line 36, referer: https://www.msapiro.net/mail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=Sent
[Sat Dec 01 11:11:32 2012] [error] [client 68.183.193.239] PHP Strict Standards: Non-static method Message::parseBodyStructure() should not be called statically in /usr/local/squirrelmail/www/class/mime/Message.class.php on line 296, referer: https://www.msapiro.net/mail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=Sent

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-01

Your minimal patch is lacking the function definition for sm_encode_html_special_chars(). You need to include that change (to functions/strings.php) as well.

Please don't paste multiple copies of the same two E_STRICT warnings. The status of those two is indeed "won't fix". Production environments shouldn't use E_STRICT error reporting.

Thanks very much for your help.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mark Sapiro - 2012-12-04

Thanks for your reply regarding "won't fix" for the E_STRICT warnings, however the issue really isn't how I choose to manage the server on which I run SquirrelMail or what warnings I may see because of those choices.

The issue is whether SquirrelMail should or should not be violating PHP strict coding standards. Granted, there is no problem created at this time for that violation, but that does not guarantee that future PHP releases will continue to handle these violations in a way that doesn't cause problems.

Of course, it isn't up to me to say whether or not these will be "fixed", but if I were a SquirrelMail developer, I'd be concerned about them.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2012-12-04

Please take this up with PHP authors, whose philosophy is to break compatibility in new versions. Please do not assume we have not analyzed this and do not have good reasons for the decision.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mark Sapiro - 2012-12-04

Consider me properly chastised. Thanks for your work on SquirrelMail.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thijs Kinkhorst - 2012-12-05

Hi Paul,

I prepared a patch along the lines of your attached patch locally, but have now scrapped that and applied yours. It seems to work fine and I believe it's the right way to solve the problem.

I think it's not too invasive: better just replace all calls to htmlspecialchars everywhere: we then have the ability to change it at will globally should further adjustments be necessary, and it will give a consistent 'encoding experience' accross SquirrelMail.

As for your FIXME about performance: I don't think it will kill performance as the version checking function boils down to a simple arithmetical comparison. However, since that anti-double_encode function is not used at all in SquirrelMail (the parameter is never set to false), you could also just leave it out entirely: you can always add the extra parameter if it would be needed some time in the future.

I've also applied the patch to production. If no problems arise soon I'll commit it in SVN aswell: that won't set it in stone but it will hopefully give the patch a little bigger audience.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thijs Kinkhorst - 2012-12-09

Now applied as r14345 & r14346.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Abra Cadabra - 2014-04-02

i18n.php
< if (! $save_html) $string = sm_encode_html_special_chars ($string, ENT_COMPAT, $charset);

if (! $save_html) $string = sm_encode_html_special_chars ($string);

When charset of string != utf-8 in php 5.5 result return empty
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tomas Hajny - 2014-08-11

Hi,

I observed issues related to the PHP behaviour changes too, in particular triggered by messages containing parts encoded using QP encoding with one of ISO-8859-* charsets (but possibly also any other valid single byte charsets). Two probably important bits worth mentioning:

1) The issue was not reproducible with the default (English) locale, but only triggered when the language set in Display Preferences was set to Czech (probably also any other language defaulting to ISO-8859-* charset different from ISO-8859-1 - Czech uses ISO-8859-2).

2) The issue has been fixed for me (thanks for patient admin of the server used by me :-) ) by patch found in Debian bug repository in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680458 - in particular https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;filename=iso88591.patch;att=1;bug=680458 which had to be applied on top of other patches already included in the version provided in standard Ubuntu distribution.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2014-08-23

@Abra Cadabra @Tomas Hajny I think both of you are seeing the issue reported in https://sourceforge.net/p/squirrelmail/bugs/2806/ (therein you should find a proposed patch that is being tested - make sure to get the latest patch version).

The referenced Debian tracker and patch are NOT recommended (or supported) ways to fix this issue. The patch here is somewhat more robust.

I am closing this tracker since 1.4.23-svn seems to have shown itself to have disposed of the errors reported on this particular issue.

Thanks for your help.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Paul Lesniewski - 2014-08-23

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

squirrelmail 1.4.22 produces a lot of errors with php-5.4.0

Group

Searches

Help

#2784 squirrelmail 1.4.22 produces a lot of errors with php-5.4.0

Discussion

Index: src/compose.php