Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

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

Produces PHP errors
closed-fixed
nobody
None
5
2014-08-23
2012-02-23
MiHl
No

Squirrelmail produces a lot of php errors messages, when used with php 5.4

Parsed log file:
Notice: Undefined property: Deliver_SMTP::$dlv_msg in /usr/share/squirrelmail/src/compose.php on line 1699
Notice: Undefined property: Deliver_SMTP::$dlv_server_msg in /usr/share/squirrelmail/src/compose.php on line 1701
Strict Standards: Declaration of Deliver_IMAP::send_mail() should be compatible with Deliver::send_mail($message, $header, $boundary, $stream, &$raw_length, $extra = NULL) in /usr/share/squirrelmail/class/deliver/Deliver_IMAP.class.php on line 82
Strict Standards: Declaration of Deliver_SMTP::initStream() should be compatible with Deliver::initStream($message, $length = 0, $host = '', $port = '', $user = '', $pass = '') in /usr/share/squirrelmail/class/deliver/Deliver_SMTP.class.php on line 369
Strict Standards: Non-static method Message::parseBodyStructure() should not be called statically in /usr/share/squirrelmail/class/mime/Message.class.php on line 296
Strict Standards: Non-static method Message::parseStructure() should not be called statically in /usr/share/squirrelmail/functions/mime.php on line 36
Warning: Creating default object from empty value in /usr/share/squirrelmail/class/mime/Message.class.php on line 367
Warning: Creating default object from empty value in /usr/share/squirrelmail/class/mime/Message.class.php on line 396
Warning: Illegal string offset '' in /usr/share/squirrelmail/functions/imap_general.php on line 708

This was obtained by:
sed -e 's/^.*PHP //' -e 's/, referer:.*$//' squirrelmail.log | sort | uniq

Discussion

  • 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.

     
  • T.D. Corell
    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

     
  • T.D. Corell
    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.

     
  • 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.

     
  • 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.

     
  • T.D. Corell
    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.

     
  • 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

     
  • Mark Sapiro
    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.

     
  • 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.

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

     
  • 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

     
  • Mark Sapiro
    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

     
  • 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.

     
  • Mark Sapiro
    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.

     
  • 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.

     
  • Mark Sapiro
    Mark Sapiro
    2012-12-04

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

     
  • 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.

     
  • Now applied as r14345 & r14346.

     
  • Abra Cadabra
    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

     
  • Tomas Hajny
    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.

     
  • @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.

     
    • status: open --> closed-fixed