Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124691
Message-ID: <112d479e-b10c-4b0b-804d-1d9f59183fba@bastelstu.be>
Date: Tue, 30 Jul 2024 21:24:29 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: Mike Schinkel <mike@newclarity.net>,
 "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, 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>
 <95147d9d-d6e8-4396-bf0b-409c33679f90@bastelstu.be>
 <CAPrKfG4TijmZ_N9512_Fk9MBUNg=E6PjNTy-bCbV8CAj9_wX8A@mail.gmail.com>
 <CAPrKfG7Hi0SGbLA31V-9KjHM50QaX+Q=PptuO4+VMOrz7d9eBA@mail.gmail.com>
 <G9IiDe18a2ZhrXPA-zljNZsawKCZxlTn2ACfJpM32scdRkRflZ2rM6Ra8z88ZYDczomex4pffxZMpVhEjdB74YQXXNyqJkd7rQdDGA14HC0=@gpb.moe>
 <89096756-9f50-4b10-9630-d3b18e4b9c29@gmx.de>
 <d54b99fd-64ea-40f2-9fee-c904f1305893@app.fastmail.com>
 <3beb3488-94fc-484e-ac6c-ce7a7a0facd2@app.fastmail.com>
 <921dcf17-280b-4005-b31f-5811dbe5ce62@gmx.de>
 <884458DE-74CF-4198-90E7-0BBBF828260F@newclarity.net>
Content-Language: en-US
In-Reply-To: <884458DE-74CF-4198-90E7-0BBBF828260F@newclarity.net>
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 06:33, Mike Schinkel wrote:
> P.S. Frankly, I really would not want to see md5() nor sha1() removed because there are valid use-cases for them. I would at least like to see them kept in some form, maybe in an `\Insecure` namespace, or renamed `insecure_md5()` and `insecure_sha1()` or maybe add a third optional bool parameter `$insecure_ok` that defaults to `false` — or ?enum flag parameter accepting Hashing::INSECURE_OK as its only value — thus allowing developers to explicitly opt-in to insecure use.

Renaming the functions would do nothing but make this a backwards 
compatibility break, whereas a deprecation does not.

Remember: The algorithms are also available by means of the hash() 
function (and the related functions), without emitting a deprecation, 
warning, error, or Exception.

Best regards
Tim Düsterhus