Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124692
Message-ID: <03a76613-58e3-4b64-b906-360826d46fe3@bastelstu.be>
Date: Tue, 30 Jul 2024 21:52:26 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: Kamil Tekiela <tekiela246@gmail.com>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: PHP internals <internals@lists.php.net>
References: <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <1a88918e-e808-d778-45e1-53797660e093@php.net>
 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
 <c03eb187-bd21-4a4b-9faf-8d0243eaa994@varteg.nz>
 <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
 <3563cf9b-8eab-4c82-b525-a5d2f9a767bb@varteg.nz>
 <38920A4B-790D-48C7-B2F6-C49D3F506232@rwec.co.uk>
 <0824789d-0e36-4628-85c1-4b8d9b7f86af@varteg.nz>
 <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
 <CAGBsUrfqn9spaJfv+NWkCub0N-NgoK8uHRZew+beRO5pmRKqFg@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAGBsUrfqn9spaJfv+NWkCub0N-NgoK8uHRZew+beRO5pmRKqFg@mail.gmail.com>
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/28/24 14:24, Kamil Tekiela wrote:
> I have voted yes only because I thought it's about removing inconsistent
> function alias. I can't see anything wrong with this hashing algorithms and
> I don't consider them unsafe. However, as someone pointed out this doesn't
> seem to be correct as the crc32 function isn't part of the depreciation
> proposal. I am confused now as to why we are trying to deprecate these

crc32() is different, because the hash() function is not a direct 
drop-in replacement. The crc32() function returns an integer, whereas 
the hash() function returns raw bytes / hex encoded bytes (as with all 
hash functions it provides). Unfortunately one also needs to remember to 
use the 'crc32b' algorithm value, because 'crc32' is taken up by the 
bit-reversed bzip2 variant of CRC32. The 'crc32b' naming is something 
PHP-specific and non-standard :-/

The standalone crc32() could probably also be deprecated, given the big 
red warning in documentation. But it's sufficiently different from the 
standalone md5() and sha1() functions to not bundle it with them.

> functions at all. If it's about people confusing the hashing algorithms
> with password key stretching algorithms then that's not a valid reason. A
> red warning in the documentation should aid people in clearing this
> confusion.

No, it's about MD5 and SHA-1 being a bad choice nowadays and 
nevertheless being more prominently available than the alternatives.

Best regards
Tim Düsterhus