On Sunday 01 July 2012, William A. Rowe Jr. wrote: > 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. >
No. As I have mentioned in one of the other mails, I prefer importing a suitably licensed version of the source code. What I currently have is http://people.apache.org/~sf/apr_bcrypt_password_support.diff diffstat: build.conf | 2 crypto/apr_md5.c | 145 ------- crypto/apr_passwd.c | 196 ++++++++++ crypto/crypt_blowfish.c | 902 ++++++++++++++++++++++++++++++++++++++ crypto/crypt_blowfish.h | 27 + include/apr_md5.h | 5 > 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. No new dependency, no configure.in change. Instead I add two files from the crypt_blowfish distribution. I intend to make some benchmarks with the assembler version, but it says it was written for Pentium 1, so I am not so sure that it will greatly improve performance on current processors. If it is actually significantly faster than the pure C version, I would add it plus the necessary build logic. That would mean one additional file (there is only an assembler version for i386). The diff of crypt_blowfish.c versus upstream is one line. So importing new versions if there happen to be any upgrades should be easy. > > 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. Yes. That's why I was sceptical about using apr_crypto for this task, too. After all, apr_crypto is still optional. Cheers, Stefan
