Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124438
Message-ID: <0648d816-02c9-4033-a340-9934ba3de6d4@bastelstu.be>
Date: Mon, 15 Jul 2024 22:52:38 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
 <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
 <668B5728.40300@adviesenzo.nl>
 <4cf169f4-e222-4140-aef7-20eb5b871d32@heigl.org>
 <668B73B6.7070509@adviesenzo.nl>
 <7a86d94a-bacb-4f72-9eb2-da89b5fc0f13@heigl.org>
Content-Language: en-US
In-Reply-To: <7a86d94a-bacb-4f72-9eb2-da89b5fc0f13@heigl.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/8/24 07:25, Andreas Heigl wrote:
>> I don't mind putting the work in when there is a good justification, but
>> I don't see one for this deprecation.
> The only one I can see is cleaning up the codebase and removing
> duplicate methods.
> 
> But the RFC definitely states that it is to "encourage users to use a
> secure hash functions, instead of using an insecure algorithm"
> 
> Which is fine. But I am totally with you that deprecating a function by
> encouraging users to use the same insecure algorithm via a different
> function is ... an interesting take to say the least.
> 

Gina already mentioned it in the long email from earlier today, but for 
reference:

The intention is that the users do not perform a mindless search and 
replace, but instead use the opportunity to re-evaluate the choice on a 
case by case basis.

Cleaning up the codebase is not a concern, because the implementation of 
the functions is trivial.

However cleaning up the documentation and API surface *is* something 
that is useful. As an example it is easier for the (inexperienced) user 
to navigate the documentation, because all the hashing functionality is 
available by the standard 'hash' functions. It also makes maintaining 
the documentation easier. As an example a few months ago, I updated all 
the examples to no longer showcase 'md5' and instead showcase the usage 
of 'sha256':

https://github.com/php/doc-en/commit/20dcfbb0dd7150cbe5dfd7903a3001229295c549

Of course the functions still support MD5, but now the documentation 
shows current best practices. Anyone whom I trust to use MD5 safely, I 
also trust to understand how to use it by means of the hash() function 
and for all the others the examples will be helpful in writing safer code.

Also once the users migrated to the hash() function, they will be able 
to switch out algorithms much more easily going forward, because the 
algorithm choice can easily be stored in a central configuration and 
passed as a string. (no, no one calls functions using a dynamic name).

In other words, the goal of the proposal is the anticipated positive 
downstream effects in overall ecosystem safety and simplified learning 
curve for new PHP developers.

Best regards
Tim Düsterhus