Re: [PHP-DEV] [RFC] is_literal

On 2021-06-15 10:19, Joe Watkins wrote: It's just that existing implementation details - RETURN_CHAR using interned strings, and literal constant strings being interned by the compiler - lead to a literal string being "re-used". This is just a natural consequence of literal strings retaining

Re: [PHP-DEV] [RFC] is_literal

Le 22/06/2021 à 11:28, Dan Ackroyd a écrit : On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: Should(n't?) PHP add a basic SQL builder class that can be extended for special cases, e.g. different flavors of SQL? No. Or at least not yet. This type of thing is much better done in userland,

Re: [PHP-DEV] [RFC] is_literal

On 2021-06-22 12:15, Dan Ackroyd wrote: Dan Ackroyd wrote: If people aren't going to make using a non-literal where a literal is expected, be an error, the only alternative I can see is logging it. Please correct me if you think people should be doing something other than those two things.

Re: [PHP-DEV] [RFC] is_literal

> On Jun 22, 2021, at 5:28 AM, Dan Ackroyd wrote: > > On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: >> >> Should(n't?) PHP add a basic SQL builder class that can be extended for >> special cases, e.g. different flavors of SQL? >> > > No. Or at least not yet. > > This type of thing is

Re: [PHP-DEV] [RFC] is_literal

On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: > > Should(n't?) PHP add a basic SQL builder class that can be extended for > special cases, e.g. different flavors of SQL? > No. Or at least not yet. This type of thing is much better done in userland, where the api can evolve at a fast rate,

Re: [PHP-DEV] [RFC] is_literal

> On Jun 22, 2021, at 4:53 AM, Dan Ackroyd wrote: > > The whole point of the idea of literal strings is to make it be easier > to write some code that: > > i) is safe. > ii) can be reasoned about at scale. > > Passing bare strings around is not so great for either of those > things. You have

Re: [PHP-DEV] [RFC] is_literal

Dan Ackroyd wrote: >> The developer who made that change would run the tests, >> see the tests pass and then push their code live. At which point, it >> would cause an error in production, as the string returned would not >> pass the is_literal check. Craig Francis wrote: > No, the only way

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 14:27, Thomas Nunninger wrote: > Thomas Nunninger wrote: Thomas Nunninger wrote: > Only some (infrastructure or > end-to-end) test that covers the business logic plus the corresponding > infrastructure by accident would uncover an error. I think testing will be much

Re: [PHP-DEV] [RFC] is_literal

On Fri, 18 Jun 2021 at 1:30 pm, Mike Schinkel wrote: > For the avoidance of doubt can you confirm that this $sql would indeed be > trusted? > > $ids = array_map( 'intval', $_GET['ids'] ?? [] ); > > $where = implode( ',', $ids ); > $sql = 'SELECT * FROM foo WHERE id IN (' . $where . ')'; > > >

Re: [PHP-DEV] [RFC] is_literal

Refcounted* not recounted ... Predictive text on phone ... Cheers Joe On Friday, 18 June 2021, Joe Watkins wrote: > Just to explain this tracking of longs. > > We can track strings because there's space to do that in GC info which > recounted types all have. > > Where things aren't recounted

Re: [PHP-DEV] [RFC] is_literal

Just to explain this tracking of longs. We can track strings because there's space to do that in GC info which recounted types all have. Where things aren't recounted there is no usable space on the value to store the literal flag without disabling some internal assumptions about type flags. We

Re: [PHP-DEV] [RFC] is_literal

> On Jun 18, 2021, at 8:30 AM, Mike Schinkel wrote: > > >> On Jun 18, 2021, at 7:22 AM, Craig Francis > > wrote: >> >> On Fri, 18 Jun 2021 at 11:45 am, Guilliam Xavier > > >> wrote: >> >>> IIUC, with the addition of

Re: [PHP-DEV] [RFC] is_literal

> On Jun 18, 2021, at 7:22 AM, Craig Francis wrote: > > On Fri, 18 Jun 2021 at 11:45 am, Guilliam Xavier > wrote: > >> IIUC, with the addition of integers, the function will return true for e.g. >> `'SELECT * FROM foo LIMIT ' . (int)$limit` even if $limit doesn't come from >> a "static" value

Re: [PHP-DEV] [RFC] is_literal

> On Jun 16, 2021, at 1:24 PM, Craig Francis wrote: > > On Sat, 12 Jun 2021 at 18:00, Craig Francis > wrote: > >> I'd like to start the discussion on the is_literal() RFC: >> https://wiki.php.net/rfc/is_literal >> > > Hi Internals, > > Following up on the is_literal() RFC, thanks for the

Re: [PHP-DEV] [RFC] is_literal

On 15/06/2021 08:19, Joe Watkins wrote: https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe. It's possible to create more

Re: [PHP-DEV] [RFC] is_literal

Hi, It's not unpredictable. krakjoe@Fiji:/opt/src/php-src$ cat nothing.php krakjoe@Fiji:/opt/src/php-src$ var=not-literal sapi/cli/php nothing.php string(11) "not-literal" bool(false) The engine doesn't intern "randomly", and doesn't intern input. Cheers Joe On Tue, 15 Jun 2021 at 10:56,

Re: [PHP-DEV] [RFC] is_literal

> Le 15 juin 2021 à 09:19, Joe Watkins a écrit : > > Morning, > > https://3v4l.org/nJhc1/rfc#focus=rfc.literals > > > It's not so much a bug as a side effect or quirk. > > Note that, the result is correct, in the sense that you do have a

Re: [PHP-DEV] [RFC] is_literal

Morning, https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe. It's just that existing implementation details - RETURN_CHAR

Re: [PHP-DEV] [RFC] is_literal

> Le 12 juin 2021 à 19:00, Craig Francis a écrit : > Hi Internals, > > I'd like to start the discussion on the is_literal() RFC: > > https://wiki.php.net/rfc/is_literal Hi, I’ve found an interesting bug in the implementation: https://3v4l.org/JfSHX/rfc#rfc.literals —Claude

Re: [PHP-DEV] [RFC] is_literal

I've just added support for a `literal-string` type to Psalm: https://psalm.dev/r/9440908f39 This will remain whether or not the RFC passes, but if it passes the is_literal check will be used to inform Psalm in a similar fashion to how array_is_list (coming in 8.1) will inform Psalm's list array

Re: [PHP-DEV] [RFC] is_literal

Hi Craig, > On Jun 14, 2021, at 5:36 AM, Craig Francis wrote: > > On Mon, 14 Jun 2021 at 09:07, Pierre wrote: > >> Le 14/06/2021 à 02:41, Mike Schinkel a écrit : >>> A big*NO* on warnings. Full stop. >> >> [...] Any warning raised by the low level functions would be too >> restrictive. > >

Re: [PHP-DEV] [RFC] is_literal

Hi Dan, On 14/06/2021 13:29, Dan Ackroyd wrote: While I think the idea behind this RFC is great, the current implementation is terrible, as it will cause some fatal errors in production. I think you have raised a legitimate concern here, but agree with Matthew Brown that calling the

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 11:53, Dik Takken wrote: > That sounds like a great future extension. Then it would be nice to have > the name of the new type match the name of the function that checks for > it. In case the existing 'string' type would be paired with a new > 'lstring' type the existing

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 13:30, Dan Ackroyd wrote: > [...] it will cause some fatal errors in production. > No, the only way fatal errors can occur is if you choose to make them fatal (in userland code). I have included examples of the literal_concat() and literal_implode() functions in the

Re: [PHP-DEV] [RFC] is_literal

Hey Thomas, On Mon, Jun 14, 2021, 15:27 Thomas Nunninger wrote: > Hi! > > > class UserPreferences { > > private DB $db; > > > > function getColor(): string { > > $preferredColor = $this->db->getColor(); > > > > if ($preferredColor === 'light') { > >

Re: [PHP-DEV] [RFC] is_literal

Hi! class UserPreferences { private DB $db; function getColor(): string { $preferredColor = $this->db->getColor(); if ($preferredColor === 'light') { return '#fff'; } if ($preferredColor === 'dark') { return '#000';

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 08:30, Dan Ackroyd wrote: > Hi Craig, Joe, > > While I think the idea behind this RFC is great, the current > implementation is terrible, as it will cause some fatal errors in > production. > > I'm not sure it's productive to call the implementation terrible. With

Re: [PHP-DEV] [RFC] is_literal

Hi Craig, Joe, While I think the idea behind this RFC is great, the current implementation is terrible, as it will cause some fatal errors in production. # The problem Imagine we have this code: function getInfoPanel(UserPreferences $up): string { $html = ""; $html .= // more html here

Re: [PHP-DEV] [RFC] is_literal

On 13-06-2021 21:46, someniatko wrote: > 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

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 09:07, Pierre wrote: > Le 14/06/2021 à 02:41, Mike Schinkel a écrit : > > A big*NO* on warnings. Full stop. > > [...] Any warning raised by the low level functions would be too > restrictive. > Hi Pierre, I'll be talking to Mike on Zoom later today (5pm UK time), which

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 08:34, someniatko wrote: > I am sure even without a dedicated type it is still a valuable addition to > the engine [...] IMO it's okay to ship the feature without it for now. Thanks someniatko, it's certainly something I'm interested in (8.2?), as I think a dedicated

Re: [PHP-DEV] [RFC] is_literal

Le 14/06/2021 à 02:41, Mike Schinkel a écrit : A big*NO* on warnings. Full stop. Hello, I agree. A lot of DBAL / ORM / query builders tools exist and use the mysqli_, pgsql_ or PDO libraries as simple arbitrary SQL executor, and handle the security aspect at a higher level. Any warning

Re: [PHP-DEV] [RFC] is_literal

Nevertheless, I am sure even without a dedicated type it is still a valuable addition to the engine. Just to clarify, I understand that if this would require too much additional work to implement the type, IMO it's okay to ship the feature without it for now. I was just replying to other

Re: [PHP-DEV] [RFC] is_literal

> And I agree, there would be value in having a `literal-string` type, > especially when working with IDE's and Static Analysers; but it brings a > couple of issues that the is_literal() function solves: Yeah, those are valid arguments why we should have a dedicated `is_literal()` function, and

Re: [PHP-DEV] [RFC] is_literal

> 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

Re: [PHP-DEV] [RFC] is_literal

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

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

Re: [PHP-DEV] [RFC] is_literal

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,

Re: [PHP-DEV] [RFC] is_literal

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

Re: [PHP-DEV] [RFC] is_literal

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

Re: [PHP-DEV] [RFC] is_literal

Hi Craig, > On Jun 12, 2021, at 1:00 PM, Craig Francis wrote: > > Hi Internals, > > I'd like to start the discussion on the is_literal() RFC: > > https://wiki.php.net/rfc/is_literal Nice! There is an awful lot to like here. And few bits of concern. What's to like? --- 1.

Re: [PHP-DEV] [RFC] is_literal

On 2021-06-12 22:21, Craig Francis wrote: On Sat, 12 Jun 2021 at 19:59, Lauri Kenttä wrote: Hi, I wrote the untaint() / make_literal() function, just in case. implode("", array_map(fn($c) => $chars[ord($c)], str_split($s, 1))) https://3v4l.org/EaN9Z#focus=rfc.literals Sorry and bye.

Re: [PHP-DEV] [RFC] is_literal

On Sat, 12 Jun 2021 at 19:59, Lauri Kenttä wrote: > Hi, > > I wrote the untaint() / make_literal() function, just in case. > > implode("", array_map(fn($c) => $chars[ord($c)], str_split($s, 1))) > > https://3v4l.org/EaN9Z#focus=rfc.literals > > Sorry and bye. > > Yes, I have a similar example

Re: [PHP-DEV] [RFC] is_literal

Hi, I wrote the untaint() / make_literal() function, just in case. implode("", array_map(fn($c) => $chars[ord($c)], str_split($s, 1))) https://3v4l.org/EaN9Z#focus=rfc.literals Sorry and bye. -- Lauri Kenttä -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] is_literal

Afternoon all, While this is not at all my idea, I wrote the patch, so my words may seem bias/hollow. Still, here are some words ... In the past this kind of feature would have been extremely invasive, it would have had so many edges because of the way we handled strings that it was never really

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 23:22, Jakob Givoni wrote: > I'll suggest is_from_literal() as a more precise formulation. Good suggestion, I've added it to the list of Open Issues (if we can determine the different ways this can be achieved, without affecting performance, then we can see what people

Re: [PHP-DEV] [RFC] is_literal()

On Sat, Mar 21, 2020 at 4:58 PM Craig Francis wrote: > I'm happy to use a different name; but I should add that is_numeric() isn't > really a type, there are other functions such as is_writable(), and the taint > extension uses is_tainted(). Right, good points. However, to my logic, whether

Re: [PHP-DEV] [RFC] is_literal()

Hi Tyson, Thanks for your email, I really appreciate it. I'm not a C developer, but if I was to have a go at implementing `is_literal()`, I probably would start with the existing taint extension. But you're right, that approach can cause performance issues, and doesn't play well with XDebug

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 21:23, Jakob Givoni wrote: > On Sat, Mar 21, 2020 at 3:26 PM Craig Francis > wrote: > > > > As to the name, it's to work alongside functions such as > > is_int(), is_string(), etc - is that a good enough reason? > > I think it could cause confusion since int and string

Re: [PHP-DEV] [RFC] is_literal()

Hi Craig, https://github.com/laruence/taint#taint notes that "Please note that do not enable this extension in product(ion) env, since it will slowdown your app." - That repo already provides is_tainted() http://docs.php.net/is_tainted A fork of that repo would theoretically allow

Re: [PHP-DEV] [RFC] is_literal()

On Sat, Mar 21, 2020 at 3:26 PM Craig Francis wrote: > > As to the name, it's to work alongside functions such as > is_int(), is_string(), etc - is that a good enough reason? I think it could cause confusion since int and string are value types, - literal is not a type as such, it merely

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 20:06, Ben Ramsey wrote: > This seems very similar to the taint extension Hi Ben, Yes, it is similar; I hope I've covered the differences under the "Taint Checking" heading (please let me know if that could be improved).

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 19:54, Dan Ackroyd wrote: > On Sat, 21 Mar 2020 at 19:14, Craig Francis > wrote: > > > > Any feedback would be appreciated. > > The RFC should probably define what a literal is. > > Good point Dan, I've added it to the intro. Please let me know if it needs more work

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 19:51, Larry Garfield wrote: > Eg, there's plenty of very good reasons to put a template string into the > database rather than a file literal. Or to build an SQL query dynamically > in ways that an is_literal check would not allow, at least not without an > absurdly

Re: [PHP-DEV] [RFC] is_literal()

> On Mar 21, 2020, at 14:13, Craig Francis wrote: > > Hi, > > I've written up my suggestion for a is_literal() function: > > https://wiki.php.net/rfc/is_literal > > Any feedback would be appreciated. > > Craig This seems very similar to the taint extension. How does it differ from

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 19:14, Craig Francis wrote: > > Any feedback would be appreciated. The RFC should probably define what a literal is. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] is_literal()

On Sat, Mar 21, 2020, at 2:13 PM, Craig Francis wrote: > Hi, > > I've written up my suggestion for a is_literal() function: > > https://wiki.php.net/rfc/is_literal > > Any feedback would be appreciated. > > Craig While I appreciate the intent, without an untaint() or equivalent I fear its