[php-maint] Bug#687307: Fwd: Updating php5 to 5.4.4-5 broke FastCGI setup on my machine

Christoph Anton Mitterer calestyo at scientia.net
Tue Oct 16 01:45:06 UTC 2012


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5450 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20121016/95dfe7a4/attachment-0001.bin>


More information about the pkg-php-maint mailing list