Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107776 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 20323 invoked from network); 6 Nov 2019 21:54:51 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 6 Nov 2019 21:54:51 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 4B8F32D1F9D for ; Wed, 6 Nov 2019 11:44:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Wed, 6 Nov 2019 11:44:33 -0800 (PST) Received: by mail-qk1-f171.google.com with SMTP id m125so25711518qkd.8 for ; Wed, 06 Nov 2019 11:44:33 -0800 (PST) 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=hA3Q7pUJyODN7y7U5xyp0cbNW+MOLMFQNR8BsN2ESVU=; b=ODr8K48yuONMLStKEva5q/U++Jz5GIBcKVFGqdGyPPsHFq3CR8IS4gXGngLMq8cEPN UgNkHO0eHE1N6NqmwSA/ckPDJ+A1qMvgJSRpToD42a5TFwcas8pvC9+gybGFy1iHrDc6 YLUiOjblzBOrNWfo/rPfW/08NIIe/vl1YEB3lISGz5bd2BK6HmnLNa61Bka7G0kDmiJB f4PTIRZ8KTyYtfHZWp933MRTkibZlEgElfPxw8EqqVQiIXlVCYEDB9pNYUWjAS397IDR 6eM34Qofw2CJVArZHtCn5Dj5dqep5AZn0U5LU6Djl9W6lNToKMDu8ry+yIYRPGsnF95U zvnQ== X-Gm-Message-State: APjAAAWZPaQQZ49x+adV8WytxAk9A6UaLrVKuF70RXPeDIdgskbiO0Be u5Xs3nseVD14Jnr69QMFlq2gSZB4t9byhkWpbtY= X-Google-Smtp-Source: APXvYqx9oQ4tgp8Ecq6owJ84BW/voGdjlFjo4J4X7NihRihl+Ard0qNAfJ+XfZiRFJl0HxZ45wavvwIKhnU9aGiNL3E= X-Received: by 2002:a37:6105:: with SMTP id v5mr3900675qkb.40.1573069473027; Wed, 06 Nov 2019 11:44:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 6 Nov 2019 19:44:22 +0000 Message-ID: To: Nikita Popov Cc: Christian Schneider , PHP internals list Content-Type: multipart/alternative; boundary="000000000000259ca20596b2c7d2" X-Envelope-From: Subject: Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes() From: bukka@php.net (Jakub Zelenka) --000000000000259ca20596b2c7d2 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 30, 2019 at 6:33 PM Jakub Zelenka wrote: > > > On Wed, 30 Oct 2019, 18:32 Jakub Zelenka, wrote: > >> >> >> On Mon, 23 Sep 2019, 14:02 Nikita Popov, wrote: >> >>> On Mon, Sep 23, 2019 at 2:52 PM Christian Schneider < >>> cschneid@cschneid.com> >>> wrote: >>> >>> > Hi, >>> > I just noted (too late in the process, I know) that >>> > openssl_random_pseudo_bytes(0) now throws an exception. >>> > >>> > This breaks code like >>> > $ivsize = openssl_cipher_iv_length($method); >>> > $iv = openssl_random_pseudo_bytes($ivsize); >>> > $data = openssl_encrypt($string, $method, $key, >>> OPENSSL_RAW_DATA, >>> > $iv); >>> > if $method is 'aes-256-ecb' because $ivsize is 0. >>> > >>> > I do realize that ECB mode ciphers are deprecated but having them >>> throw an >>> > exception indirectly via openssl_random_pseudo_bytes() seems a bit >>> strange, >>> > even in the context of security. >>> > >>> > I checked the RFC >>> > https://wiki.php.net/rfc/improve-openssl-random-pseudo-bytes and it >>> > doesn't mention this BC break: >>> > "False-checks on the return value of openssl_random_pseudo_bytes() >>> will do >>> > nothing since the function fails closed. Usage of $crypto_strongwill >>> > generate errors." >>> > >>> > While I would have preferred the exception to be thrown only when >>> $ivsize >>> > is not an integer or less than 0 but I guess this cannot be changed at >>> the >>> > RC stage. >>> > >>> > I would recommend though that we aim to keep BC breaks to what's >>> mentioned >>> > in RFCs. >>> > >>> >>> This was noted during the PR review in: >>> https://github.com/php/php-src/pull/3649#discussion_r230598754 >>> Especially >>> in conjunction with your example, I think we should revert this part an >>> make openssl_random_pseudo_bytes(0) return "" without exception or >>> warning. >>> Ideally we'd adjust random_bytes() to do the same. >>> >> >> I agree this should be reverted for 7.4 at least as it's a BC and wasn't >> really in RFC. It really doesn't matter if it's a good thing or not as it's >> a BC that we shouldn't do in minor release. >> > > I mean BC break ofc... :) > I was thinking about the revert but after reading the RFC again, I don't think it would be right thing to do. Although it's a bit generic and doesn't mention when it can fail, it states that the exception is thrown on fail. We always considered this case as a fail because it returned false so it's kind of covered. It would be also quite late to do such changes in 7.4 and I guess RM wouldn't allow it anyway. It's basically BC break that went through the RFC which is probably acceptable. I have to say that the RFC wasn't really well done as the implementation followed which caused this omission. We should really look properly to the implementation when creating RFC so it's more detailed and doesn't cause omission like this. Cheers Jakub --000000000000259ca20596b2c7d2--