Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115158
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1E0CBB40-AB40-40B4-B56B-664062D97AA8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Sat, 26 Jun 2021 09:51:06 -0400
References: <CAFv4g+GCbRataTtCKSrej5yU259=hbjNxQVzZX+oXm_vh0z-TQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAFv4g+GCbRataTtCKSrej5yU259=hbjNxQVzZX+oXm_vh0z-TQ@mail.gmail.com>
Message-ID: <A0784946-A9F5-4EB0-B04C-EAFDD1359FF5@newclarity.net>
Subject: Re: [PHP-DEV] is_literal() is back
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_1E0CBB40-AB40-40B4-B56B-664062D97AA8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The idea behind is_literal() is of good intention, but as they say the =
road to hell is paved with good intentions.

The RFC proposes to add an internal "literal" flag to a string, the =
is_literal() function, and nothing else.=20

 Further the RFC states a vision to get "libraries to start using =
is_literal() to check their inputs."  Again, that comes from a great =
intention. =20

The problem lies with the fact that library developer who choose to =
disallow non-literal strings will offer solutions when a use-case =
literally (pun-intended) cannot produce a literal string.=20

Sure, most leading library developers will offer a solution, but many of =
the long-tail library developers will not either because it will add =
scope and/or because those library developers don't have to skill and/or =
experience to do so.

So what will those users of those libraries do when faced with a =
required to only use literal strings?  They will find a workaround so =
they can get their jobs done.  And that workaround is really simple:

function make_literal(string $non_literal):string {
    $literal =3D '';
    for( $i =3D 0; $i< strlen($non_literal); $i++ ){
        $literal .=3D chr(ord($non_literal[$i]));
    }
    return $literal;
}

You can see it in action 3v4l.org <http://3v4l.org/> here[1] and for =
posterity on gist.github.com <http://gist.github.com/> here[2].=20

Once developers start bypassing the is_literal() check then all those =
good intentions will be moot, and many who think they are secure from =
injection attacks will be vulnerable:

$sql =3D 'SELECT * FROM foo WHERE id=3D' . make_literal( $_GET['id']);
$result =3D mysqli_query($conn, $sql);

So what am I suggesting we do? =20

1. We postpone passing this is_literal() RFC until we have collectively =
addressed how userland developers will be able to handle non-literals in =
SQL, HTML, etc. when their use-cases require non-literals.

2. We could also go ahead and add the internal "literal" flag to a =
string so that if someone wants to use it to write an extension to add =
an is_literal() function in the mean time it would be available, but not =
yet standardized into PHP.

Thank you in advance for your consideration.

-Mike

[1] https://3v4l.org/oCBp7#focus=3Drfc.literals =
<https://3v4l.org/oCBp7#focus=3Drfc.literals>
[2] =
https://gist.github.com/mikeschinkel/b9abd4178db461568b813269bc936c18 =
<https://gist.github.com/mikeschinkel/b9abd4178db461568b813269bc936c18>=20=

--Apple-Mail=_1E0CBB40-AB40-40B4-B56B-664062D97AA8--