[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] Explicit callee defaults

> On Jul 26, 2024, at 6:42 PM, Christoph M. Becker wrote: > > I have only skimmed your suggestion, but it sounds quite similar to > . I would really love to hear from some of those who voted "no" ~9 years why they did so, and if they still feel the same. >

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] Explicit callee defaults

On 26.07.2024 at 23:54, Bilge wrote: > New RFC idea just dropped. When writing a function, we can specify > defaults for its parameters, and when calling a function we can leverage > those defaults /implicitly/ by not specifying those arguments or by > "jumping over" some of them using named param

[PHP-DEV] Explicit callee defaults

Hi Internals, New RFC idea just dropped. When writing a function, we can specify defaults for its parameters, and when calling a function we can leverage those defaults /implicitly/ by not specifying those arguments or by "jumping over" some of them using named parameters. However, we cannot

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On 26/07/2024 19:39, Andreas Heigl wrote: On 26 July 2024 18:25:53 UTC, Larry Garfield wrote: The vote will end on 9 February, probably afternoonish in my timezone. That's a pretty long voting period... It seems he meant the 9th of August.

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] [Vote] Asymmetric visibility v2

On Fri, Jul 26, 2024, at 6:54 PM, Bilge wrote: >> Presumably the proposed PHP version is wrong? No, this is still within the window to target 8.4. --Larry Garfield

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On Fri, Jul 26, 2024, at 6:25 PM, Larry Garfield wrote: > Voting for Asymmetric Visibility is now open. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > The vote will end on 9 February, probably afternoonish in my timezone. > > -- > Larry Garfield > la...@garfieldtech.com Sigh. And

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

> > Presumably the proposed PHP version is wrong?

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On 26 July 2024 18:25:53 UTC, Larry Garfield wrote: > Voting for Asymmetric Visibility is now open. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > The vote will end on 9 February, probably afternoonish in my timezone. > That's a pretty long voting period... -- Andreas Heigl

[PHP-DEV] [Vote] Asymmetric visibility v2

Voting for Asymmetric Visibility is now open. https://wiki.php.net/rfc/asymmetric-visibility-v2 The vote will end on 9 February, probably afternoonish in my timezone. -- Larry Garfield la...@garfieldtech.com

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] Asymmetric Visibility, v2

On Fri, Jul 26, 2024, at 16:27, Larry Garfield wrote: > On Fri, Jul 26, 2024, at 12:58 PM, Rob Landers wrote: > > >> And now that I see it spelled out more, I do agree that while it appears a > >> bit more verbose, and this "(set)" looks odd at first, having all the > >> visibility upfront is a

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] Asymmetric Visibility, v2

On Fri, Jul 26, 2024, at 12:58 PM, Rob Landers wrote: >> And now that I see it spelled out more, I do agree that while it appears a >> bit more verbose, and this "(set)" looks odd at first, having all the >> visibility upfront is a lot clearer than having to read through the hooks to >> see wha

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] Asymmetric Visibility, v2

On Fri, Jul 26, 2024, at 13:36, Jordi Boggiano wrote: > On 21.07.2024 11:21, Rob Landers wrote: >> >> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: >>> On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: >>> > Will the alternative syntax on hook not even be put to a vote? >>> >>> It

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] Asymmetric Visibility, v2

On 21.07.2024 11:21, Rob Landers wrote: On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote: On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote: > Will the alternative syntax on hook not even be put to a vote? It was, a year and a half ago when Aviz was first proposed.  The preference wa

[PHP-DEV] [RFC][VOTE] Lazy Objects

Dear internals, We have just opened the vote for the Lazy Objects RFC: https://wiki.php.net/rfc/lazy-objects The vote will close on August 11th à 00:00. Please check the discussion thread if you didn't follow it already: https://externals.io/message/123503 Cheers, Nicolas and Arnaud

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