Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Friday, 19 July 2024 at 19:39, Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. 2 days late but I have now closed the vote for all the R

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-08-02 18:34, Mike Schinkel wrote: On Jul 31, 2024, at 5:15 PM, Morgan wrote: Also, providing a dedicated function for an algorithm over and above others that don't get such special treatment inflates use of that algorithm, making it more commonly used. It becomes self-reinforcing.

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 31, 2024, at 5:15 PM, Morgan wrote: > A problem is that MD5 should _not_ be one of the most commonly used > algorithms. Tell that to: - RFC 2846 - Internet Message Format (IMF) Extensions for Internet Mail - RFC 3229 - Delta-Encoding in HTTP - RFC 4151 - The Internet IP Traffic Archi

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 31.07.2024 at 23:13, Rowan Tommins [IMSoP] wrote: > On 30/07/2024 20:15, Tim Düsterhus wrote: > >> Part of the motivation of the deprecation (and my argument against the >> addition of a standalone sha256() function) is simplifying the >> documentation: Everything needs to be written down in mu

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 30/07/2024 21:57, Tim Düsterhus wrote: Let me attempt to give an explanation. As of today users should use in order of priority: 1. The hash function they need for interoperability: If a service provides a SHA-1 checksum, then there is no choice and SHA-1 needs to be used. 2. The hash fun

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-31 13:07, Mike Schinkel wrote: On Jul 30, 2024, at 4:26 PM, Tim Düsterhus wrote: The problem with adding standalone functions for every algorithm is that it would result in a combinatorial explosion of available functions. I commented on this but as it was probably missed in a longe

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 30/07/2024 20:15, Tim Düsterhus wrote: Part of the motivation of the deprecation (and my argument against the addition of a standalone sha256() function) is simplifying the documentation: Everything needs to be written down in multiple different places, any changes to hash_file() will likely

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 30, 2024, at 4:26 PM, Tim Düsterhus wrote: > The problem with adding standalone functions for every algorithm is that it > would result in a combinatorial explosion of available functions. I commented on this but as it was probably missed in a longer reply so I will repeat. There is n

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 30.07.2024 at 21:20, Tim Düsterhus wrote: > What prevented me personally from adding a "soft deprecation" to the > documentation is, that the function is not actually deprecated and not > slated for deprecation. It is not up to me to decide to soft deprecate > something. Well, yeah, that needs

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/28/24 08:42, Rowan Tommins [IMSoP] 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 act

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/28/24 00:25, Rob Landers wrote: I'd love to see a "hashing" namespace and all of these given their own functions with docblocks and manual pages instead of the current generic "god of hash" page which doesn't even list the hash functions available; you have to click on hash_algos and t

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/28/24 14:24, Kamil Tekiela wrote: 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 crc3

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/28/24 06:33, Mike Schinkel wrote: P.S. Frankly, I really would not want to see md5() nor sha1() removed because there are valid use-cases for them. I would at least like to see them kept in some form, maybe in an `\Insecure` namespace, or renamed `insecure_md5()` and `insecure_sha1()`

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/27/24 13:24, Christoph M. Becker wrote: Hmm, such soft deprecations should be a good thing, but I'm afraid they are not really reaching much of the user base. Remember ext/mysql? That was soft deprecated for "centuries", but still support channels were burning when it actually had been

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/26/24 19:33, Rowan Tommins [IMSoP] wrote: On Fri, 26 Jul 2024, at 15:20, Larry Garfield wrote: One thing to remind people about, the deprecations for md5(), sha1(), and uniqid() explicitly say they cannot be outright removed before PHP 10. That's at least 6 years away. That gives a lo

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/27/24 02:18, Juliette Reinders Folmer wrote: Considering that the hash() function was introduced in PHP 5.1.2 (January 2006) and password_*() in PHP 5.5 (June 2013), I don't share your optimism about tutorials being updated within six years I attribute that to the fact that there

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/26/24 15:13, Rowan Tommins [IMSoP] wrote: On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote: I think you are expecting a little too much from a beginner that is following "the modern PHP tutorial" if you expect them to critically question whether the tutorial is actually good or not. T

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 29 July 2024 21:00:37 BST, Morgan wrote: >That still doesn't protect md5() and sha1() from deprecation; if there is a >PHP-mandated default hash algorithm that gets its own name, then users should >be encouraged to use that one, which means not leaving the others lying around >to for it

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-29 18:47, Rowan Tommins [IMSoP] wrote: On 29 July 2024 02:19:23 BST, Morgan wrote: At that point you've got \PHP\sha3() instead of hash("sha3-?"), and now you've (a) lost the word "hash" indicator of what's going on, and (b) hidden the choice of "?" from the user. I'm not really

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 29 July 2024 02:19:23 BST, Morgan wrote: >At that point you've got \PHP\sha3() instead of hash("sha3-?"), and now you've >(a) lost the word "hash" indicator of what's going on, and (b) hidden the >choice of "?" from the user. I'm not really seeing an improvement. Once again, you're assumi

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 28, 2024, at 9:19 PM, Morgan wrote: > I, too, wish there was more willingness to add useful functions to core. :-) >>> On Jul 27, 2024, at 6:14 PM, Morgan wrote: >>> Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions >>> for both, and then when SHA4 comes alon

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-28 15:54, Mike Schinkel wrote: Many (all?) of the functions the Go team adds could have been written in "userland" but they represent such common use-cases that the Go team decided to make them easy and obvious. They even soft deprecate functions and structs that are not ideal and

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-28 18:42, Rowan Tommins [IMSoP] wrote: On 27 July 2024 23:14:32 BST, Morgan 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

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi, On Mon, Jul 22, 2024 at 11:59 AM Jakub Zelenka wrote: > Hi, > > On Fri, Jul 19, 2024 at 6:42 PM Gina P. Banyard wrote: > >> Hello internals, >> >> I have opened the vote for the mega deprecation RFC: >> https://wiki.php.net/rfc/deprecations_php_true8_4 >>

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Sun, Jul 28, 2024, 08:42 Rowan Tommins [IMSoP] wrote: > > > On 27 July 2024 23:14:32 BST, Morgan 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

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 27 July 2024 23:14:32 BST, Morgan 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 actua

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 27, 2024, at 7:24 AM, Christoph M. Becker wrote: > > Hmm, such soft deprecations should be a good thing, but I'm afraid they > are not really reaching much of the user base. Remember ext/mysql? > That was soft deprecated for "centuries", but still support channels > were burning when it

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 27, 2024, at 8:36 AM, Rowan Tommins [IMSoP] > wrote: > On 27 July 2024 00:58:17 BST, Morgan wrote: >> >> I'm not talking about the MD5 or SHA1 algorithms or whether they should or >> shouldn't be used. I'm just talking about the functions themselves. md5(), >> md5_file(), sha1(), and

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Sun, Jul 28, 2024, at 00:14, Morgan wrote: > On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote: > > > > > > On 27 July 2024 00:58:17 BST, Morgan wrote: > >> > >> I'm not talking about the MD5 or SHA1 algorithms or whether they should or > >> shouldn't be used. I'm just talking about the funct

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote: On 27 July 2024 00:58:17 BST, Morgan wrote: I'm not talking about the MD5 or SHA1 algorithms or whether they should or shouldn't be used. I'm just talking about the functions themselves. md5(), md5_file(), sha1(), and sha1_file(). They only

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 27 July 2024 00:58:17 BST, Morgan wrote: > >I'm not talking about the MD5 or SHA1 algorithms or whether they should or >shouldn't be used. I'm just talking about the functions themselves. md5(), >md5_file(), sha1(), and sha1_file(). They only exist because there wasn't the >generic hash a

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26.07.2024 at 19:33, Rowan Tommins [IMSoP] wrote: > On Fri, 26 Jul 2024, at 15:20, Larry Garfield wrote: > >> One thing to remind people about, the deprecations for md5(), sha1(), >> and uniqid() explicitly say they cannot be outright removed before PHP >> 10. That's at least 6 years away. Th

