Pierre, >> I know you didn't like PASSWORD_MOST_SECURE. So what about keeping >> PASSWORD_DEFAULT as a moving target, documented, and just making the >> second parameter (algo) to password_hash required? That way users >> could choose between PASSWORD_BCRYPT and PASSWORD_DEFAULT. >> >> That way, over time, PASSWORD_DEFAULT could be updated, and it would >> be documented that it would change. But it would require them to >> understand that it could change... >> >> Would that satisfy your issues? > > Yes. > > Using this constant name and clearly document its changing nature is > fine. The argument being required fully solves my worry about optional > argument with changing default value.
I've implemented this in my branch. I've also updated the RFC to indicate such (we may want to expand it a little bit, but it should suffice for now). I've also added a bit to the RFC about a policy for updating the default constant over time. (Indicating for a non-security release, changing the default must be done via an RFC, how long the algorithm must be available before being eligible for default, etc). > Thanks for your efforts and work! Absolutely! Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
