Re: [PHP-DEV] [RFC] is_literal

2021-06-13 Thread Mike Schinkel
> On Jun 13, 2021, at 12:51 PM, Craig Francis wrote: > > On Sun, 13 Jun 2021 at 07:46, Mike Schinkel wrote: > > 1. [...] Minimally I'd ask for a separate vote on is_literal() vs. > is_from_literal(). > > It would definitely be possible to have a vote on the name. Cool. > 2. Regarding the s

Re: [PHP-DEV] [RFC] is_literal

2021-06-13 Thread Craig Francis
On Sun, 13 Jun 2021 at 22:30, Matthew Brown wrote: > I was skeptical about the first draft of this RFC when I saw it last month > [...] Sorry for any unnecessary grief I caused. > Hi Matthew, actually I'd like to thank you for that early feedback, the first draft did need work doing to it, and

Re: [PHP-DEV] [RFC] is_literal

2021-06-13 Thread Matthew Brown
On Sat, 12 Jun 2021 at 13:00, Craig Francis wrote: > Hi Internals, > > I'd like to start the discussion on the is_literal() RFC: > > https://wiki.php.net/rfc/is_literal > > is_literal() brings a proven way to identify Injection Vulnerabilities to > PHP, already used by Google in their Java and Go

Re: [PHP-DEV] [RFC] is_literal

2021-06-13 Thread Craig Francis
On Sun, 13 Jun 2021 at 20:33, someniatko wrote: [...] Have you considered [a] new `literal-string` type, which would be enforced by PHP all the time? Thanks someniatko, a "clearer intent" is a really nice way of putting it. It is something that Joe is considering, but for a future version, simpl

Re: [PHP-DEV] [RFC] is_literal

2021-06-13 Thread someniatko
Hi! >From what I understood reading the RFC, this looks like a new type, "literal string", specifically a subtype of "string". Have you considered instead of forcing library authors to use `is_literal()` check everywhere on their input boundary and making sure no place where input is passed, is fo

Re: [PHP-DEV] [RFC] make Reflection*#setAccessible() no-op

2021-06-13 Thread tyson andre
Hi Marco Pivetta, > I'm posting here to introduce a new simplification, as well as > quality-of-life-improving RFC: > > https://wiki.php.net/rfc/make-reflection-setaccessible-no-op > > The RFC is quite minimal, and proposes removing any runtime behavior from > `ReflectionMethod#setAccessible()`

Re: [PHP-DEV] [RFC] make Reflection*#setAccessible() no-op

2021-06-13 Thread Marco Pivetta
Hey Larry, On Sun, Jun 13, 2021, 20:46 Larry Garfield wrote: > I'm generally OK with it. The change makes sense. > > What I'm unclear on is why it's not including the actual deprecation. Not > doing that yet and having it just become a noop first seems fine, but it's > also clear that having i

Re: [PHP-DEV] [RFC] make Reflection*#setAccessible() no-op

2021-06-13 Thread Larry Garfield
On Sun, Jun 13, 2021, at 11:44 AM, Marco Pivetta wrote: > Hey folks, > > I'm posting here to introduce a new simplification, as well as > quality-of-life-improving RFC: > > https://wiki.php.net/rfc/make-reflection-setaccessible-no-op > > The RFC is quite minimal, and proposes removing any runtim

Re: [PHP-DEV] [RFC] is_literal

2021-06-13 Thread Craig Francis
On Sun, 13 Jun 2021 at 07:46, Mike Schinkel wrote: > Nice! There is an awful lot to like here. > Thank you. > 1. [...] Minimally I'd ask for a separate vote on is_literal() vs. > is_from_literal(). > It would definitely be possible to have a vote on the name. I only went with is_literal()

[PHP-DEV] [RFC] make Reflection*#setAccessible() no-op

2021-06-13 Thread Marco Pivetta
Hey folks, I'm posting here to introduce a new simplification, as well as quality-of-life-improving RFC: https://wiki.php.net/rfc/make-reflection-setaccessible-no-op The RFC is quite minimal, and proposes removing any runtime behavior from `ReflectionMethod#setAccessible()` and `ReflectionProper