Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124664
Precedence: bulk
MIME-Version: 1.0
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>
 <c03eb187-bd21-4a4b-9faf-8d0243eaa994@varteg.nz> <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
 <3563cf9b-8eab-4c82-b525-a5d2f9a767bb@varteg.nz> <38920A4B-790D-48C7-B2F6-C49D3F506232@rwec.co.uk>
 <0824789d-0e36-4628-85c1-4b8d9b7f86af@varteg.nz> <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
In-Reply-To: <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
Date: Sun, 28 Jul 2024 14:24:34 +0200
Message-ID: <CAGBsUrfqn9spaJfv+NWkCub0N-NgoK8uHRZew+beRO5pmRKqFg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000752b94061e4dd40e"
From: tekiela246@gmail.com (Kamil Tekiela)

--000000000000752b94061e4dd40e
Content-Type: text/plain; charset="UTF-8"

On Sun, Jul 28, 2024, 08:42 Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>
wrote:

>
>
> On 27 July 2024 23:14:32 BST, Morgan <weedpacket@varteg.nz> wrote:
>
> >Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions
> for both, and then when SHA4 comes along (as it inevitably will) another
> standalone function for one of its variants?
>
> You tell me. As I have repeatedly said, I don't actually know anything
> about these algorithms. SHA-256 is the only one on the list which I've
> heard of, and I'm aware it's newer than SHA-1. I don't know why SHA-512
> isn't "better", I don't know why nobody talks about SHA-3, and I don't know
> if one of the others in the list is absolutely amazing and should be
> everyone's default forever.
>
> As far as I can see, nobody, in this whole discussion, has actually
> stepped up and explained what users should be using, once we have taught
> them that MD5 and SHA-1 are bad.
>
>
> >Or leave them them the 60-piece set (which includes flat-head and
> Phillips screwdrivers, so they're not being taken away), and write some
> tips on how to use it correctly.
>
> So go ahead and write those tips. You don't need an RFC vote to improve
> the documentation.
>
>
> Here is my offer to those arguing in favour of this deprecation: If you
> show me a draft of a comprehensive improvement to the manual to explain how
> users should be choosing a hashing algorithm, I will consider changing my
> vote.
>
> I am also happy to help with proofreading, and working out how to format
> it into DocBook that fits nicely in the manual.
>
> As long as the deprecation rests on "somebody in the next 10 years might
> get round to improving the manual", my vote remains a firm No.
>
>
> Regards,
> Rowan Tommins
> [IMSoP]
>

I have voted yes only because I thought it's about removing inconsistent
function alias. I can't see anything wrong with this hashing algorithms and
I don't consider them unsafe. However, as someone pointed out this doesn't
seem to be correct as the crc32 function isn't part of the depreciation
proposal. I am confused now as to why we are trying to deprecate these
functions at all. If it's about people confusing the hashing algorithms
with password key stretching algorithms then that's not a valid reason. A
red warning in the documentation should aid people in clearing this
confusion.

>

--000000000000752b94061e4dd40e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sun, Jul 28, 2024, 08:42 Rowan Tommins [IMSoP] &lt;=
<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 27 July 2024 23:14:32 BST, Morgan &lt;<a href=3D"mailto:weedpacket@varte=
g.nz" target=3D"_blank" rel=3D"noreferrer">weedpacket@varteg.nz</a>&gt; wro=
te:<br>
<br>
&gt;Why a SHA2 algorithm? Why not a SHA3 one? How about standalone function=
s for both, and then when SHA4 comes along (as it inevitably will) another =
standalone function for one of its variants?<br>
<br>
You tell me. As I have repeatedly said, I don&#39;t actually know anything =
about these algorithms. SHA-256 is the only one on the list which I&#39;ve =
heard of, and I&#39;m aware it&#39;s newer than SHA-1. I don&#39;t know why=
 SHA-512 isn&#39;t &quot;better&quot;, I don&#39;t know why nobody talks ab=
out SHA-3, and I don&#39;t know if one of the others in the list is absolut=
ely amazing and should be everyone&#39;s default forever. <br>
<br>
As far as I can see, nobody, in this whole discussion, has actually stepped=
 up and explained what users should be using, once we have taught them that=
 MD5 and SHA-1 are bad.<br>
<br>
<br>
&gt;Or leave them them the 60-piece set (which includes flat-head and Phill=
ips screwdrivers, so they&#39;re not being taken away), and write some tips=
 on how to use it correctly.<br>
<br>
So go ahead and write those tips. You don&#39;t need an RFC vote to improve=
 the documentation. <br>
<br>
<br>
Here is my offer to those arguing in favour of this deprecation: If you sho=
w me a draft of a comprehensive improvement to the manual to explain how us=
ers should be choosing a hashing algorithm, I will consider changing my vot=
e.<br>
<br>
I am also happy to help with proofreading, and working out how to format it=
 into DocBook that fits nicely in the manual. <br>
<br>
As long as the deprecation rests on &quot;somebody in the next 10 years mig=
ht get round to improving the manual&quot;, my vote remains a firm No.<br>
<br>
<br>
Regards,<br>
Rowan Tommins<br>
[IMSoP]<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I have voted yes only because I thought it&#39;s about removing inco=
nsistent function alias. I can&#39;t see anything wrong with this hashing a=
lgorithms and I don&#39;t consider them unsafe. However, as someone pointed=
 out this doesn&#39;t seem to be correct as the crc32 function isn&#39;t pa=
rt of the depreciation proposal. I am confused now as to why we are trying =
to deprecate these functions at all. If it&#39;s about people confusing the=
 hashing algorithms with password key stretching algorithms then that&#39;s=
 not a valid reason. A red warning in the documentation should aid people i=
n clearing this confusion.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000752b94061e4dd40e--