Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123821
Date: Tue, 25 Jun 2024 16:49:36 +0100 (BST)
To: Marco Pivetta <ocramius@gmail.com>
cc: "Gina P. Banyard" <internals@gpb.moe>, 
    PHP internals <internals@lists.php.net>, timwolla@php.net
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
In-Reply-To: <CADyq6sLuz3430TRMu8cSh5_x57UBaWA8v4sr_c+OgUSjn-otBQ@mail.gmail.com>
Message-ID: <a503f9ff-739f-a1c4-f85f-1896acffa1c0@php.net>
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe> <CADyq6sLuz3430TRMu8cSh5_x57UBaWA8v4sr_c+OgUSjn-otBQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

Please, no top posting.

On Tue, 25 Jun 2024, Marco Pivetta wrote:

> I agree with most of these deprecations, except:
> 
>  * `uniqid()`, in my case (XKCD 1172) is largely used for quickly
> generating a semi-random string for test purposes: a suitable replacement
> PRNG implementation would be welcome. Even refactoring with tools like
> Rector will lead to quite messy code, or added dependencies. IMO fine to
> get rid of **this specific implementation**, if a safe function is
> provided, such as `random_ascii_string()` or such (dunno, just a hint)

>  * `md5()`, `sha1()` - OK-ish with moving to `hash('<algo>', ...)`, but
> while these are insecure for most use-cases, they are part of the domain of
> many tools, including GIT itself. I can Rector my way out of it, just not
> sure these should be hidden into `hash(...)`

I agree on both points.

These functions are indeed often used. The documentation for uniqid has 
some nice big warnings too. It can be used in situations, where it is 
OK.

Replacing the algorithm underneath uniqid can (and perhaps should) be 
looked at.

For the md5 and sha1 functions. Although these algorithms are not useful 
for "verifying the authenticity of a a payload", that doesn't mean they 
can't be used outside of that use case. 

I understand the reasons why you want to "nudge" people to no longer use 
these "unsafe" functions, but IMO, in this case, it's not worth the 
BC issues.

cheers,
Derick