> This change should go through the standard RFC process and should be
> targeted at 7.2+ (master) *only*.
> Please check with the RMs before merging functionality changes into
> branches. All functionality changes need consent and consensus. Bug fixes
> (that don't change functionality or break BC) do not.
You were told very specifically that the kinds of changes you proposed here
require an RFC.
You chose to ignore that, and merge an implementation into frozen branches
I have reverted this change.
Do not do that again.
On Tue, Oct 18, 2016 at 8:35 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> On Tue, Oct 18, 2016 at 4:16 PM, Niklas Keller <m...@kelunik.com> wrote:
> > Yasuo Ohgaki <yohg...@ohgaki.net> schrieb am Di., 18. Okt. 2016, 08:47:
> >> Hi Niklas,
> >> On Tue, Oct 18, 2016 at 3:36 PM, Niklas Keller <m...@kelunik.com> wrote:
> >> > Yasuo Ohgaki <yohg...@ohgaki.net> schrieb am Di., 18. Okt. 2016,
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I committed this patch that simply use php_random_bytes() w/o any BC.
> >> >
> >> >
> >> > Doesn't this throw now in some environments where /dev/urandom isn't
> >> > readable?
> >> It could happen, but such system should not be used now a days.
> > Sure, but it did happen that shared hosts block it, noticed during
> > random_compat adoption.
> > You claimed there isn't any BC break.
> The line should be
> "There is no BC for usable systems"
> Any file permission could disturb PHP script execution, couldn't it?
> I think it's nothing special for /dev/urandom. User should set up system
> correctly to use PHP. Then there is no BC at all.
> Yasuo Ohgaki
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php