[PHP-DEV] Re: [PHP-DEV] Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4 — Use a carrot, not a stick.

On Fri, Jul 26, 2024 at 6:14 PM Mike Schinkel wrote: > 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 ab

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 26, 2024, 04:58 Tim Düsterhus wrote: > > I just Googled "PHP tutorial" and found https://www.phptutorial.net/ as > the second search result, which considers itself to be "the modern PHP > tutorial". > > I've clicked at the CSRF section > (https://www.phptutorial.net/php-tutorial/php-c

[PHP-DEV] Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4 — Use a carrot, not a stick.

> On Jul 26, 2024, at 9:11 PM, Mike Schinkel wrote: > > Kudos to Tim Düsterhus 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

[PHP-DEV] Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4 — Use a carrot, not a stick.

> On Jul 26, 2024, at 6:03 AM, Gina P. Banyard wrote: > > 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 roo

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26-7-2024 16:20, Larry Garfield wrote: One thing to remind people about, the deprecations for md5(), sha1(), and uniqid() explicitly say they cannot be outright removed before PHP 10. That's at least 6 years away. That gives a loong time for documentation, tutorials, instructions, an

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-26 09:34, Rowan Tommins [IMSoP] wrote: On 24/07/2024 23:01, Morgan wrote: And they would still be available as hash("md5") and hash("sha1"); the only reason they're called out as their own distinct functions today is historical inertia. I don't agree that the reasons for includin

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> > In regards to hashing, this is likely fine; for now. There still > isn't an arbitrary pre-image attack on md5 (that I'm aware of). Can > you create a random file with a matching hash? Yes, in a few seconds, > on modern hardware. But you cannot yet make it have arbitrary > contents in our life

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, 26 Jul 2024, at 15:20, Larry Garfield wrote: > One thing to remind people about, the deprecations for md5(), sha1(), > and uniqid() explicitly say they cannot be outright removed before PHP > 10. That's at least 6 years away. That gives a loong time for > documentation, tutorials,

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 26, 2024, at 08:44, Rowan Tommins [IMSoP] wrote: > > > On 25 July 2024 23:54:53 BST, Nick Lockheart wrote: > >Doesn't password_hash() handle this automatically? The result of the > >password_hash() function includes the hash and the algorithm used to > >hash it. That way password_v

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, 26 Jul 2024, 15:22 Larry Garfield, wrote: > > That long deprecation period is the reason why I was comfortable voting > yes. This isn't something that would happen tomorrow. It would be in at > least two presidential elections from now. > Real elections or rigged elections? 😁 >

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26.07.2024 at 15:13, Rowan Tommins [IMSoP] wrote: > On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote: > >> CRC32 does not claim to be a cryptographically secure hash algorithm. >> Its use case is completely different. > > As an inexperienced user looking at the PHP manual for hash() and > ha

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 26, 2024, at 11:11 AM, Christoph M. Becker wrote: > On 26.07.2024 at 12:03, Gina P. Banyard wrote: > >> 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 enou

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 26, 2024, at 15:02, Tim Düsterhus wrote: > HI > > On 7/26/24 14:50, Rob Landers wrote: > >>> $_SESSION['token'] = md5(uniqid(mt_rand(), true)); > >> > >> *Exactly* the md5-uniqid construction that is called out as unsafe in > >> the RFC and used in a security context. > > > > In regar

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote: > I think you are expecting a little too much from a beginner that is > following "the modern PHP tutorial" if you expect them to critically > question whether the tutorial is actually good or not. They are likely > already struggling with synt

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

