Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124615
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885
Precedence: bulk
MIME-Version: 1.0
Message-ID: <d54b99fd-64ea-40f2-9fee-c904f1305893@app.fastmail.com>
In-Reply-To: <89096756-9f50-4b10-9630-d3b18e4b9c29@gmx.de>
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>
Date: Fri, 26 Jul 2024 14:20:00 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jul 26, 2024, at 11:11 AM, Christoph M. Becker wrote:
> On 26.07.2024 at 12:03, Gina P. Banyard wrote:
>
>> Stephen Rees-Carter, a security expert that has performed countless security audits on Wordpress and Laravel websites, would like to disagree with the fact that it is not enough of a good reason. [1]
>> A warning on a documentation page is useless, as nobody is forced to read it.
>
> Right, but even a deprecation notice is likely to be ignored by those
> (either use the shut-up operator, or use hash("md5), or maybe a polyfill
> to support old PHP versions), so the deprecation wouldn't help in such
> cases.
>
> (I've recently seen a new release of a software which still uses
> <https://www.openwall.com/phpass/>.  Apparently, the notice to prefer
> the password_*() API has been ignored or overlooked.)
>
> On the other hand, I'm quite confident that a deprecation could be
> useful for some developers, who would at least reconsider the use of
> md5/sha1 hashes, but just have overlooked this; although some static
> analysis should report respective issues.  However, there is certainly
> code without any static analysis, where at least this discussion appears
> to be helpful, e.g. our php-sdk-binary-tools might reconsider their use
> of md5() and md5(uniqid())[2].
>
> Note that I'm not against these deprecations, but I'm also not strongly
> in favor.  I see valid arguments from both proponents and opponents.
>
>> [1] https://x.com/valorin/status/1816593881791860963
>
> [2] <https://github.com/php/php-sdk-binary-tools/issues/21>
>
> Cheers,
> Christoph

One thing to remind people about, the deprecations for md5(), sha1(), and uniqid() explicitly say they cannot be outright removed before PHP 10.  That's at least 6 years away.  That gives a loooooong time for documentation, tutorials, instructions, and code to be updated.

That long deprecation period is the reason why I was comfortable voting yes.  This isn't something that would happen tomorrow.  It would be in at least two presidential elections from now.

--Larry Garfield