Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115067 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 44002 invoked from network); 23 Jun 2021 14:36:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Jun 2021 14:36:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C968D1804CC for ; Wed, 23 Jun 2021 07:54:43 -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.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (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 ; Wed, 23 Jun 2021 07:54:43 -0700 (PDT) Received: by mail-lj1-f169.google.com with SMTP id a16so3365065ljq.3 for ; Wed, 23 Jun 2021 07:54:43 -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=ynD+yJjsz9Hl+6q5q8/QilJEzvC88g8eFXUBbTKYHJE=; b=NhWHA/jnTBRTmL4JO2kE+6y4BOfu8wmmJQi5OXGLvXZcOoahDxDVQO+9JmGf6cNlFE e1P9R7TiwEYHIZ+5BSIgwIuVGO1qbi7gNnK1kz3UDBcoGoBq/3R/e9r3RcobBYIGO8yG /ETa5q8L+6NL+4HD+xx/YGxwP82r9KYJ6n3DE= 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=ynD+yJjsz9Hl+6q5q8/QilJEzvC88g8eFXUBbTKYHJE=; b=sHRSY5Jvdq3JDUfyKFS3MVI99qmbMaTShfwugqSRcKcP42EAbwAvngMWCdWfBB92bu xXE7DbsxCEVFvFnl2zqO9qhGwDiAGEXOPqrf57nIyhR6gDmqkURIu/ykuciIoR0J+U5o +G3m3okojKr+m/gBsyvHSk5ct5aVLdxXZc+ByVKe92vGjDyrf+Dlqz/V41Az6KlpXk0z DlDfe8/SQ3TJpR7Rv3+UkDUclYjRpLX2PhuUnQ0rv4HY5d/mRQ2KKBwU7OC8VcMu5Gfr GwbjwdLiKyTaw3xMgm/wr2Vpic0wRGRtN1Q6oVtMYOroWUfoU9sRAHAXv050AFhM+Rki 1Org== X-Gm-Message-State: AOAM533IGpTi9Ma52AocI+TczUHjoGMaz68j1AS32bTv1Maa+J/DaB8c FAatyNM80KfSgxNBUqLe0dYn+xzE0StrBDWMsLAajtGTv23aMA== X-Google-Smtp-Source: ABdhPJwtDMBVwMlJh4KkB0gg7TvL40oy4QhlnvrIVIfqU6EKniBBCvNr0gT7WFu+LTxwrKq7wi2B2ci49qvz2SlwDGw= X-Received: by 2002:a2e:8147:: with SMTP id t7mr46794ljg.241.1624460080990; Wed, 23 Jun 2021 07:54:40 -0700 (PDT) MIME-Version: 1.0 References: <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> In-Reply-To: <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> Date: Wed, 23 Jun 2021 15:54:30 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000001460df05c57016a1" Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted From: craig@craigfrancis.co.uk (Craig Francis) --0000000000001460df05c57016a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 23 Jun 2021 at 14:37, Larry Garfield wrote= : > I'm still very torn on is_literal; I fear that the people who would > benefit from it are the very people that don't use the tools that would > leverage it (DBALs et al), and so the net benefit will be small. > This RFC will not help those who aren=E2=80=99t using libraries (DBALs), th= at=E2=80=99s something we could look at in the future (I have a suggestion in the Future Scope section, but whatever that involves, it will need to use this flag, so it would need to be in place first). But - and why I=E2=80=99m here - my experience is that it=E2=80=99s still a= big issue for those who *do* use libraries. It frequently comes up at software agencies/companies that maintain their code (built with free libraries/frameworks), and employ junior developers (i.e. the cheapest), who make many "quick edits" (time is money), and in doing so introduce the issues the RFC covers (and not to say we more experienced coders don=E2=80= =99t occasionally make mistakes too!). While non-library users are the main cause, the library users are still a big part of why Injection Vulnerabilities remain at the top of the OWASP Top 10. Craig --0000000000001460df05c57016a1--