Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115153 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94477 invoked from network); 26 Jun 2021 12:10:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Jun 2021 12:10:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AC5E21804C3 for ; Sat, 26 Jun 2021 05:30:03 -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.9 required=5.0 tests=BAYES_00,BIGNUM_EMAILS, DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 ; Sat, 26 Jun 2021 05:30:03 -0700 (PDT) Received: by mail-vs1-f45.google.com with SMTP id g28so4418878vsr.13 for ; Sat, 26 Jun 2021 05:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4swpFMOswh7M/3roK7A8R9CWQvw46OBoUrZrM6SYlMk=; b=oO3S/CG11ygwfBMvoL60X2ksdQ+EaDzwoIr3yyOkFM8Fj+gxUmSj3NtpJFLKyJJMvC vuFnqbW0Nqn24X6+jeIPY3pYBaIRVvwwYdnoCGlgKzxAWrPvD01mQV5q9gDHebxiAP1v bSPvDvpeXKi143i5fs43HvDjuGQWZ33jz49kRA4mY6jgN7z9++uaqEj3NfurKMX19cL2 32DO0jFVfkzB5kvWGrgWYQcYEE9/H8vZs4C9GBn8T+xYbTQ40ZLF2cXzoNAj/ReJuwKv mZRg15QJb/fmw+oKaUvdxwLAeucyIVtc2HpSfsqvbP3srO+PB7/r+hYoLMhqIBemXbQI 9g9Q== 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=4swpFMOswh7M/3roK7A8R9CWQvw46OBoUrZrM6SYlMk=; b=jF4APPNY4ax8PMN1jX6Fp5t4HkI1X4KBeoEaDMeYI5csEh4FTlUkjC3fOqOKX2kRph dQ72e3sxIjoyMsZ3YxoClzUZZsgetAWlJ1/rDSArr5N79mmPHgAv96c0iDcG3jVBhwGX 0KCP+gs0NEgWK2RXxL+1N6DdbkdPBQTjtnPXd+1+j15kidopCpCRP7zPC4C+EyKNsY0M Da16Zu2oZGXYY9vD5JgqFUCBBcKwAYH17QGjtEzdlNP+9VTfKLSXAoc+h8qzU8EQ6kO3 MmUAfZq4X1dFk3MeJJoFUxaWMy7DIFNVjAWK+cPDsHX1IwVojgm3Wc/+XkJg9vei3PRk otkA== X-Gm-Message-State: AOAM530ezXoD6i9s+9ckfAn253xsTUD/rqhZVEBB3WvViBVSolOnXBEC XXDwpnOKDe8qmBLOTewLAX5mIcW9IqYaq1r3qTFpmQ== X-Google-Smtp-Source: ABdhPJyyn4KUxkNR4fML6CpTKRpQI0lzv09vaLG2loZ/pJH2WswsRMt94X9EZn4Y9lYX61G3WflJZjJR74GttfSgI3M= X-Received: by 2002:a67:f7c2:: with SMTP id a2mr11914228vsp.3.1624710603042; Sat, 26 Jun 2021 05:30:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 26 Jun 2021 13:29:50 +0100 Message-ID: To: Craig Francis , Joe Watkins Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] is_literal() is back From: Danack@basereality.com (Dan Ackroyd) Craig, On Fri, 25 Jun 2021 at 23:21, Craig Francis wrote: > > We're going back to the original is_literal() proposal. > > https://wiki.php.net/rfc/is_literal The RFC still contains carrying the string literal flag through string concatenation, which is still not a good idea. And it still doesn't say what people are meant to do when there is an error. Dan Ackroyd wrote: > > Please can you go into some detail about what you think people are > > meant to do when they detect a non-literal used where a literal is > > expected? Craig Francis wrote: > By using a simple function, it allows the library to handle > the situation however it likes. That's not an answer to the question. Just saying "you can handle it however you like" skips over the core problem with RFC, which is that by supporting carrying the literal flag through string concatenations, > It allows silly mistakes to slip through and make it to production. As > per https://news-web.php.net/php.internals/114858: > Assume that both UserPreferences and getInfoPanel code is covered by > unit tests. 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. For is_literal checks, what's going to happen is: * programmer makes a mistake, that isn't caught by a test. * programmer deploys site, and entries about non-literal strings start being written to log files. * someone then needs to remember to check the log files, and pull out the appropriate entries, and make a ticket for them to be investigated. * someone then needs to pick up that ticket, investigate the cause of the non-literal string being used, and trace it back to which module/library is causing it, then update the ticket for someone on that team to fix it. * someone on that team needs to have that ticket prioritised before they start work on it. > I'd really like anyone who is promoting this RFC to answer the > question from https://news-web.php.net/php.internals/115010 : > Why are you prioritising speed of adoption, over reducing the cost of > using this feature for projects over say the next 5 or 10 years? It's going to take more time to track down an error than it will be to start using the feature. I had planned to use this RFC to prevent XSS attacks, and in it's current state I'm going to get a notice of "There's some userdata in an inappropriate place. Have fun finding it!" because the information about where that user data is in the string will be lost. It's still bizarre to me that the RFC is proposing something that allows mistakes to slip through to production. cheers Dan Ack btw, email or ticketing systems are not an appropriate place to log this type of problem. They could happen on every page load, and so generate hundreds of errors per second. As amusing as it is to look back at the times that I have generated 10,000 error emails per second in the past, I don't want to repeat that experience. Also, I'm going to cross-post this, as it's unreasonable to expect people to read all of the different threads.