Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114951 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 95440 invoked from network); 18 Jun 2021 13:35:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jun 2021 13:35:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BE41A1804DB for ; Fri, 18 Jun 2021 06:52:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 18 Jun 2021 06:52:41 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id r5so16858156lfr.5 for ; Fri, 18 Jun 2021 06:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=craigfrancis.co.uk; s=default; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uke8TQoFD1Uzr64Urs+ZmoZPBIwBAgo5O45pnbRdU0g=; b=SQeSrnaQZAL19CrHTvAGhBWnEwO4jVMbWj1I5fgWVQ8WRmPTFGGB7mgkb32HeX3g91 ZQKTsOvb8sf1ywKGDLTGzObF+Tds5SsjfzM5Rf+gQ6K8v5iC46k3l0ftEB0URu1Uja9n j+naIwO1KHD5V2Py2gUF+2KEaN3IeM8hMw51g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uke8TQoFD1Uzr64Urs+ZmoZPBIwBAgo5O45pnbRdU0g=; b=jXm4IbIh2nx7oDxQCYsw+AqP8hIDB4vzCxCbrG5S82RXRJqS4mOJ3dnp1Zm/xdThnN TmTub3eXXL4/G+LQjgN8WmRnxJZ9VPw7QlvZKk7mM8/KLVTJJEC27/nvdVyTifbPz3BS nf+nfwoP59QSqQOk0/xcIyRhZqcvEQA0VQP52tKNahveekpZ1rWwExSc5ztQ+JwgMhh4 WvEPveNVZduUh/qlDxLubq6Uac7MiEpnEuqj9veZV0yqIq7D6KEqlYdzOqJr0fGwdSu4 eoX46TAYz0QPRYbYeKK2LlaUpoRy/0GmdprRMzKXksn75Afl2c2ftyFBcPyVOtsgPznl geXw== X-Gm-Message-State: AOAM5324RMvzpHnoO0Zt5++Y8LSSqEJ6AVn/66T7fqhhN8WaM+a4e9C5 QXYN3Y+yOouMDoMmzXuxIc+v626YVF/Py7UAgwqb/g== X-Google-Smtp-Source: ABdhPJxQVUrdnxMHpFLajZNfHpXWD0VLnYjJYhzQ+9EXlVxDjDUg8QBeIVls/47OCrMP6D8JTcwepkJBis9eWOY/T6Q= X-Received: by 2002:ac2:4a61:: with SMTP id q1mr3306449lfp.572.1624024356673; Fri, 18 Jun 2021 06:52:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 18 Jun 2021 14:52:25 +0100 Message-ID: To: Pierre Cc: Guilliam Xavier , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000e2ec8205c50aa2a4" Subject: Re: [PHP-DEV] Re: [RFC] is_literal From: craig@craigfrancis.co.uk (Craig Francis) --000000000000e2ec8205c50aa2a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 18 Jun 2021 at 12:25 pm, Pierre wrote: > Le 18/06/2021 =C3=A0 12:45, Guilliam Xavier a =C3=A9crit : > > 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 (e.g. random_int() or even `$_GET['limit']`) > > OK I get it. > > I followed the initial discussions but I didn't read everything for a > while. > > Doesn't it mean that is_literal() which doesn't test anymore if something > is literal does a bit more than that ? > I think there may be a misunderstanding here. We are only going to =E2=80=98trust=E2=80=99 variables created from: - Literal Strings (i.e. written by the developer), - Integers. It=E2=80=99s a very basic approach. The only change to the implementation h= as been the inclusion of integers, nothing else. (Any Future Scope is not relevant yet in regards to a new type etc. and it currently works on its own.) The original is_literal() function idea is nice, why not having both, > is_literal() that exposes a purely technical information in one side, and > [one] that is more specialized [=E2=80=A6] than simply string static stat= e, for std > provided SQL database layers ? We have not found any issues with allowing integers in SQL, HTML, CLI; and other contexts as well (like preg, mail additional_params, XPath query, and even *gasp* eval). While philosophically more pure, there is actually no extra security benefit for excluding integers. And to support having 2 functions, we would need 2 flags on strings. These flags are limited, and managing 2 flags would affect performance. Craig --000000000000e2ec8205c50aa2a4--