Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107734 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34738 invoked from network); 30 Oct 2019 20:44:51 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 30 Oct 2019 20:44:51 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 621762CC68B for ; Wed, 30 Oct 2019 11:32:48 -0700 (PDT) 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: No Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) (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, 30 Oct 2019 11:32:45 -0700 (PDT) Received: by mail-qk1-f194.google.com with SMTP id q70so3770371qke.12 for ; Wed, 30 Oct 2019 11:32:44 -0700 (PDT) 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=2qdiTWWaIOSNWy2jtUr9dQMS5fjBXzcny7D5QXM9jwE=; b=Tmtku8zSHrdCBBFrSnPPVHZgvxMyJ+wTwcVdquqBwKgAi+PIdnvNGb7hjLbxxVtYoy Y1Q1LqrUWAy3a5HM9/7lGWL25brIIbAq6RlCXqJNnOH2J5DUEL2T7PusloOfhCIDdmMA tZ/Q2oyG/p9qzC4W5ViG69wU7P+N+nyK3suNfc36CDNyILphkeizEMkmtFDCdXg4pY4w /1+2hBw3gJ2SSfBwgPVh1t6bs9/s/WCOORQN8q4IyGaaIoJ5FK/6MfjTnLWGNVsOXPEp ZQCFXGZBa8DSJx4IinULLKs9BanheJWO32i4TPgVn6jqukLrXnBxeGQCo5E2PrZ4tGr7 OKwg== X-Gm-Message-State: APjAAAXQwHkl9RkoYwCoVfLbjuJER6AJffHjAmZkmQ1ICTg+zewX8Nr+ ny5SSN/8lAV7ZPPNc0iWbwAzxDV1wAm+hnWk+BA9XQ== X-Google-Smtp-Source: APXvYqwDXjjGtLvTg211CCT+3IA1EcbWPkI+AEfnMSTfjh8hSmOjL6cp9G/IFDXN3yXekT1YciP5U4m2SbcdLyCh2r4= X-Received: by 2002:a37:9207:: with SMTP id u7mr1497729qkd.84.1572460364119; Wed, 30 Oct 2019 11:32:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 30 Oct 2019 18:32:32 +0000 Message-ID: To: Nikita Popov Cc: Christian Schneider , PHP internals list Content-Type: multipart/alternative; boundary="0000000000006d4472059624f58b" X-Envelope-From: Subject: Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes() From: bukka@php.net (Jakub Zelenka) --0000000000006d4472059624f58b Content-Type: text/plain; charset="UTF-8" On Mon, 23 Sep 2019, 14:02 Nikita Popov, wrote: > On Mon, Sep 23, 2019 at 2:52 PM Christian Schneider > > 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. Jakub > --0000000000006d4472059624f58b--