HI On 7/26/24 14:50, Rob Landers wrote: $_SESSION['token'] = md5(uniqid(mt_rand(), true)); *Exactly* the md5-uniqid construction that is called out as unsafe in the RFC and used in a security context. In regards to hashing, this is likely fine; for now. There still isn't an arbitrary pre-im

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 26, 2024, at 13:58, Tim Düsterhus wrote: > Hi > > On 7/26/24 08:35, Peter Stalman wrote: > > How prevalent is this exactly? PHP 4 ended support in 2008. I think > > putting warning labels on these things in the docs is enough, but we can't > > go around locking up every kitchen knife

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26 July 2024 11:03:53 BST, "Gina P. Banyard" wrote: >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. This is a gross misrepresen

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/26/24 08:35, Peter Stalman wrote: How prevalent is this exactly? PHP 4 ended support in 2008. I think putting warning labels on these things in the docs is enough, but we can't go around locking up every kitchen knife just because there are some idiots out there who read a book from the

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26.07.2024 at 12:03, Gina P. Banyard wrote: > 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] > A warning on a documentation page is usel

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Am 26.07.2024, 12:03:53 schrieb Gina P. Banyard : > On Friday, 26 July 2024 at 08:09, Peter Stalman > wrote: > > On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman wrote: > >> If their learning insticast >> > > *instincts. > > I should also clarify, I'm not against deprecations in general. However,

