On 6/29/2012 4:23 AM, Stefan Fritsch wrote: > > Therefore I will go ahead and add bcrypt support to apr-util which > will be a big improvement for the 95% of users who don't need FIPS.
It sounds to me that after we spent a great deal of time to make APR largely library agnostic, you are insisting on binding us to a specific library. I would be very hostile to that. If you are talking about a plugable, client-agnostic approach which the user can ignore the details of how apr was built, that would be fine. Before throwing code at APR, please post a patch, because the group might largely be in agreement. The delta to configure.in and the headers is probably sufficient for now. But if your solution is to add more mandatory dependencies or make apr less flexible, it would be met with resistance. The user should remain largely oblivious whether the pw crypt used lives in bcrypt or openssl or the kernel, and the resulting pw data should be always portable between different builds of apr. This was the logic behind the sha1, md5 and other common password schemes. The crypt scheme was an exception, one which can be resolved even on win32 and hpux with the use of openssl's crypt implementation or linking to fcrypt. Platform or library binding dependent pw data takes us back to 1999.
