Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112359 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 20791 invoked from network); 1 Dec 2020 20:45:58 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Dec 2020 20:45:58 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3C64E1804C3 for ; Tue, 1 Dec 2020 12:13:29 -0800 (PST) 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_40,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail.thelounge.net (mail.thelounge.net [91.118.73.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 1 Dec 2020 12:13:29 -0800 (PST) Received: from srv-rhsoft.rhsoft.net (rh.vpn.thelounge.net [10.10.10.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) (Authenticated sender: h.reindl@thelounge.net) by mail.thelounge.net (THELOUNGE MTA) with ESMTPSA id 4CltZv2JLRzXVk; Tue, 1 Dec 2020 21:13:27 +0100 (CET) To: Stanislav Malyshev , internals@lists.php.net References: <3dd3c22d-0959-5425-46b1-dade4ac75b00@rhsoft.net> Organization: RH Software Message-ID: Date: Tue, 1 Dec 2020 21:13:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling From: harry@rhsoft.net ("Reindl Harald (privat)") Am 01.12.20 um 21:09 schrieb Stanislav Malyshev: >> we are running error_reporting E_ALL for 17 years now and don't >> distinct between notice / warning / error, it has to be fixed - >> period > > Surely you do. Your code continues to run after warning/notice but stops > after the error. It's impossible to ignore that. Unless you have an > error handler that does exit() after a notice (which I have hard time > believing, honestly, but who knows), there is a very major distinction. my server would trigger a mail every 15 minutes wioth all warnings and notices to enforce fixing the issue > It's not about what "has to be fixed" - it's not about the contents of > your bug tracking database - it's about the code that run one way and > suddenly now runs (or, rather, fails) in a fundamentally different way it should fail and it should have done that for 20 years because it points out missing input validation which is a much bigger probkem than a random exception seems to be but yeah, you are the guy closing security bugs all the time with no understanding what "fail eraly and fail safe" means in the context of security