Hi, On Sat, Jan 21, 2017 at 11:12 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä <lauri.ken...@gmail.com> > wrote: > >> On 2017-01-19 13:46, Yasuo Ohgaki wrote: >> >>> However, PHP as a whole cannot work reliable way w/o CSPRNG and >>> today's >>> standard requires working CSPRNG, doesn't it? >>> >> >> No. >> >> Why do you think that PHP can't work without CSPRNG? >> >> PHP is a general-purpose programming language. It can be used in a closed >> environment, even on machines without any network. CSPRNG is not required >> and should not be required. > > > When things failed, program should fail properly. > There are number of examples that failed to make thing secure enough. e.g. > SSL > > > On Thu, Jan 19, 2017 at 11:14 PM, Leigh <lei...@gmail.com> wrote: > >> >> Everyone who cares about stability. >> >> I agree, if you want to introduce breaking changes, this needs to go to >> RFC. >> >> Therefore the simplest option seems to be DON'T introduce breaking >> changes. Wouldn't you agree? > > > The nature of MT rand is non CSPRNG, so I don't mind to much about the > fallback. I'm just uncomfortable with not following the "When things > failed, program should fail properly" principle. Not following this > principle caused unexpected results in many softwares. This specific case > does not matter much, though. > > Anyway, unusable CSPRNG is very unlikely to happen. I may just use > UNEXPECTED macro for the if branch. > I changed my mind due to comment for uniqid() CSPRNG usage. IMO, there is no benefit for CSPRNG failure fallback. We shouldn't add fackback for every CSPRNG usage. It's just does not make sense. Are we going to add poor fallbacks for every CSPRNG usage? I strongly against it. CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't fail with healthy hardware/OS. Therefore, we should not add poor fallback code for it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
