Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124661
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
In-Reply-To: <921dcf17-280b-4005-b31f-5811dbe5ce62@gmx.de>
Date: Sun, 28 Jul 2024 00:33:18 -0400
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <884458DE-74CF-4198-90E7-0BBBF828260F@newclarity.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>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 27, 2024, at 7:24 AM, Christoph M. Becker <cmbecker69@gmx.de> =
wrote:
>=20
> Hmm, such soft deprecations should be a good thing, but I'm afraid =
they
> are not really reaching much of the user base.  Remember ext/mysql?
> That was soft deprecated for "centuries", but still support channels
> were burning when it actually had been deprecated, and even after it =
had
> been removed.  (interestingly <https://pecl.php.net/package/mysql> =
still
> says the package would have been moved to <http://php.net/mysql>)
>=20
> Maybe, just maybe, it might be a good idea to repurpose E_STRICT for
> such things.  Basically a three step deprecation: first document that =
a
> feature is obsolete, then trigger E_STRICT, and only then =
E_DEPRECATED.
> I haven't really thought this through, though.

Reading this I pondered why long soft deprecations do not really work =
and why there is still a crisis when the hard deprecation happens. Seems =
to me that as long as those who prioritize spend can put off doing =
things with no short term benefit then there is no tangible incentive to =
update. People will (almost?) always prioritize addressing a current =
crisis =E2=80=94 or adding features that benefit them in the near term =
=E2=80=94 than remediating something that is not causing them a current =
problem.

I wondered if it would not be possible to give code owners an incentive =
to remediate without actually forcing them to? The one thing that I came =
up with is reduced performance over time.=20

Somehow I expect to get a firestorm of negativity for even suggesting =
this, but please hear me out.

Imagine we had another round of deprecation voting for md5(), sha1(), =
etc. and instead of it just being soft deprecated until PHP 10 then hard =
deprecated, what if we ADDED a sleep duration in each of those =
functions, and we escalate for each minor release. Start with 100 =
milliseconds delay per function call, and then add another 100 =
milliseconds delay each point release of PHP. =20

This would allow all code to continue functioning but over time any code =
that uses the functions will get slower. The code owners =E2=80=94 not =
the developers =E2=80=94 will then be incented to prioritize a =
remediation sooner than later. And the longer they wait the worse =
performance will get assuming they keep upgrading their version of PHP. =
OTOH their code will continue to work no matter what,. so they can put =
off remediating until it becomes their priority.

This would certainly get lots of libraries to be motivated to remediate =
as their users would get annoyed with the delays, and commonly used =
libraries can affect large numbers of installations. And since =
performance topics drive eyeballs, lots of developer websites would be =
motivated to write articles about how and why people should remediate =
those functions.

Something to consider?

-Mike

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` =E2=80=94 or =
?enum flag parameter accepting Hashing::INSECURE_OK as its only value =
=E2=80=94 thus allowing developers to explicitly opt-in to insecure use.=