Hi! > "The salt parameter, if provided, will be used in place of an > auto-generated salt." This is setting someone up for failure by > letting them put in something weak, you should be forced to get an > auto-generated salt. If this is for unit testing then it should be > explicitly stated.
This assumes that we have the best salt generation algorithm that ever existed or could exist, and never would have any bugs or vulnerabilities in it. If it's not the case, it makes sense to let people provide their own salts in case they can generate better ones. > E_WARNING in a crypto function is also bad. Throw an exception or > fatal. There's no reason to just raise a warning and continue > execution, if something went wrong in crypto then its a bad time for > everyone. This means the function will be behaving differently than other PHP functions. Because it's crypto and very important, I understand. But then comes somebody else and says "my file functions are super-important too, whole application depends on them, why can't I have them work the same as crypto ones?", etc. Core should be consistent in its responses. Also, since the function returns false on failure, you can easily know something went wrong and throw exception/produce fatal error there if you wanted. Just like other functions - e.g. fopen() - do. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