RE: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> 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. > > > Gina P. Banyard If you describe it in such a dramatic fashion, then there is

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Friday, 26 July 2024 at 08:09, Peter Stalman wrote: > On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman wrote: > >> If their learning insticast > > *instincts. > > I should also clarify, I'm not against deprecations in general. However, the > benefits should outweigh the costs. If something is

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman wrote: > If their learning insticast > *instincts. I should also clarify, I'm not against deprecations in general. However, the benefits should outweigh the costs. If something is getting unmaintainable, no longer supported, inherently insecure e

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 25 July 2024 23:54:53 BST, Nick Lockheart wrote: >Doesn't password_hash() handle this automatically? The result of the >password_hash() function includes the hash and the algorithm used to >hash it. That way password_verify() magically works with the string >that came from password_hash().

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Thu, Jul 25, 2024 at 8:33 AM Tim Düsterhus wrote: > 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

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, 2024-07-26 at 00:44 +0200, Juliette Reinders Folmer wrote: > On 26-7-2024 0:00, Nick Lockheart wrote: >   > > > > That's a good point. What if there were crypto functions that > > worked > > like password_hash() in that they had one generic function name, > > but > > magically used the new

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 26-7-2024 0:00, Nick Lockheart wrote: That's a good point. What if there were crypto functions that worked like password_hash() in that they had one generic function name, but magically used the new/better "best practice" algorithms as time went by without the need to update any calling code?

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> > On Jul 25, 2024 at 6:02 PM, mailto:li...@ageofdream.com)> > wrote: >That's a good point. What if there were crypto functions that worked > > > like password_hash() in that they had one generic function name, but > magically used the new/better "best

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> > On Jul 25, 2024 at 5:35 PM, (mailto:imsop@rwec.co.uk)> wrote: >Rather than force people to use functions that we acknowledge are hard > > > to use, surely the logical thing is to make the "right" code *easy* to use? > Which means if we want people to use SHA-

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Thu, 2024-07-25 at 22:34 +0100, Rowan Tommins [IMSoP] wrote: > On 24/07/2024 23:01, Morgan wrote: > > And they would still be available as hash("md5") and hash("sha1"); > > the > > only reason they're called out as their own distinct functions > > today > > is historical inertia. > > > I do

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 24/07/2024 23:01, Morgan wrote: And they would still be available as hash("md5") and hash("sha1"); the only reason they're called out as their own distinct functions today is historical inertia. I don't agree that the reasons for including standalone functions are "historical". The RFC i

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi On 7/25/24 19:28, Nick Lockheart wrote: I'm in the process of refactoring an old framework and I just found a use of sha1(). It's being used to generate a unique resource lock. It doesn't need to be secure, just a fast and random UID. SHA-1 is a deterministic algorithm, thus it is unable to

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Thu, 2024-07-25 at 17:33 +0200, Tim Düsterhus wrote: > > 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 a

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

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 tal

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Wed, Jul 24, 2024 at 3:03 PM Morgan wrote: > And they would still be available as hash("md5") and hash("sha1"); the > only reason they're called out as their own distinct functions today is > historical inertia. > Yes, I am aware of that, it's covered in the RFC and has been discussed. My iss

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 2024-07-24 15:58, Peter Stalman wrote: On Mon, Jul 22, 2024 at 9:06 AM Derick Rethans > wrote: - Deprecate md5(), sha1(), md5_file(), and sha1_file() (just says "large   impact") About 1.2 million. https://github.com/search?q=%28md5+OR+md5_file+OR+sha1+OR

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

