[php-maint] Bug#668053: Bug#668053: Bug#668053: [php5-common] php.ini-production does not actually have production values

[Thijs Kinkhorst]

On Sun, April 8, 2012 22:18, Filipus Klutiero wrote:
> On 2012-04-08 13:07, Thijs Kinkhorst wrote:
>> On Sun, April 8, 2012 18:36, Filipus Klutiero wrote:
>>> That's not an opinion, that's a bug. Compare
>>>> ; Production Value: Off
>>> with
>>>> short_open_tag = On
>>> Off != On
>> I think what confuses you is that the comments in the php.ini indicate
>> what upstream considers production values, while what we ship is
>> different
>> from that because we do not think that short_open_tag necessarily needs
>> to
>> be off for environments considered 'production'.
>>
>
> That looks like it. debian/rules "sanitizes" php.ini files:
>
>> 	# sanitize php.ini file
>> 	cat php.ini-production | tr "\t" " " | sed -e'/short_open_tag =/
>> s/Off/On/g;/session.gc_probability =/ s/1/0/g;/disable_functions =/
>> s/$$/ $(PCNTL_FUNCTIONS)/g;'>
>> debian/php5-common/usr/share/php5/php.ini-production
>> 	cat php.ini-production | tr "\t" " " | sed -e'/memory_limit =/
>> s/128M/-1/g;/short_open_tag =/ s/Off/On/g;/session.gc_probability =/
>> s/1/0/g'>  debian/php5-common/usr/share/php5/php.ini-production.cli
>> 	cat php.ini-development | tr "\t" " " | sed -e'/short_open_tag =/
>> s/Off/On/g;/session.gc_probability =/ s/1/0/g;/disable_functions =/
>> s/$$/ $(PCNTL_FUNCTIONS)/g;'>
>> debian/php5-common/usr/share/php5/php.ini-development
>
> So it looks like we're changing the value of 3-4 default settings from
> the upstream value, but we're not updating the corresponding
> documentation.

I disagree. The comments contain advice by PHP upstream on what to do. We
supply this advice to the user, but at some points set other defaults.
That does not mean that the advice is necessarily wrong. See below for
explanation in this specific case.

> By the way, regarding short_open_tag, according to php.ini
> "php.ini-production contains settings which hold security, performance
> and best practices at its core."

I don't think anyone disagrees with those goals.

> and:
>> This directive determines whether or not PHP will recognize code between
>> ; <? and ?> tags as PHP source which should be processed as such. It's
>> been
>> ; recommended for several years that you not use the short tag "short
>> cut" and
>> ; instead to use the full <?php and ?> tag combination. With the wide
>> spread use
>> ; of XML and use of these tags by other languages, the server can
>> become easily
>> ; confused and end up parsing the wrong code in the wrong context. But
>> because
>> ; this short cut has been a feature for such a long time, it's
>> currently still
>> ; supported for backwards compatibility, but we recommend you don't
>> use them.
>
> So I don't think short_open_tag should be enabled in php.ini-production.

We're obviously well aware of these considerations by upstream. While the
principle is true that having short_open_tag Off is better, as with
everything there's a tradeoff involved. If you're starting an entirely
blank project from scratch, you really shoudl work only with the setting
off. However, the world is not perfect and there are uncountable amounts
of scripts out there that rely on this feature. We have to balance
breaking all this software against the benefits. Although the benefits as
they are described are real, they're not of extremely high importance.
This makes this case different from e.g. register_globals, where there's
also a large installed base of software relying on it, but the drawbacks
of that function are much much larger than that of short_open_tag, which
are relatively minor.

So the choices are 'ideal production setup' v.s. 'generally workable
defaults without too many adverse effects'.


Cheers,
Thijs