Bug 24933 - latest php errata breaks HORDE/IMP
Summary: latest php errata breaks HORDE/IMP
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: All Linux
Target Milestone: ---
Assignee: Phil Copeland
QA Contact: David Lawrence
: 25152 25250 25322 25670 26116 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-25 15:04 UTC by Arenas Belon, Carlo Marcelo
Modified: 2005-10-31 22:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-06 22:26:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Arenas Belon, Carlo Marcelo 2001-01-25 15:04:47 UTC
tested on latest stable 1.2.3/2.2.3 and also on beta branch (1.3.2/2.3.6)
there is no way to send messages as there are several strange errors.

on both HORDE/IMP versions there is a warning on imp/compose.php? (line 248
of compose.php3 on stable version) regarding an undefined index :

Warning: Undefined index: Send Message in compose.php3 on line 248

the code affected is :

if (strcspn($actionID, '0123456789')) {
  $actionID = isset($actions[$actionID]) ? $actions[$actionID] :

somehow, the $actionID doesn't resolve to the corresponding index on the
$actions array and remains as an string ("send message" or whatever is used
on the locale defined)

on the beta branch of horde there is also a problem to call the
Mail_sendmail ->  send() method created from the instantiated Mail::factory

the following code gives error while calling the send method :

require_once ("Mail.php");
$mailer = Mail::factory('sendmail', array());
$recipients = "foo@bar.com";
$headers = array (
  "From" => "foo@bar.com",
  "To" => "foo@bar.com",
  "Subject" => "foo"
$msg = "bar";
$status = $mailer->send  ($recipients, $headers, $msg);
print $status;

Comment 1 Arenas Belon, Carlo Marcelo 2001-01-27 02:16:05 UTC
the beta bug related to a problem calling Mail_sendmail->send() is related to a
problem on the path to PEAR, see bug 24940 for a description to this problem

after the path is fixed, the error goes away

Comment 2 Nalin Dahyabhai 2001-01-29 20:08:55 UTC
Probably related to #25152, as Horde makes heavy use of forms IIRC.  We'll have
to investigate.

Comment 3 David Golden 2001-01-29 20:44:46 UTC
Some crude (printf) testing on my part revealed that the error appears related 
to the fact that $actionID (returned from the form) contains " Send Message", 
not "Send Message".  (I.e., leading space)  Other fields ($to, $subject) in the 
same script show a leading space as well.  What happened in the form code from 
4.0.4p1-1 to 4.0.4p1-3?

Comment 4 Nalin Dahyabhai 2001-01-29 21:08:04 UTC
This confirms my suspicions.  The parsing code which handles multipart form data
is pretty messy.  If the name of the variable (say, "foo") wasn't quoted, the CR
from the CR/LF pair at the end of the line was taken as part of the variable
name.  This bug was tickled by Lynx 2.8.3 and earlier, but not Netscape
Navigator (or Mozilla, IIRC).

Terminating at the CR (which fixes the variable's name) seems to be pushing the
LF into the front of the value of the variable, which is a problem in how we
tried fixing the parsing bug.  This means that it's probably the cause of the
problem in 3.0.18 as well.


Comment 5 Nalin Dahyabhai 2001-01-29 21:13:48 UTC
*** Bug 25152 has been marked as a duplicate of this bug. ***

Comment 6 Nalin Dahyabhai 2001-01-30 06:08:06 UTC
*** Bug 25250 has been marked as a duplicate of this bug. ***

Comment 7 Nalin Dahyabhai 2001-01-30 11:30:54 UTC
Please test either php-3.0.18-6.2 or php-4.0.4pl1-5 from
http://people.redhat.com/nalin/test/ and see if this fixes
the problem behavior you're seeing.

Comment 8 David Golden 2001-01-30 15:59:34 UTC
I installed php-4.0.4pl1-5 and it *does* appear to fix things.  I was able to 
send mail and save as draft from IMP 2.2.3, both of which were broken before.  
Thanks for the quick turnaround.  (I have not done any code-level testing, just 
an RPM -Uvh, restarted httpd, and gave it a try.)

Comment 9 Nalin Dahyabhai 2001-01-30 20:23:22 UTC
Actually, when I came back in this morning I found that it doesn't work right
all the time (both Netscape Navigator and IE5 on Windows still trip it up, while
it works fine with Navigator and Lynx under Linux, grrrr), so I still have some
debugging to do on this.

It may take a while since I'm going to be out of town for a few days.

Comment 10 Nalin Dahyabhai 2001-01-30 20:31:55 UTC
Scratch that.  Having multiple versions of PHP floating around on my test
machine is making me crazy.  I'll bounce the existing patches off the PHP team
before I hand this off to QA for another errata release.

Comment 11 Nalin Dahyabhai 2001-01-30 20:55:52 UTC
*** Bug 25322 has been marked as a duplicate of this bug. ***

Comment 12 Victoriano Giralt 2001-01-30 23:06:48 UTC
Having upgraded to php-4.0.4pl1-5, the newline at the start of the fields have
disappeared (at least in Netscape on Linux) but now, there is no document-type
for the uploaded files.

Comment 13 chrismcc 2001-01-31 15:58:43 UTC
I tried php-4.0.4pl1-5 ( recompile on a RH6.x machine).  Still broke.  My test
is phpMyAdmin.

Also, curl is missing from php.ini


There maybe others, but this one I saw

Comment 14 chrismcc 2001-02-01 19:25:43 UTC
FYI,  I used the spec file from 4.0.4pl1-? but used the 4.0.3pl1 tarball.
Same problem.
This could be a spec file ./configure or patch problem not a php4.0.4pl1 problem.

Comment 15 chrismcc 2001-02-01 20:12:51 UTC
scratch that last comment. My test was faulty.

Comment 16 Nalin Dahyabhai 2001-02-02 06:08:52 UTC
vic, if I'm reading the parsing code correctly, the fix applied shouldn't have
modified the section which deals with file uploads.  Data entered into form
fields did not have its content-type saved any where, which was part of the
problem (the code assumed that the content-type header was actually the blank
line which marks the end of a header set, so the blank line would be counted as
part of the data set).  If I'm remembering it correctly, the code which handles
file uploads was actually not changed, but I'll have to have another look at it
just to be sure.

chrismcc, we currently can't build in a curl extension because curl is not
itself in the main distribution.  This may change in an upcoming release.

Comment 17 chrismcc 2001-02-02 16:34:50 UTC
For the curl thing see:
and  php-4.0.4-redhat.patch from the srpm
There could/should be a:
in the php.ini file.  Not because curl is included, but so that someone else, a
sysadmin, could write up a curl.rpm,curl-devel.rpm,curl-libs.rpm, and a
php-curl.rpm without recompiling all of php.
This is especially easy now that there is a php-devel rpm!

Comment 18 Pekka Savola 2001-02-02 23:23:13 UTC
*** Bug 25670 has been marked as a duplicate of this bug. ***

Comment 19 Nalin Dahyabhai 2001-02-03 02:56:26 UTC
chrismcc, point taken.  Change will be made in php-4.0.4pl1-7, which will
probably be built as the new candidate at some point this weekend.

vic, I've just run php-4.0.4pl1-6 from Raw Hide on a workstation, connected
using multiple clients (Navigator 4.72, 4.75, and 4.76, Mozilla 2001012900, and
Links 0.95 on Linux and IE5 on Win2k), and captured the requests being submitted
by clients.  Navigator and Links on Linux don't supply a Content-Type header for
the file upload field (tested using /etc/passwd), so I wouldn't expect a type to
be available, but Mozilla supplies "application/octet-stream" (again, with
/etc/passwd), and IE5 supplies "text/plain" (tested using one of the log files
in c:\), and both show up in the structure.

Which browser/OS combination are you seeing this with?  I'd like to verify
whether or not the client actually supplies a Content-Type header for the field
in its request.  I *think* this is the only outstanding issue with 4.0.4pl1-5,
aside from the commented-out curl extension and the openssl extension once again
being buildable with 0.9.5a.

Comment 20 chrismcc 2001-02-03 20:34:03 UTC

php-4.0.4pl1-6 from rawhide

My test (broken app) was phpMyAdmin
System RH 6.x, updated, tweeked

spec was edited to remove references to db-2 and db-3

natlin, 'you da' man!'

Comment 21 Victoriano Giralt 2001-02-04 18:47:52 UTC
nalin,  I'd ben using the content-type for uploaded files quite a while in
disparate environments, with excellent results, both for PHP/Apache on LInux or
things like DCL (Digital Command Language) with OSU DECThreads Web Server on
OpenVMS. It looks like the browsers have a very windowish behaviour in this
matter, they supply a content type based on the file extension (anything behind
the last dot), that's why you are getting nothing or octect/stream for
/etc/passwd. I have installed 4.0.4pl1-6 from rawhide (by the way it complaints
about libpq.so for php-pgsql and liblber.so and libldap.so for php-ldap,
although they are in the system) and everything is working again, at least from
Netscape and Mozilla on Linux.

Greetings, and congratulations for such excellent responses

Comment 22 Nalin Dahyabhai 2001-02-05 06:11:41 UTC
vic, the Raw Hide variants are built using the versions of OpenLDAP and Postgres
in the Raw Hide tree, and while I don't know about Postgres off the top of my
head, the OpenLDAP package has had a change in the version of the libldap.so
shared library which breaks compatibility with RHL 7.

The updated openldap package contains the new shared library, and the new
openldap12 package includes the older version to maintain binary compatibility.

Given that the current revisions seem to work for everyone, I'm going to hand
them off to QA for testing for release as a bug-fix errata.

Comment 23 John Dalbec 2001-02-05 14:47:42 UTC
IMP 2.3.3 uses "date('r')" which needs a CVS patch to fix a buffer overflow ("tmp_buff" is too small).
Have you incorporated this change?

Comment 24 chrismcc 2001-02-05 15:05:07 UTC
is that a patch to imp or php?

Comment 25 Nalin Dahyabhai 2001-02-06 00:45:07 UTC
*** Bug 26116 has been marked as a duplicate of this bug. ***

Comment 26 Oliver Schulze L. 2001-02-08 18:14:19 UTC
I have installed the php-4.0.4-pl5 from here:

And IMP 2.2.3 works fine again.
Does IMP work the php-4.0.4-pl6 ?

Comment 27 Joe Mitchell 2001-02-20 06:04:56 UTC
I'm not sure if this helps, but I tried to install Horde with php-4.0.4pl1-3 installed which seems to remove the old mod_php3 (RHSA-2000-136) and had 
failed dependencies:

# rpm -Uvh horde-1.0.11-1.noarch.rpm 
error: failed dependencies:
        mod_php3 >= 3.0.7 is needed by horde-1.0.11-1
# rpm -qa | grep php

Comment 28 Arenas Belon, Carlo Marcelo 2001-03-07 15:11:15 UTC
any ETA for an errata that fixes this problem?,  bug 30877 and an unreliable
imap module could mean there are lots of HORDE/IMP not running the errata and
still vulnerable to the imap overflows.

also. -6 is not longer available from rawhide nor the
http://people.redhat.com/nalin/test page and without the "RedHat 7 compat" rpms
is useless on binary form.

granted you can rebuild your own package but a "blessed" one would be great


Comment 29 Rob McMillin 2001-03-27 03:13:39 UTC
I'm pretty sure this is PHP bug number 8966 (http://www.php.net/bugs.php?id=8966); according to them, it has been fixed (the bug, of course, doesn't 
say in which version it's been fixed).

Comment 30 Russell McOrmond 2001-03-28 20:05:53 UTC
Just to add confusion to this bug, I have a number of TWIG
<http://twig.screwdriver.net/> installations where having the RedHat patch to
deal with this bug actually caused TWIG to not function.  I ended up building
new RPM's which removed the php-3.0.18-parse.patch and all runs well now.

Note:  I have so far only tested TWIG with Netscape, so if this is a problem
where IE and Lynx behave differently then I have not yet tested this (I don't
run Windows so don't have IE available, and don't have an SSL aware Lynx and all
my installations of TWIG are on SSL servers)

Comment 31 Need Real Name 2001-12-21 06:26:12 UTC
This is also broken in 6.2 with the php-3.0.18-1.6.x release.

Comment 32 Daniel Senie 2002-01-06 22:26:06 UTC
Umm, hello? This bug was last seriously being looked at in March 2001. A "fix" 
is referenced as being on nalin's web page, but it's no longer there. It 
appears the errata which is talked about never was created.

Is there any chance this will get cranked into an errata and fixed? There are 
folks out here waiting for this!

PLEASE either fix this thing, admit you're not going to fix it, or something.

Comment 33 Phil Copeland 2002-06-04 21:10:09 UTC
There's no datestamps on this record so I've no idea how long this has been open.
Going by what I've read in this, the currently available errata should have all
this fixed.



Comment 34 Oliver Schulze L. 2002-06-04 21:26:41 UTC
wow, where are the timestamps?
I have using IMP 3.0 on RH7.2, so I think it is solved.

Note You need to log in before you can comment on or make changes to this bug.