On Mon, 2012-10-08 at 15:38 +0200, Ondřej Surý wrote: > Just one last question which came to my mind. Would this all be fixed > if we added non-magic type to mime-support (e.g. > http://bugs.debian.org/670945) and reverting the changes done in the > php5-cgi package? I'm a bit unsure how/why that would fix the general problem? Perhaps you can elaborate a bit more on what your ideas are :)
I haven't looked into absolute details but I think the main problem here is, that different SAPIs use different fixed handler-names. And even if all would use the same,... we'd have a problem, namely how to select the right one. > That I think would justify change in the mime-support package. Too > much breakage on every front now. Well... I think it's quite dangerous to again play around at mime-support. I mean we all know the problems arising from there,... not only the security issues like foo.php.jpeg, but also that we are again quite dependant on some other package. Admittedly, we're in quite a shitty situation now, so close to wheezy, but I somewhat agree to Stefan, in better just adding some more release notes. The next step would/could be to think about post-wheezy release goals for the overall PHP framwork in Debian. Which includes IMHO: - unifying as much (apache) configs as possible for the different SAPIs - other packages (i.e. packaged PHP programs) should not rely on PHP being activated by the php packages (especially not globally), but should rather give the user a debconf option on where (which webserver) to activated it how (always only "local" scope,... and questioning which SAPI) - make the different SAPIs co-exist more "out-of-the-box"...which i.e. also addresses this very bug.... The ideal state would be that one can enable all SAPIs in one Apache instance and even use them in the same vhost... differentiating per <Directory> (well at least as far as this is possible for all the SAPIs). Maybe this requires that we patch things like mod_f(ast)cgid ... to use other handler names. I have not yet an idea how all this could be achieved. But back to this very bug: If we say we "solve" this for now, by just adding release notes as Stefan proposed... then there is still one important thing left. Namely those I asked in the mails from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#59 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#69 May we run into the problem, that again, files are accidentally served (as files)? Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature