Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118605 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28712 invoked from network); 11 Sep 2022 04:35:24 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Sep 2022 04:35:24 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 15D8F1804AC for ; Sat, 10 Sep 2022 21:35:24 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 10 Sep 2022 21:35:20 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id b23so4401446iof.2 for ; Sat, 10 Sep 2022 21:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date; bh=i8IyMidaOxmGQ/NvW+h21OcFY38uS0Si0BJX7ucr/U4=; b=JlIxEAt+xEo+NMd1UgwbGD8djWQJhuAx09JhX9BnE3QwJb77IaTz43D+or1o497W3V iVs6FN+1UkjRo/hxnhRGVSLed1u8ZGNDhGddRGZd3jszLwtzB0woTP3YyThHQRjjkNkv 0mi9pYdMmifDPkUPx2G19L+7ZZieYt+DcnYKDyQPokO8DAbzQj9aImjJplNkNHFk0g3i EM6JdR8sd+XgpFhzoCPRnLXFPpmWUc1NjsadWttfd14c6Q2rybtvTpm+SZW3uo/mBjyM u1gePORlBDY1qhnp1K4ctZhDhi6ZCYXLTXmFGnh6j4HdTszIbGkFFAheK+G4ENnnXdhD vSbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=i8IyMidaOxmGQ/NvW+h21OcFY38uS0Si0BJX7ucr/U4=; b=jbM+Ez7dUOdHt+xs5k9vZ0y/zGOpqj3Q/aj0/b4e2cj4Aoj3cmyNClSpjzZnng9SkZ b1B5npR8Ri8h/tFNiS6PysuPr0wqpwqc5CVkKCGgM6PKPH+0+yBQMS4mwo2u5vKpekjX Pm3ZX7pMJ56PY4qQLRZETC0/qs4IQTEzFxO6JXxGjnJjtTPiPxwkTdN7dABWwO2Wg85H NC0Pccb3Iq85iWgEOLD+3GkwMaGaSgxOFBMrABC8t5H0m2LT+jUehfxgeKw6vf7+0DiH 4fa4tOSmva3RX8O5JLT3e9j3OVkc24Z77Mjgwds9ZSXwCTROD5Se6yCCQjunWrxZk+nV 1OgA== X-Gm-Message-State: ACgBeo09huyi8gmvbBFAJ7NkxlAOcnw+ia4vsw+i/r39s9jIN3DRsM9N wEwgtLYXGr0gV3BFDQ1RVDGv6Kdgm7UKXoI9mt4= X-Google-Smtp-Source: AA6agR6J5pddpAAwFGgBE02IxWe+YpSq4hpW/nAq2BD0U0acslxv5zafFWVdheN286p+Q3d7lYf2lAKYb5u1BXA5vV4= X-Received: by 2002:a02:3c12:0:b0:34a:1d2f:6b5a with SMTP id m18-20020a023c12000000b0034a1d2f6b5amr10558017jaa.173.1662870919743; Sat, 10 Sep 2022 21:35:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6e04:c8c:0:0:0:0 with HTTP; Sat, 10 Sep 2022 21:35:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Sep 2022 09:35:19 +0500 Message-ID: To: Yasuo Ohgaki Cc: David Gebler , juan carlos morales , Peter Kokot , Misha , internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte From: office.hamzaahmad@gmail.com (Hamza Ahmad) > We spend a lot of time to increase limits for uploads file in PHP. For a lot of time, I assume you are using a web host that does not allow modification to INI file directly or using INI functions, and you have to contact your host provider for that change. Otherwise, it is not that difficult to apply that change. Plus, this question would have been answered in a php forum, like phpearth. > I'm not against increasing the sizes, but 50MB might be too much. It is possible on userland as well as configuration level. I don't feel like it is worth doing. It will break some websites. Most of the projects go with default options of upload; thus, doing so will make issues for such projects. > By the Way... This needs an RFC right? This change should be made with an rfc. Because it will impact a majority of projects, and usually devs doant have to have that huge limit. Plus, there are razed further concerns that On 9/10/22, Yasuo Ohgaki wrote: > 2022=E5=B9=B49=E6=9C=8810=E6=97=A5(=E5=9C=9F) 23:23 David Gebler : > >> On Sat, Sep 10, 2022 at 3:05 PM juan carlos morales < >> dev.juan.morales@gmail.com> wrote: >> >>> I also agree that increasing the size to something bigger than 8M >>> might not be a good idea; I can imagine that a value bigger than 8M >>> (like 50M) will cause an impact in hosting platforms specially, which >>> will be forced to always change the php's default values to a lower >>> one, because of potential DoS Attacks. >>> >>> Default settings should have a reasonable level of security in mind. >>> >> >> Do these settings actually have any impact in respect of DoS attacks? As >> far as I'm aware, neither post_max_size nor upload_max_filesize do >> anything >> to prevent or terminate processes where the client sends data exceeding >> these limits, that's something you should handle in your webserver. >> > > For example, password hash DoS attack was made possible because PHP allo= ws > 8MB post data. > > https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-serv= ice/ > > IIRC, Drupal has a security release for this. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >