Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114526 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76947 invoked from network); 20 May 2021 04:50:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 May 2021 04:50:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CF0A01804B0 for ; Wed, 19 May 2021 22:00:10 -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,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 ; Wed, 19 May 2021 22:00:10 -0700 (PDT) Received: by mail-ed1-f51.google.com with SMTP id g7so5668215edm.4 for ; Wed, 19 May 2021 22:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cIqaKzy2eLwr28AgzHRMFeef6gEp+cDzMyoB5vo++pw=; b=m8y/GLIRcyjSvOhQb2g8KN6G8h1kCi7wwsEVI7gc+1eOUTgPrA2ZfKExtblrQvl+aO k1zwe+uVFGqZ5f0etz2pEjO67fUWzr5+P6TqJxElY3DNVhliSmqe2Qa+DJABCvnXRvE4 +0MjoO1CRRqXqAk59WyYJG+FqlhUd4t3YRR37p5KQCq6FKH3JH1jwa4+hUSZziXD1Vx0 SzydNIOqo4lB+fseszdWmUs9shjtK1o2cnoBCTasXi/lgRv6E/HvQbsUBg8hl2R85Az9 hPc6JyWkdvWPoqUbsMSBL1gpHduPVF9/HP7N6v8Ex4rXUm015Hr+WUNujGNDfvwIzrOm 4OGQ== 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; bh=cIqaKzy2eLwr28AgzHRMFeef6gEp+cDzMyoB5vo++pw=; b=VzJHrKKf0GPW1rrgUbF34hvi1M2bue+wFoYY7WlJYYU++90YvebFPvMPt9wDlBvJpn pSc9bruDm2/haF2hVpcop/hsHAsSpuriCV7dgG4iKcd+qFbJzHV7cEdYgSGx4OL2meSb SNE+r8zu5o/+AzufVf04HmcBR/83Lg5Xk/JZWxPV67IOSfLGNgTpVzJdGye0H00DxerK rdP6QKI1VvYTxFRh8qFymk82f04LAFznF7fl8ZZvl84EH62dLzGn4ZFlXoEeq5lZo2CS wE6Wj7FOACAYkHX2zN1k4qXBfXU0woGspk6Znqg9hgTP69Il4pZSUFtlu0O8B+yPKt0o w43A== X-Gm-Message-State: AOAM532+nyf/mW4r1lDIHLhLeU4gqjSx383Ah1ssdDEsmue5Q5b0Tjf/ cIH+6SoTT2MDfDM/JzIs2DRj6/2PeMglMuNmfuc= X-Google-Smtp-Source: ABdhPJwnSNFJyBcDIYeBaszi1Bj34nCAaLeDeDdGEpgLCNU3mSqdbnykey4TDjzqiDWc1XE4eSFloAtWKcSwsDMO7QY= X-Received: by 2002:aa7:dd10:: with SMTP id i16mr2942121edv.274.1621486809106; Wed, 19 May 2021 22:00:09 -0700 (PDT) MIME-Version: 1.0 References: <72767cd7-ffc5-c84b-523c-123ff6ef30fa@gmail.com> In-Reply-To: <72767cd7-ffc5-c84b-523c-123ff6ef30fa@gmail.com> Date: Thu, 20 May 2021 13:59:58 +0900 Message-ID: To: Rowan Tommins , PHP internals Content-Type: multipart/alternative; boundary="00000000000043d05205c2bbd1c3" Subject: Re: [PHP-DEV] [RFC] [Draft] Add RNG extension and deprecate mt_srand() From: zeriyoshi@gmail.com (Go Kudo) --00000000000043d05205c2bbd1c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. Deprecation will be done only to prevent unintended MT state dependent code. We don't plan to go as far as removing the implementation for now. > Firstly, making these functions independent of mt_srand() is a breaking change, so cannot happen until PHP 9.0 at the earliest. To be honest, I don't understand how far PHP is willing to go to accept disruptive changes. For example, `mt_rand()`, when called in its uninitialized state, was initialized using Combined LCG (time + PID/TID) before PHP 8.0. This can bias the results of `mt_rand()`, so I sent a PR on GitHub and it was changed to use `php_random_bytes()` if possible. https://github.com/php/php-src/pull/6520 It was in PHP 7.1 that the `shuffle()`, `str_shuffle()`, and `array_rand()` functions were changed to use MT-based random numbers instead of libc-derived random numbers. This was clearly disruptive, and left no way to even maintain backward compatibility. Compared to that, this proposal is not disruptive in the sense that it provides a complete alternative. 2021=E5=B9=B45=E6=9C=8819=E6=97=A5(=E6=B0=B4) 2:43 Rowan Tommins : > On 18/05/2021 17:19, Go Kudo wrote: > > I have created a draft of the RFC. > > > > https://wiki.php.net/rfc/rng_extension > > > Hi, > > At a glance, I think this looks like a good clear approach. > > I think deprecating mt_srand makes sense, but could do with a heading to > make sure it's not overlooked, and include a clear statement of when it > would be removed (9.0? 10.0?). It could potentially even be a separate > vote, as keeping it doesn't actually harm users of the new classes. > > > I have a few concerns with the third part of the proposal: > > > Also, change the following function to use the same method as > random_byte() (the php_random_bytes() internal function) for processing, > instead of PHP's global state. > > Firstly, making these functions independent of mt_srand() is a breaking > change, so cannot happen until PHP 9.0 at the earliest. This could > happen at the same time as mt_srand() is removed, but that connection > needs to be clear in the proposal. > > Secondly, it seems inconsistent to make these functions use the > crypto-strong randomness source, but retain rand() and mt_rand() using > PRNGs. In fact, I don't see the need to change them at all - they can be > documented as not for cryptographic use, as mt_rand is, and users > pointed to the new API if they need something stronger. > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --00000000000043d05205c2bbd1c3--