[php-maint] Possible release note for systems running PHP through CGI.

Ondřej Surý ondrej at debian.org
Mon Aug 20 12:57:10 UTC 2012


Hi all,

[multiple messages from d-d and d-r merged together]

> I am also concerned that a *simple* solution to restore the old
> behaviour in a secure way is not provided: maybe php5-cgi should install
> a sensible default configuration in /etc/apache2/conf.d/ ?

I have prepared new update for PHP based on comments from d-d. The
commit is here:

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a

To sum the changes:

- create dummy php5_cgi module, which has the required configuration inside
- enable this module if upgrading from anything older than 5.4.4-5
- the module is not enabled on fresh installs (user has to enable it manually)
- update NEWS.Debian to:

php5 (5.4.4-5) unstable; urgency=low

 Please be aware that the mime-types package dropped non-standard
 definitions for PHP that might affect any systems using PHP 5 running
 as CGI or FastCGI.  Following definitions were dropped:

  application/x-httpd-php                        phtml pht php
  application/x-httpd-php-source                 phps
  application/x-httpd-php3                       php3
  application/x-httpd-php3-preprocessed          php3p
  application/x-httpd-php4                       php4
  application/x-httpd-php5                       php5

 The php5-cgi package mitigates any known issues by creating a (dummy)
 apache2 module php5_cgi with a configuration containing handlers for
 all previously defined extensions.  Even though we believe that this
 configuration should keep your PHP scripts interpreted, it might be a
 good idea to check your apache2 site-wide configuration and also any
 specific PHP configuration for websites running on your system.

 As far as we know definitions from the mime-types packages are not
 used in any other webserver included in Debian, but it might affect
 any application which relies on system MIME types to interpret PHP
 files.

 -- Ondřej Surý <ondrej at debian.org>  Wed, 15 Aug 2012 10:31:31 +0200

- Update the README.Debian to match current state.

I will upload this change as part of 5.4.6-1 upload to Debian experimental
and if everything is ok, I'll merge it back to 5.4.4-5 targeted to
unstable->testing.

> As far as the mime-support package is concerned, I think that we reached the
> consensus that we will not add the entries back, and that the consequences will
> be documented in the php5-cgi package's NEWS file and in the release notes.

I agree on that, even though I think that PHP should have it's own
mimetype definition (same as python or perl, e.g. application/x-php,
but let's keep this discussion out of this issue, since it's something
different).

> I guess we could consider that for a very specific, low-popcon package.
> But knowingly interrupting upgrades for a well-known problem, on a very
> high number of systems? I'm not sure that's appropriate. Quite the
> opposite, actually.

I believe that update that I just did should solve any backwards
compatibility issues. (Crossed fingers... have to do thourough testing
first, I tend to make mistakes from time to time.)

> Many of the users of php5-cgi will be doing so because they are using other
> web servers. The discussion in #674089 seems to mainly revolve around
> Apache. How does this affect other web servers?

I am not aware of any other (Debian shipped) web server which uses
system-wide mime-types.  At least both nginx and lighttpd don't depend
on system mime types for interpreting PHP files (both use extension
based definitions).

>  - In Squeeze, using default configurations, files with ".php" in their name
>    such as "foo.php.jpeg" are executed as PHP scripts by the Apache web servers
>    runing PHP scripts through php5-cgi.

Charles, did you test that or you base that claim on Christoph's
mails?  I have just tested both php5-cgi in standard configuration as
recommended in README.Debian and this claim doesn't seem to be true:

$ wget -q -O - http://localhost:8080/index.php
bar
$ wget -q -O - http://localhost:8080/index.php.jpeg
<?php echo 'foo'; ?>

Also Apache2 documentation is very clear on that issue:
See http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext

> If more than one extension is given that maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html.

However there could be a problem when you use MIME-type and handler
together (which we *don't* use):

> Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being handled by the module associated with the handler.

> Maybe that's because it's expected they would be PHP scripts emitting
> JPEG files, not plain JPEG files? This seems like a feature to me, not a
> bug. Why was support for that removed?

My testing shows that the support for this was NEVER there in the
first place; neither in php5-cgi nor in libapache2-mod-php5. (Unless
you have jumped through some loops and used custom configuration not
recommended by upstream - in that case you will also probably have a
configuration which overrides our configuration anyway.)

O.
P.S.: Ccing me or pkg-php-maint increases the change I will see the
message and reply to you.
-- 
Ondřej Surý <ondrej at sury.org>



More information about the pkg-php-maint mailing list