On Fri, 2012-06-01 at 16:16 +0200, Stefan Fritsch wrote: > I would vote for > the release notes plus Release notes is a good idea, Stefan, Brian... can anyone of you take care of this or should I (but I'm on vacation starting next Tue, so that would take some time). > either apache2 or mod_php NEWS file. It seems > exessive to have it in the mime-support NEWS file since it is just > noise to all non-apache2 users. I'm not sure whether I can agree... At least mod_php is not enough,... people seem to always forget that it's totally ok (and IMHO from a security point of view even much better) to run PHP as CGI. Neither am I sure, whether Apache is enough, there may be other webservers in Debian that could use mime.types (though I haven't checked this). In principle, as mime-types is the canonical location of the change, the safest place to put it, would be there. > see below. Stefan, you haven't commented on this... I've already opened #674205, where I ask the php people to include what I'd consider the "safest/best" way to handle PHP mime-type in Apache. IF mime.types will really ship no further definitions for PHP AND if that change is accordingly documented in release-notes/NEWS file(s) than I think there should be no definitions for PHP in Apache's default configs at all. > The x-httpd- types are really historic ballast from the time there was > no separate way to configure the handler (Apache 1.3.x or even 1.2.x). > Because of their special properties, they are called magic MIME types > in apache httpd. Therefore I think they should be considered an > internal (and deprecated) implementation detail of apache httpd and > should not be used as real MIME types anywhere else. If we see it from that point, and given that the types are */httpd-* then I'm in principle ok with your interpretation and dropping it from mime.types. But we should perhaps check (how?) whether any other packages have started to use that mime type (things like nautilus/file/etc.) > As #589384 explained, declaring them globally is bad for security. And > it would be really strange to set these magic types globally just to > remove them with "RemoveType php" again in the default apache2 > configuration. Agreed upon. I've added this just a s safety measure to remove any definitions for .php that are potentially already in place and are prone to the "foo.php.jpeg" problem. > But adding a different type for .php to /etc/mime.types is fine with > me. There is some discussion at http://cweiske.de/tagebuch/php- > mimetype.htm which type may be best. Both text/x-php and > application/x-php seem ok to me. As outlined before, I wouldn't use text/ anymore... and further... I'd strongly recommend against any type that is not and */x-* type... (unless there was an official delegation). OTOH,... there's no need to discuss such a type now, right? As soon as someone needs it, he will step up. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature