Hey folks. On Tue, 2012-10-16 at 00:16 +0200, Stefan Fritsch wrote: > And remove the php-cgi.conf completely, right? So this would introduce > a different fix for the multi-views problem. Are you sure that there > is no other problem that we would re-introduce? Maybe it's worth a > try.
> There is at least no solution that is obviously right. I fear that > regardless what we do, we will break some configs. I'd say we should "sit" together after wheezy however,... searching for some best-as-possible-overall-framework ;) > Besides removing the media types from /etc/mime.types, one could add a > "RemoveType php ..." to the apache config (but where?). I proposed that previously to Ondřej but only as a poor-man's guarantee... I wouldn't want to see that we really rely on it,... cause it may easily break... One never knows what upstream changes... e.g. at some day there might be a change in the order of evaluation from RemoveType and TypesConfig... or evil things like that... > Or maybe, one > could also set "AddHandler default-handler php ...". The latter is an > idea I just had, I have not thought it through or tested it. Sounds like it could work,... and actually a nice idea ;) ... but it seems somewhat ugly to me... you know adding handlers and assigning stuff just for hackings something into... We cannot know how much something like this breaks... just imagine if a user has already his own "default-handler" defined. > Maybe it would be better to create a single document with all possible > solutions and pro and cons? I have started to create such an overview > at http://wiki.debian.org/Apache/WheezyMimeTypes but it is not > finished yet. Feel free to add more infos/solutions/pros/cons. The > page may come in handy for the Jessie, too. Good idea... I hope I'll find some time into looking at it... But in general... I'm a bit scared that we clash into the release of wheezy with neither a perfect nor an at-least-somewhat-secure solution. So question the the group is: Should we continue with investigating in a perfect solution (and that wiki seems to somewhat go into that direction)... or should we simply admit there's a shitty situation for wheezy... add the necessary release notes with big fat exclamation marks... and shame ourselves till we come up with the uber-solution in jessie? ;-) > Christoph: For mod-fastcgi/mod-fcgid, the file.fcgi.foo problem is > somewhat mitigated that they require "Options ExecCGI", too. And > AFAICS that is not set by default. Any opinions if this is "good > enough" for wheezy? I lean towards yes, but maybe I am missing > something. Well... phew... I mean don't get me wrong... nearly all what we do here is about teaching users and/or helping them not to shoot themselves... so in theory you're right and this is enough... on the other hand: Practise looks like this that users often have merely an idea what they do... and I'd feel better, if both mods also place some <Files> block around. Actually,... I'd even feel better if they stop automatically enabling things. And this is not my usual security-paranoid installed-packages-shouldn't-enable-their-stuff-automatically talking... it's rather that in this special cases (namely Apache)... they enable things globally for the whole server... which is (to my experience) rarely needed. We could help users from potential security troubles,... if we "force" them to decide in which context they want to enable things. But how to proceed now? In general, if we "secure" these two mods from the evil.fcgi.jpeg issue, we have the same problem as with PHP (there Ondřej added a according entry to NEWS and README.Debian) namely that we potentially break some setups (those from such devilish admins coming straight from hell and used http content negotiation in some way with their interpreted stuff. I personally think it's definitely worth! Then we have the options: a) Either just secure it with <Files> blocks around the diretives that add the handlers... b) or disable global per-default activation but still document in each of the two packages how to do it right. I'd vote for (b). Depending on what you guys from the Apache Maintainer group say... I'd open respective bugs, and help Tatsuik and Taku with documentation and stuff... Chris.
smime.p7s
Description: S/MIME cryptographic signature
