2015-08-01 1:43 GMT+02:00 Yasuo Ohgaki <yohg...@ohgaki.net>: > Hi Niklas, > > On Sat, Aug 1, 2015 at 8:27 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> They should totally be handled. You need to catch the error and throw a >>> defined exception, otherwise your public API will break if you choose to >>> use another internal implementation. >>> Additionally, you seem to assume that the library doesn't have to do >>> things like cleanups in such a case. >>> >> >> My thought is based on Design by Contract (Contract programming). >> When parameter or environment does not satisfy contract, contract error >> should be >> resulted in program/process termination. >> >> Fixing inappropriate parameter or environment is not library/framework >> author's >> responsibility, but the developer's. i.e. >> Caller(function/programmer/system admin) >> has the responsibility that satisfies parameter/environment requirement. >> If >> requirement is not met, it's perfectly OK for library/framework to raise >> fatal >> errors/exceptions. e.g. "You need PHP 5.6 or greater" error. >> > > I'll be more specific for "CSPRNG not available" error. > > If a author would like to handle the error and fallback to non crypt safe > RNG, > he/she should detect environment and execute alternative code for the > environment. >
Hi Yasuo, You always assume the developer just wants to fallback to something different. You can't detect the environment btw. because it could just fail because of too many open file descriptors. > Catching exception and fallback to non crypt safe RNG is not optimal way > for handling unsatisfactory environment. IMHO. If we need function that > checks > environment, we are better to provide one rather than let users to use > exception. > This is damn insecure and far away from "not optimal". As said, checking the environment before executing the function isn't safe, and no, exceptions would always be the better way here. Regards, Niklas > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > >
