Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124431
Message-ID: <61cbb650-17d7-4dbf-a73b-8265d6af2d4f@gmx.de>
Date: Mon, 15 Jul 2024 15:56:42 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
Content-Language: de-DE
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>,
 internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
 <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
 <668B5728.40300@adviesenzo.nl>
In-Reply-To: <668B5728.40300@adviesenzo.nl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:BaLD/weVKes=;MoGw15POcL9N/PVbePf5DHqUZtM
 643SUbU9QOOzvdDGfBlxHip5qbK6X5Bf/lVRKLDB96gIXSU8ue2zbdTkI68QjN6LrqMWnRLmp
 AwuX+4b6mdwLLgEjsEIm7XFjkY6T7cAdBPDZKZx4ku5M07FTKS1NAMnitcL7jg+31usuRfI2/
 yxmWqvsH+J08k0TnJWxvL27p/+fefy5f8m23SEGaBfvqSXfSVvqJGRsgvHUo+A47ZKEQBLlfE
 MzA+AQd4u2g4PgGjIWRudlHiSpGmJP0lJqbiZQoYnHLrZh7rnhs7k0JyutnZhVHtSlxbESrJV
 mPmJdU9+bTlYo3qtWn8yZOaL5CedNMyeJIuDKF13WzeJcuy580IdeWMTJ03Ro7TsPsZ29NGGR
 cdk0PxasajMoJKwF8lL4VvUwST8WgA7wNlvt04cJ0BTr4JahYcDGuS74rWPEDcEsccSDjoAek
 80/pDC1ULd8RH2QrvWQvmER0idxd5C3Snk5Y44kNUwuC6GwckpjB05R/XCawqFXdnTIhkXibc
 HPcZv+ystyCCKiwLUEKjcGHNtp/0HcJWvuGGtUUVFxjodDG++lsBF0FQQT+2U6nvpnijELMma
 +dsAc+ITeAVUR8fZbDWe+ztq8dLJsrVxecr+tSFhiQweZmuH95igKeKQEkSDv1dqAHgMJTF5y
 INUfNua8fg49UpCL8jpkOPU+g4tZekG8iO0CdnmoDJnNS1Plq+fPB/TtMhUudQhJfldMUTF57
 Ixgcb2tFUkJ0ZuIkkpFSN383EHd4B0xK0b9ckfq4PkuxzRcnY2m/9Ebjl9qSDi5i6SwyiImi+
 BSx8aTJXRU0M3bg1J4B+xnBCAXk5JJl8lm7g30ZnWWfMQ=
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 08.07.2024 at 05:04, Juliette Reinders Folmer wrote:

> On 2-7-2024 20:05, Gina P. Banyard wrote:
>
>> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
>> <php-internals_nospam@adviesenzo.nl> wrote:
>>
>>> Other than that, I join the previously voiced objections to the
>>> deprecation of `uniqid()`, `md5()`, `sha1()`, `md5_file()`,
>>> `sha1_file()`.
>>> While I acknowledge that these functions _can_ be used
>>> inappropriately for security-sensitive code, which should use
>>> alternative methods, these functions have perfectly valid use-cases
>>> for non-security-sensitive code and the impact of the BC-break of
>>> deprecating and eventually removing these methods can, IMO, not be
>>> justified.
>>> Keep in mind that while "we" know and understand that deprecations
>>> are not errors, end-users often don't and particularly for open
>>> source projects, this means that in practice these deprecations will
>>> need to be addressed anyway to reduce the noise of users opening
>>> issues about them, which without a clear path to removal of the
>>> functions, will, in a lot of cases, mean adding the `@` operator to
>>> all uses.
>>
>> If I may be a bit cheeky, if we consider that userland does not
>> understand that deprecations are not errors, how can we trust them to
>> use the 5 aforementioned functions correctly?
>> Especially as there are more appropriate replacements available.
>
> There is a difference between "userland"=C2=A0 (dev-users) and end-users=
. I
> was talking about end-users, while based on your remark, you are talking
> about dev-users.

To clarify, by end-users you are referring to users who install and
"operate" (open-source) software on (shared) hosting.  If so, indeed
they may stumble upon deprecation notices, and from my (limited)
experience, they will report that as issue, unless the software
developers release a new version which does not trigger these
deprecation notices.  This is unfortunate, but I really do hope that
these developers only use the shut-up operator when all else fails, and
that they remove it as soon as possible.  Yeah, even more work, but that
is what you are sometimes not paid for. ;)

> I also don't agree that there are "more appropriate replacements
> available".
> The=C2=A0 suggested `hash()` replacements for the md5/sha1* functions ha=
ve
> the exact same functionality, which the RFC considers "incorrect use",
> so what are we actually solving by this deprecation ? Devs not having
> enough to do already ?
> The problem (for open source) with "force-replacing" the uses of
> `md5/sha1*` functions with the `hash` function calls, is that the hash
> extension was not part of PHP core until PHP 7.4, which means that for a
> significant number of open source projects, the replacement is not a
> one-on-one function call replacement, but needs guard code for PHP < 7.4
> in case the hash extension is not available.

Well, I don't think it's hard to deal with deprecations for which
alternatives are easily available.  Just replace all e.g. md5() calls
with something namespaced, and define that function depending on the PHP
version.

With regard to md5() and sha1() my first though was that we easily could
keep them as aliases.  However, the RFC explains that it might be a good
idea to *reconsider* the use cases, and that is a good idea, in my opinion=
.

I do not, however, agree with the reasoning that a function (like
uniqid()) is often used in a unsafe way (i.e. for purposes it has not
been designed), and therefore should be deprecated/removed.  There are
likely a couple of developers who are easily rolling their own
implementation which can be way worse.  I've seen "encryption" code
which was basically a Caesar cipher, spiced with some obsure function
calls to make it "even more safe".  And I've seen obscure HTML escaping
code with an not so obvious back-door, that was once available as user
note on php.net.

That doesn't mean that I'm against the uniqid() deprecation, especially
if the deprecation message is clear on what to use instead.

Cheers,
Christoph