> On Jul 23, 2024, at 12:26 PM, Larry Garfield wrote: > > Hypothetical pattern matching example: > > $foo is ['a' => int, 'b' => $b, 'c' => mixed]; > > That would assert that there's 3 keys. "a" may be any integer (but only an > integer), "b" can be anything and will be captured to a variable

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Mon, Jul 22, 2024 at 9:06 AM Derick Rethans wrote: > - Deprecate md5(), sha1(), md5_file(), and sha1_file() (just says "large > impact") About 1.2 million. https://github.com/search?q=%28md5+OR+md5_file+OR+sha1+OR+sha1_file%29+language%3APHP+&type=code The proposed deprecation of these fu

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Tue, Jul 23, 2024, at 4:00 PM, Matthew Weier O'Phinney wrote: >> However, a few people indicated a desire to have an explicit wildcard _ >> anyway, even if it's redundant, as it's a more common and standard approach >> in other languages. We've indicated that we are open to making that an >

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Tue, Jul 23, 2024 at 9:06 AM Larry Garfield wrote: > On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote: > > On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard > wrote: > >> Hello internals, > >> > >> I have opened the vote for the mega deprecation RFC: > >> https://wiki.php.net/rf

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Tue, Jul 23, 2024, at 2:41 PM, Christoph M. Becker wrote: > On 23.07.2024 at 16:04, Larry Garfield wrote: > >> On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote: >> >>> On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard wrote: >>> I have opened the vote for the mega deprecation

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On 23.07.2024 at 16:04, Larry Garfield wrote: > On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote: > >> On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard wrote: >> >>> I have opened the vote for the mega deprecation RFC: >>> https://wiki.php.net/rfc/deprecations_php_8_4 >> >> The sec

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi Jakub! On 22.07.2024 at 12:59, Jakub Zelenka wrote: > On Fri, Jul 19, 2024 at 6:42 PM Gina P. Banyard wrote: > >> I have opened the vote for the mega deprecation RFC: >> https://wiki.php.net/rfc/deprecations_php_8_4 > > Just wanted to send some reasoning of my no votes. > > The CSV one is als

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote: > On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard wrote: >> Hello internals, >> >> I have opened the vote for the mega deprecation RFC: >> https://wiki.php.net/rfc/deprecations_php_8_4 >> >> Reminder, each vote must be submitted i

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. > > > Best regards, > > > Gina P. Banyard > The section "De

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Fri, 19 Jul 2024, Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. I have voted no for a few, as they had no impact assesment at all: - D

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

On Mon, Jul 22, 2024 at 11:59 AM Jakub Zelenka wrote: > I think we should also keep file_put_contents array argument as it might > actually be used with iovec in the future which could be a significant > optimization - need to check details if that would work but if it does, it > could be a prett

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hi, On Fri, Jul 19, 2024 at 6:42 PM Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. > > > Just wanted to send some reasoning of my no votes.

[PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Hello internals, I have opened the vote for the mega deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_4 Reminder, each vote must be submitted individually. Best regards, Gina P. Banyard