Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124627
Message-ID: <5a508fb6de62932d0f17aa859bde828d9531cfd1.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: internals@lists.php.net
Date: Fri, 26 Jul 2024 16:13:28 -0400
In-Reply-To: <cf0f0b2b-5df8-4b7b-bb03-a705f37d5e4a@app.fastmail.com>
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>
	 <6c0baa01-68e5-4d74-bc4e-d6830ab5076d@bastelstu.be>
	 <cf0f0b2b-5df8-4b7b-bb03-a705f37d5e4a@app.fastmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0
From: lists@ageofdream.com (Nick Lockheart)

>=20

> In regards to hashing, this is likely fine; for now. There still
> isn't an arbitrary pre-image attack on md5 (that I'm aware of). Can
> you create a random file with a matching hash? Yes, in a few seconds,
> on modern hardware. But you cannot yet make it have arbitrary
> contents in our lifetime. The NSA probably has something like this
> though, but if so, this isn't widely known.

The NSA likely owns "Let's Encrypt" and can therefore MitM every TLS
site on the internet.


> If the problem is that the web is full of bad documentation, find or
> write some GOOD documentation. Then, work out how best to signpost
> users to that documentation. Deprecating md5() and sha1() does
> neither.

This. I'm not going to quote everything, but I read through the
comments from today and would say this:

1) This seems very much like the people in support of these
deprecations are trying to push PHP to enforce *policy* on developers,
rather than simply providing tools.

2) PHP should provide good documentation, but should not try to force
every user to do something "best practice" by renaming functions.

3) If a websever/host updates the PHP version and the code breaks, the
last thing a dev is looking for is "what's the best practice to
refactor this code".

The dev is thinking, "our site is down, the boss/client is angry,
what's the fastest band-aid I can slap on this to get the site up
again".

Thus:

Provide tools, not policy.

Provide good documentation.

--
Nick