> Le 8 oct. 2019 à 11:44, Björn Larsson <bjorn.x.lars...@telia.com> a écrit :
>
> Den 2019-10-08 kl. 11:00, skrev Claude Pache:
>>> Le 8 oct. 2019 à 10:26, Björn Larsson <bjorn.x.lars...@telia.com> a écrit :
>>>
>>> Den 2019-10-06 kl. 15:41, skrev Mark Randall:
>>>> On 06/10/2019 14:18, Reinis Rozitis wrote:
>>>>> Since `` are used for literal strings (for poorly chosen reserved words
>>>>> as field, table names (which happens from time to time)) in MySQL
>>>>> (multiline) queries I doubt there is a simple way to distinguish and
>>>>> replace everything to exec().
>>>> Hi,
>>>>
>>>> As the RFC states, there are already widely used tools available which can
>>>> do this reliably:
>>>>
>>>> https://github.com/FriendsOfPHP/PHP-CS-Fixer
>>>> backtick_to_shell_exec
>>>>
>>>> --
>>>> Mark Randall
>>>>
>>> Even if there are good tools, there is a cost in doing the upgrade
>>> not just for doing the coding work, but also testing. Assume we
>>> have legacy code that works perfectly, so what is then the benefit
>>> to upgrade unless it goes in together with other features?
>>>
>>> Motivating to get a small budget to fix this in small company is
>>> not obvious. The purity of PHP won't fly I think ;-)
>>>
>>> r//Björn L
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>> When evaluating the _unique_ cost of migrating legacy code, it should be
>> balanced with the _continual_ cost of keeping the feature. That includes:
>>
>> * People wondering what that strange syntax does, or, worse, mistaking it
>> with a variation of string literal.
>> * Difficulty to search occurrences of `shell_exec`.
>> * People trying to deactivate functions executing external programs (such as
>> `shell_exec`) using the "disable_function" ini directive, wondering how to
>> deactivate the backtick operator (since there is no `disable_operator`
>> directive).
>>
>> —Claude
>>
> That's a fair point. When it comes to the first two ones one
> might wonder how much pain these has caused historically,
> given that the feature has been around for a long time? Not
> sure how to get hard facts on it though.
>
> For the third one, one idea could be to extend the current
> directive also working for backticks or create a new one.
> Would that be an improvement?
>
> r//Björn L
The improvement for the third point is to have a proper directive that disables
every functionality relating to executing external programs on the machine,
instead of letting people figuring out by themselves the list of functions to
be disabled. But we’re deviating from the subject. I was just intending to give
possible examples (not a comprehensive list), illustrating that there are also
costs for doing nothing.
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
