Hi Charles. On Thu, 2012-10-11 at 09:06 +0900, Charles Plessy wrote: > Do you think that there is a way to fix #589384 (the *.php.foo problem) > without removing the application/x-httpd-* media types ? I would say no, well at least not if we also want to use these media types later on in Apache to select something for interpretation. The problem with using /etc/mime.types via the TypesConfig directive in Apache is the usual with Apache: Most mod_mime directives (and maybe also others) will assign a media type if just any extension (i.e. also the foo in file.foo.bar) matches. The usual way around this is to place these directives in e.g. <Files ?*.bar> </Files> or <FilesMatch ^.+\.bar$> </FilesMatch> TypesConfig however is a server wide scope directive, so this won't work here. As I mentioned previously, I think it's very dangerous to use TypesConfig per default. It's evil by design and people should need to intentionally enable it (and then hopefully know what they're doing). I really think we should not fiddle around with mime-types anymore, or better: I think we should stop using it to "enable files for interpretation", even if that may break now some setups. Of course we should provide release notes hints on how to make them work again, which is usually quite easy. Also, please consider that people using "advanced" stuff like FastCGI can be expected to know what they're doing. > I did not realise before that in the current release cycle, Apache stays at > version 2.2 and that in Jessie, configurations will need to be re-adjusted > anyway. It would of course be nice, if we could postpone this to jessie, but... > I think that it is a good argument for a compromise, provided that > #589384 stays solved and that we agree that in Jessie the media types > application/x-httpd-* will be removed from /etc/mime.types. Right now I see no way to prevent the evil.php.jpeg issue otherwise. And note especially, that also FastCGI is in principle vulnerable to this. Though I haven't checked right now, how they actually select the PHP files for interpretation (which may or may not prevent the issue). > easy way to adjust the priority of > the SetHandler statement of php5_cgi.conf I think it's determined by the loading order... which makes it basically impossible IMHO to really make sure it gets loaded as we want it to. > in a way that does not break FastCGI > configurations. Even then we need to check whether fastcgi or fcgid are vulnerable to the evil.php.jpeg isseu. Cheers, Chris.
Description: S/MIME cryptographic signature