Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124634
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: [PHP-DEV] =?utf-8?B?UmU6IFtQSFAtREVWXSBbUkZDXSBbVk9URV0gRGVwcmVjYXRpb25z?= =?utf-8?B?IGZvciBQSFAgOC40IOKAlMKgVXNlIGEgY2Fycm90LCBub3QgYSBzdGljay4=?=
In-Reply-To: <G9IiDe18a2ZhrXPA-zljNZsawKCZxlTn2ACfJpM32scdRkRflZ2rM6Ra8z88ZYDczomex4pffxZMpVhEjdB74YQXXNyqJkd7rQdDGA14HC0=@gpb.moe>
Date: Fri, 26 Jul 2024 21:11:49 -0400
Cc: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BC1EB9AF-4B96-43E2-A018-A80DDE3DE2E6@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>
To: "Gina P. Banyard" <internals@gpb.moe>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 26, 2024, at 6:03 AM, Gina P. Banyard <internals@gpb.moe> =
wrote:
>=20
> Stephen Rees-Carter, a security expert that has performed countless =
security audits on Wordpress and Laravel websites, would like to =
disagree with the fact that it is not enough of a good reason. [1]

People who work in emergency rooms think that motorcycles are the =
ultimate evil and should be banned, because emergency room workers are =
the ones who see all of the carnage of the small percent who wreck their =
motorcycles, and they see none of motorcycling's upsides.

Similarly, security experts see everything through the lens of security =
issues, because they see the problems FAR more often than everyone else. =
And as security expertise, they don't see code through other lenses =
where security is not an issue.

Not saying the input of a security experts is not useful, but one man's =
input is only one side of the story, just like emergency room workers =
vs. motorcycles.

> Yet again the PHP community doesn't care about security of its users, =
current and future, and just prefers the convenience of needing to type =
less characters and not go back fix some code for better design.

Explicitly stated, that is a straw man argument, which Rowan already =
called out.

Different people weight risks, costs, and benefits differently, and just =
because you might feel your approach for addressing security concerns =
should eclipse anyone else's approach and all other concerns does not =
mean your approach exists at the peak of the moral high ground.

Every time PHP deprecates software it places the burden and the cost of =
remediation on anyone and everyone who continues to use the software =
that requires the deprecated items. Those who are zealously =
security-first generally dismiss those burdens and cost of remediation =
=E2=80=94 because they do not have to be burdened by then nor pay the =
costs =E2=80=94 and so they shift them to everyone, including those who =
are using functions properly.

Those more pragmatic balance that burden and cost with the potential =
burden and costs that deprecating can impose. And in the case of md5() =
where public code on GitHub shows almost 1 million uses, that imposed =
burden and cost is pretty large.

But ignoring the burden and cost, is it strongly arguable that =
deprecating md5() wouldn't even fix the security problems in most cases =
as those you most want to force to fix things will the ones more likely =
to just create a polyfill and move on. As many has already stated on =
this thread.

Kudos to Tim D=C3=BCsterhus for identifying =
https://www.phptutorial.net/php-tutorial/php-csrf/ and =
https://www.php-einfach.de/php-tutorial/die-wichtigsten-php-funktionen/ =
but his takeaway for an action item was less inspiring.  He argued those =
articles support deprecations when it seems to me the more obvious =
takeaway after finding those articles would be to reach out to those =
websites =E2=80=94 as well as others publishing insecure information =E2=80=
=94 and provide them with updated content to replace the content they =
are currently publishing with content that is promotes secure practices. =
Getting those websites updated is likely to have far more positive =
impact for new PHP developers learning to do things "the right way" then =
forcing them to update their code where they'll likely just use =
hash("md5").

Further, rather than shift the burden of remediation to everyone else, =
why not write a crawler that can automatically and proactively submit =
PRs to all the code out there using md5(), etc. so that most people only =
need to accept the PR to update their code, and make is available as a =
CLI for internal use? I know it is not that simple to remediate, but who =
do you expect will know how to do that better than those on PHP =
internals. Certainly not most GitHub repo owners. Besides, the PR could =
say "Review your code we are proposing the change, and if you are =
confident that your uses are secure then do not apply this PR. But if =
you are not sure they are secure then just apply the PR, test it, and =
then you'll certainly be safer."

Rather than just take a low-effort, feel-good action for security =
theater, if the PHP community REALLY cares about security for its users =
it would take a pro-active, higher-effort approach to addressing the =
concern. The WordPress community implemented at least one successful =
technology-supported "marketing" campaign to move its user base in the =
past, one of which was the "Serve Happy" campaign to get people to =
update their version of PHP (how ironic!):=20

https://make.wordpress.org/core/features/servehappy/

Why not create a working group to promote a "SERVE SECURELY" campaign =
modeled after WordPress's "Serve Happy" campaign, and do your best to =
help people remediate their security issues? Hell, imagine the free =
press and industry-wide exposure that such as campaign would provide as =
a way to educate PHP programmers on the dangers of misusing md5() and =
other insecure approaches?

It is also strongly possible you could even get significant sponsorship =
for such as campaign to pay for some more developer time to address the =
problem. It almost certainly could be seen as a feel-good thing for big =
industry players to support.

Frankly, if the pro-deprecation voters in the PHP community are not =
willing to pursue an initiative that proactively seeks to help users =
remediate and educate users about security concerns then I would argue =
*they* do not really care about security of PHP users but instead are =
only willing to paying lip service to it. #fwiw

TLDR;?  Use a carrot, not a stick.

-Mike