Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124588
Message-ID: <95147d9d-d6e8-4396-bf0b-409c33679f90@bastelstu.be>
Date: Thu, 25 Jul 2024 17:33:16 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: Peter Stalman <sarkedev@gmail.com>, Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.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>
Content-Language: en-US
In-Reply-To: <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/24/24 05:58, Peter Stalman wrote:
> is already quite specific. We're talking about end users who are rolling
> their own security implementations and are unaware of the security risks
> but somehow know how to use these functions without reading the
> documentation and warnings.

No, we are talking about end users who are following tutorials that were 
written when PHP 4 was the most recent PHP version.

We are also talking about end users who look at existing code bases for 
"inspiration", see md5() used, notice that the output looks random and 
use it, believing they know what they are doing, but in that process use 
it in a way that is insecure.

As an example, using md5_file() to implement a cache buster is fine, but 
a less-experienced developer may believe that md5_file() uniquely 
identifies the file contents and use it in a way where strong 
collision-resistance against an adversary is required.

> On the other hand, who will be impacted by these deprecations? Potentially
> everyone, as these are included in many projects and in many vendor
> packages.  It's busy work for the people who aren't affected.  Sure,
> eventually, it will all be sorted out as CI warnings slowly subside because
> of this.

I'm positive that even existing projects written by experienced 
developers would benefit from re-checking if their use of MD5 and SHA-1 
is actually safe instead of assuming that this is the case, when the 
specific functionality has been untouched for the last 10 years.

Looking back at my own code, I'm seeing places where using SHA-1 is not 
strictly insecure, but where a stronger hash function nevertheless would 
have been more appropriate, if only to simplify code audits. I just used 
sha1(), because it was temptingly convenient compared to hash('sha256', …).

Best regards
Tim Düsterhus