Re: [PHP-DEV] [RFC] is_literal

[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 sections "Non-Parameterised Values" and "Future Scope," if I 
> understand correctly...
> 
> ...you're right, we do need to support PhpMyAdmin, Adminer, systems like 
> Drupal (...)

That is good to know.

> Native functions like mysqli_query() should be covered in a future RFC, but 
> still only use warnings. The exact details would need to be confirmed, but 
> should provide a simple way to mark certain non-literal strings as trusted, 
> and still have a way to switch off those warnings entirely (e.g. legacy 
> systems).

Having code that is valid for a given application throw warnings is a huge 
non-starter to me. 

During development I believe is is a best practice to develop with display of 
errors *and* warnings to eliminate all warnings and all errors before moving to 
testing, staging and production. If warnings are not eliminated it is to easy 
for a developer to miss warnings that are important vs. ones that are "OK to 
ignore."

To illustrate, I just added a single trigger_error() to the project I am 
currently working on.  Take a look at what it does to my project:

https://www.evernote.com/l/AAV2_-KSz2RA9pcwtWo8AQJseoZYHtnD-aw

It would be impossible to program with any library that throws a warning and 
also develop with a "zero warnings" policy.

So again, having legitimate code display warnings is a full-stop "no" in my 
book.

More on this below.

> Ideally as future scope, we would also provide a way for certain projects to 
> opt-in to having exceptions raised (the militant option), which would not be 
> appropriate for the vast majority of developers, but it's the level I'd find 
> useful for some of my projects (dealing with medical records and other 
> sensitive information).
 
Yes, when you are in full control of your source code, being able to use 
is_literal() liberally would be great. 

BUT.  There needs to be a way to mark certain non-literal strings as trusted 
for when using Other People's Code(tm), and as I will argue in the rest of this 
reply, that way needs to be part of the RFC that also introduces is_literal().  
Doing otherwise is like manufacturing a poison but not also manufacturing its 
antidote.

> As to how we could (in a future RFC) mark certain non-literal strings as 
> trusted, I've briefly touched on how this can work in the "Future Scope" 
> section (it's an idea I copied from Trusted Types in JavaScript, which 
> follows the same principle). I only did a summary because the exact 
> implementation would need to be discussed later (there are a few options, but 
> they all rely on is_literal() being implemented first).
>  
> First, we need libraries to use is_literal() to check inputs from developers 
> (i.e. the code they didn't write), which is their main source of injection 
> vulnerabilities. 

And that is where the first problem lies.  Assuming libraries do start using 
is_literal() and there is not yet an existing way to mark a string as trusted, 
then at best-case the developer using that library will have to jump through 
hoops when they need a non-literal use-case, and worse-case this will mean the 
developer will be unable to use said library for their use-case. 

And it might be the only library available, or only one "approved" by their 
company (which would be worse than the above worst case.)

Introducing is_literal() without make_literal() is like manufacturing a gun 
without a safety catch.  

I assume that implementing make_literal() would not be a technical challenge, 
or would it?

Would there be any reason *not* to include make_literal() as part of your RFC?

> What goes on inside the library is entirely up to them (they know that they 
> are doing). For their output, they create a stringable value-object, which 
> (as future scope) could be marked as trusted for certain functions (like 
> mysqli_query).
> 
> These value-objects could be as simple as a single private property (value), 
> a __construct() method that takes the libraries output, and a __toString() 
> method to return it; or the library might want to be extra sure of its 
> output, and use something like the Query Builder example linked in the 
> "Non-Literal Values" section.

Having library developers create a stringable value-object is a nice idea, but 
you are assuming all library vendors will be enlightened enough to do so. 

On one end you will have library developers who are not sufficiently educated 
on this topic (and I will remind you of the RFC's comment regarding education) 
and on the other end you will have library developers who are dogmatic in their 
belief that requiring actual literals is the only one true way to program (and 
here I will remind you of the RFC's comment 

Re: [PHP-DEV] [RFC] is_literal

[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 your feedback, along
with others, helped me focus on the main concerns.



> The only remaining issue I have is performance — Psalm and other static
> analysis tools perform quite a lot of concatenation (and never have to
> worry about user input). What sorts of slowdowns do you see when running
> those tools?
>


For Psalm in particular, I’ve just done a quick run of 10 alternating tests
on a website with 90,000 lines of code, at error level 2 (the default
level), using `--no-cache`, using PHP 8.1.0-dev from a couple of weeks ago.
Without `is_literal` it averaged 8.355s, and with is_literal, 8.373s - so
that’s a +0.018s difference, or +0.22% (full numbers below).

It’s not full lab-condition testing, but hopefully more than representative
enough.

(And repeating the RFC, just for a quick reference: Máté, who does
stress-tests on servers, found that the Laravel Demo was +0.124%,
and Symfony Demo was +0.161%. There was also a stress test, which simply
concatenated 4 strings, 5 million times, with no other actions, so not
exactly representative of a typical PHP script, which was +3.719%. None of
these tests involved connecting to the database, as the variability
introduced made it impossible to measure that level of difference).


Full Psalm-check Stats:

A = Without is_literal
B = With is_literal

A = Checks took 8.36 seconds and used 229.894MB of memory
B = Checks took 8.46 seconds and used 229.894MB of memory
A = Checks took 8.43 seconds and used 229.894MB of memory
B = Checks took 8.57 seconds and used 229.894MB of memory
A = Checks took 8.50 seconds and used 229.894MB of memory
B = Checks took 8.40 seconds and used 229.894MB of memory
A = Checks took 8.36 seconds and used 229.894MB of memory
B = Checks took 8.32 seconds and used 229.894MB of memory
A = Checks took 8.31 seconds and used 229.894MB of memory
B = Checks took 8.38 seconds and used 229.894MB of memory
A = Checks took 8.30 seconds and used 229.894MB of memory
B = Checks took 8.29 seconds and used 229.894MB of memory
A = Checks took 8.31 seconds and used 229.894MB of memory
B = Checks took 8.37 seconds and used 229.894MB of memory
A = Checks took 8.37 seconds and used 229.894MB of memory
B = Checks took 8.32 seconds and used 229.894MB of memory
A = Checks took 8.31 seconds and used 229.894MB of memory
B = Checks took 8.29 seconds and used 229.894MB of memory
A = Checks took 8.30 seconds and used 229.894MB of memory
B = Checks took 8.33 seconds and used 229.894MB of memory

Re: [PHP-DEV] [RFC] is_literal

[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 projects, and is currently
> being added to JavaScript. It's a lightweight and simple approach:
> "Distinguishing strings from a trusted developer from strings that may be
> attacker controlled", allowing Libraries to identify the mistakes made by
> the thousands of developers using them incorrectly.
>
> When Libraries use is_literal() to protect against these mistakes, we can
> trust their output, and (as covered in the Future scope section) PHP can
> then raise warnings with certain native functions like PDO::query,
> mysqli_query, exec, preg_match, etc. (we would only consider warnings,
> anything stricter like exceptions would be in many years time, if at all -
> the intention is to alert and inform people, not break things).
>
> The length is due to the FAQ Section, on why it's needed, how it can be
> used by Libraries, and the important differences of using this flag versus
> the flawed Taint Checking approach with its false sense of security
> (error-prone escaping).
>
> Thanks,
> Craig Francis
>
>
> PS: If anyone wants to discuss face-to-face on Zoom, I'll be available (UK
> Time/BST/UTC+1) at:
>
> https://chat.craigfrancis.co.uk/
>
> Saturday 12th June, 6pm to 8pm;
> Sunday 13th June, 10am to Midday;
> Monday 14th June, 5pm to 7pm;
> Tuesday 15th June, 9pm to 11pm;
> Thursday 16th June, 10am to Midday;
> (other times on request)
>


Hi Craig and Dan,

I was skeptical about the first draft of this RFC when I saw it last
month, but now I see the light (especially with the concat changes). This
looks like a very solid solution for any library authors wanting to add a
layer of protection against SQL injection attacks. Sorry for any
unnecessary grief I caused.

The only remaining issue I have is performance — Psalm and other static
analysis tools perform quite a lot of concatenation (and never have to
worry about user input). What sorts of slowdowns do you see when running
those tools?

Best wishes,

Matt

Re: [PHP-DEV] [RFC] is_literal

[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,
simply because it will require more discussion (which I'm happy to help
with).

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:

1) Libraries need to support older versions of PHP, so they wouldn't be
able to use the `literal-string` for many years; whereas they can use
`function_exists('is_literal')` today, probably to provide their own
function that simply returns true on pre PHP 8.1.

2) The is_literal() function gives the libraries a choice on how to handle
the situation. At the moment they just receive a string of unknown origin,
so they can trigger a warning, while also supporting legacy projects who
want to switch off the warnings. And some developers might want to use a
library that has an option that can raise exceptions (so they can be
certain there are no issues).

Craig

Re: [PHP-DEV] [RFC] is_literal

[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 forgotten, to let them type their whole
codebase, including internal, against the new `literal-string` type,
which would be enforced by PHP all the time? From my perspective as a
PHP developer, it would serve clearer intent than only checking in a
few places which presumably may take user input, i.e. you could
explicitly state "this function does only work with literal strings".

Regards,
someniatko

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[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()` and
> `ReflectionProperty#setAccessible()`, making `ReflectionMethod` and
> `ReflectionProperty` accessible by default.
> 
> The rationale is:
> 
>  * this API is probably coming from a copy-pasted java-ism (although I
> couldn't verify that, so I did not factor it into the RFC)
>  * removes the last bit of mutable state from `ReflectionProperty` and
> `ReflectionMethod`
>  * simplifies usage of the API
>  * if I'm up to no good, I don't need to actually solemnly swear that i am
> up to no good (that's stuff for fantasy books)
> 
> I don't really know what the deadline for 8.1 features is, but I assume
> it's coming up quite quickly, so friendly NikiC poked me to see if this
> long-standing patch of mine was still relevant.
> 
> Should be short/sweet, but I'm looking forward to your feedback.

The deadline for new features for 8.1 is July 20: 
https://wiki.php.net/todo/php81
(with some discretion from the release managers, e.g. for amendments to changes 
already made in 8.1)

I think that isAccessible should be added if any applications actually did 
depend on ReflectionException
being thrown for correctness - they could throw their own exception if 
isAccessible was false.
(e.g. for code meant to handle possibly undefined public typed properties by 
checking for initialization
then getting the value)

I can't actually remember needing this personally, though, since 
`$obj->{$method}()` could be used.
I've only used this to access private and protected properties/methods.

Regards,
Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[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 it throw a deprecation in the future, and presumably
> then having those methods be removed outright, is the long-term plan.  I'm
> good with that too, but I don't see why the full death-cycle isn't
> included, and half of it is instead punted to a future RFC.
>

Two reasons:

>
 1. I don't see a removal of the methods as necessary at all anyway: while
they are no-op, removal increases the scope of the RFC too much, and it's
really not worth going there for the added work, when a further RFC would
make it more mechanical/isolated for 8.2+ and 9.0 afterwards. If the
methods survived in 9.0 too, it would be almost no impact anyway.
 2. The usage of E_DEPRECATED inside php-src and in the composer ecosystem
at large irks me, a lot. Since we operate on a scripting language, we defer
things to the runtime, and by doing so we turn pure APIs into impure ones,
and lead to potential production disruption (happened to me multiple times,
precisely because of deprecations). I believe we don't have the right tools
to address deprecations upfront **yet**, and I'm mostly hoping for the
`#[Deprecated]` attribute to make its appearance before introducing yet
another harmful `trigger_error()` call. In this case, we have a clean cut
of API that can be **declared** deprecated, rather than turned into a
runtime problem: I want to see if the situation improves, before creating
new problems.

Would it help if I raised a second Draft RFC together with this one, so
that the promise of dealing with this later on is already fulfilled?

>

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

[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 runtime behavior from
> `ReflectionMethod#setAccessible()` and
> `ReflectionProperty#setAccessible()`, making `ReflectionMethod` and
> `ReflectionProperty` accessible by default.
> 
> The rationale is:
> 
>  * this API is probably coming from a copy-pasted java-ism (although I
> couldn't verify that, so I did not factor it into the RFC)
>  * removes the last bit of mutable state from `ReflectionProperty` and
> `ReflectionMethod`
>  * simplifies usage of the API
>  * if I'm up to no good, I don't need to actually solemnly swear that i am
> up to no good (that's stuff for fantasy books)
> 
> I don't really know what the deadline for 8.1 features is, but I assume
> it's coming up quite quickly, so friendly NikiC poked me to see if this
> long-standing patch of mine was still relevant.
> 
> Should be short/sweet, but I'm looking forward to your feedback.

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 it throw a deprecation in the future, and presumably then 
having those methods be removed outright, is the long-term plan.  I'm good with 
that too, but I don't see why the full death-cycle isn't included, and half of 
it is instead punted to a future RFC.

Please explain.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] is_literal

[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() because it's shorter (I'm a slow typer), and to match the
current convention of existing "is_*" functions (which all use a single
word suffix).


2. Regarding the sections "Non-Parameterised Values" and "Future Scope," if
> I understand correctly, your vision is to ultimately require all SQL and
> other vulnerable literals to be written as literals in the source code for
> them to be used or otherwise disallowed by future library code and/or PHP
> internal functionality?
>


No, fortunately that's not the case, as you're right, we do need to support
PhpMyAdmin, Adminer, systems like Drupal (which take certain values, like
the table name, from user input), and (as noted in your 4th point), there
is a lot of existing code that would break if we were militant about
requiring is_literal() for mysqli_query() and other functions.

Native functions like mysqli_query() should be covered in a future RFC, but
still only use warnings. The exact details would need to be confirmed, but
should provide a simple way to mark certain non-literal strings as trusted,
and still have a way to switch off those warnings entirely (e.g. legacy
systems).

Ideally as future scope, we would also provide a way for certain projects
to opt-in to having exceptions raised (the militant option), which would
not be appropriate for the vast majority of developers, but it's the level
I'd find useful for some of my projects (dealing with medical records and
other sensitive information).

As to how we could (in a future RFC) mark certain non-literal strings as
trusted, I've briefly touched on how this can work in the "Future Scope"
section (it's an idea I copied from Trusted Types in JavaScript, which
follows the same principle). I only did a summary because the exact
implementation would need to be discussed later (there are a few options,
but they all rely on is_literal() being implemented first).

First, we need libraries to use is_literal() to check inputs from
developers (i.e. the code they didn't write), which is their main source of
injection vulnerabilities. What goes on inside the library is entirely up
to them (they know that they are doing). For their output, they create a
stringable value-object, which (as future scope) could be marked as trusted
for certain functions (like mysqli_query).

These value-objects could be as simple as a single private property
(value), a __construct() method that takes the libraries output, and a
__toString() method to return it; or the library might want to be extra
sure of its output, and use something like the Query Builder example linked
in the "Non-Literal Values" section.

As future scope, this allows functions like mysqli_query() to simply check
for a literal, or one of these trusted value-objects (or have warnings
switched off entirely).


3. I notice your RFC does not grant sprintf() the ability to return a
> string with the "literal" flag even though sprintf() can frequently return
> strings composed from known literals and safe numeric value.
>


Joe has created a `literal_sprintf()` function for testing, I think it does
exactly what you're suggesting, and I believe that logic can be applied
directly to sprintf().

The only reason I've been hesitant is to keep this implementation of
is_literal() limited to identifying literals and supporting concatenation
(to keep it simple, and easy to use).

It's like the "String Splitting" part in the RFC, it's probably fine, and
we can do it if there's interest; but we also need to consider what issues
it might cause (if any). From a security point of view, it's always best to
keep something as simple as possible (and that may well include supporting
sprintf), because "You cannot prove security. You can only prove
insecurity".



> 4. Regarding the section "WHERE IN" you argue that we should push everyone
> to use parameters properly — which is a great idea in theory — but that
> would have a significant breakage in existing sites online.
>


Hopefully my answer to #2 addresses this, as you're right, that would
definitely cause more problems than it solves. Certainly for this
implementation I support libraries providing warnings and think those would
be the most appropriate, rather than exceptions. (Though obviously
libraries know their user bases best of course).

In summary of my future scope answer above, libraries could be able to mark
their output as trusted for functions like mysqli_query(). For SQL it would
ideally still be a literal string, but that's not always possible
(especially with HTML), so that's where the trusted stringable
value-objects would be used. For legacy systems, developers could simply
switch off the warnings entirely (but at least 

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

[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
`ReflectionProperty#setAccessible()`, making `ReflectionMethod` and
`ReflectionProperty` accessible by default.

The rationale is:

 * this API is probably coming from a copy-pasted java-ism (although I
couldn't verify that, so I did not factor it into the RFC)
 * removes the last bit of mutable state from `ReflectionProperty` and
`ReflectionMethod`
 * simplifies usage of the API
 * if I'm up to no good, I don't need to actually solemnly swear that i am
up to no good (that's stuff for fantasy books)

I don't really know what the deadline for 8.1 features is, but I assume
it's coming up quite quickly, so friendly NikiC poked me to see if this
long-standing patch of mine was still relevant.

Should be short/sweet, but I'm looking forward to your feedback.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] is_literal

[Mike Schinkel]

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. Adding a proactive method for guarding against injection vulnerabilities 
would be a huge step forward for PHP. This should not be underemphasized.

2. That you added the section "Previous Work" and covered what other languages 
are doing in this regard.

3. The "Thanks" section and all the external references and prior comments that 
provides insight into how this RFC was developed.

4. And I love that you publicly stated these points in an RFC:

a. Why not use static analysis? It will never be used by most 
developers.
b. Why not educate everyone? You can't - developer training simply does 
not scale, and mistakes still happen.


What's of concern? 
-
(Note: the last point could address concerns #2 and #4.)

1. Bike-shedding a bit, but I find a bit of cognitive dissonance over the 
semantic incorrectness of is_literal(), similar to Jakob Givoni's concern. 

I also fear it will be confusing for developers who know what a literal is, and 
thus I agree with Jakob. 

Minimally I'd ask for a separate vote on is_literal() vs. is_from_literal(). 

2. Regarding the sections "Non-Parameterised Values" and "Future Scope," if I 
understand correctly, your vision is to ultimately require all SQL and other 
vulnerable literals to be written as literals in the source code for them to be 
used or otherwise disallowed by future library code and/or PHP internal 
functionality?

If I did not misunderstand I believe you would disallow an important class of 
functionality from being implemented in PHP, including several existing and 
widely used applications such as but not limited to PhpMyAdmin and Adminer that 
open and interact with arbitrary SQL databases.  It would also disallow using 
any data returned by APIs where the PHP application cannot know in advance what 
data will be acquired, even if that data has been properly escaped and/or 
sanitized.

3. I notice your RFC does not grant sprintf() the ability to return a string 
with the "literal" flag even though sprintf() can frequently return strings 
composed from known literals and safe numeric value. And I have frequently see 
it used for this purpose, e.g.:

$fields = ['id','name'];
$table = 'my_table';

$sql = sprintf( 'SELECT %s FROM %s WHERE ID=%d', 
implode( ',', $fields ),
$my_table,
intval($_GET['id']));

Of course your section "WHERE IN" "addresses" this, but please see #4 below. 

I argue sprintf() should be able to pass thru literal flags and validate 
integer values to determine that the result is literal.  Am I missing something 
here?

4. Regarding the section "WHERE IN" you argue that we should push everyone to 
use parameters properly — which is a great idea in theory — but that would have 
a significant breakage in existing sites online.  While many here in Internals 
seem to look down on WordPress if does power over 40%[1] of the web at this 
point and this would break most if not all those sites if the site owners or 
their hosts were to upgrade to a version of PHP that was militant about 
requiring is_literal() for mysqli_query()[2].  

And yes, WordPress could upgrade their core code[3] to address this, but that 
would not also fix the 60k plugins and 10k themes on WordPress.org 
, or likely the million+ combined custom plugins and 
themes in use on the web. 

Is it really reasonable to change PHP to just break of all those sites so that 
we can force all the site owners to beg and plead with their plugin and theme 
developers to better protect them from injection errors?  Seems that medicine 
might be worse than the cure, at least for all those site owners. 

5. Given #2 and #4, I think your section "Support Functions" is missing what 
would allow WordPress, PhpMyAdmin, Adminer and all other PHP applications to 
address the concerns in #2 and #4 and it is neither literal_concat() nor 
literal_implode(). 

The function we would need is the one Lauri Kenttä wrote (in jest?), but we'd 
need one that is performant, not a userland version. Name it as_literal() or 
make_literal() or even as_unsafe_literal() — whichever chosen is unimportant 
IMO — but applications like the ones I mentioned need to be able to say "I 
absolutely know what I am explicitly doing so do not throw a warning or an 
error telling me my value is `not a literal`, dammit!"  

Certainly most people would not use such a method by accident, especially if 
called something like `as_unsafe_literal()`.  There might even be ways to 
validate that this was not used by a copy-and-paste artist, but I will leave 
that validation to other people who are smarter than me.

6. Regarding the section