> On Jul 27, 2024, at 7:24 AM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > > 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>) > > 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 — or adding features that benefit them in the near term — 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. 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. This would allow all code to continue functioning but over time any code that uses the functions will get slower. The code owners — not the developers — 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` — or ?enum flag parameter accepting Hashing::INSECURE_OK as its only value — thus allowing developers to explicitly opt-in to insecure use.
