Date: Fri, 12 Apr 2013 16:26:44 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: jumbo pull request #255 (trouble with static builds) From: Solar Designer [mailto:solar@...nwall.com] >> this is one of two possible fixes, the alternative is that a proper >> check for an installed openssl is done (or the user can choose) and if >> so add both -DHAVE_OPENSSL to CFLAGS and -lssl -lcrypto to LDFLAGS. > >A better fix may be to rename our interfaces and thus avoid the clash with OpenSSL's. As an option, we could add >some #define's renaming the interfaces (e.g. adding leading "john_") to the start of md.h. We already use >this approach for "int64". This was the approach I did with the sha2.c code, the 'generic' work around code, for older versions of oSSL, which did not implement sha2 functions. The 'official' oSSL name is SHA512_CTX. Mine is sha512_ctx, and there is a #define making SHA512_CTX when used in code work just fine. I have a function called sha512_init(x), and there is a #define that allows a normal looking call to SHA512_Init(x) (the proper oSSL interface), to simply call my function. Yup, it probably would have been better to simply use something like jtr_SHA512_Init(x) as my sha2 function interface, and then properly define SHA512_Init(x) to use that function. In hind sight, I should have coded them that way, but did not. However, the code using unique external names is MUCH easier to use, avoiding linkage issues like this completely. That was one of the uglier things, which I did not fully grasp, when I started working on JtR. You can still see the confusion within the dynamic stuff. It really should not take all that much, to change the internal md4/5 and sha1 scalar to have their own unique external names, and then make the header files do the #define magic to hide these modifications from end users. Then if the end user simply does #include "md5.h" vs #include <openssl/md5.h>, then the build environment could be smart enough to know when to use ossl, and when not to. One thing you get in some builds of JtR, is the MD5_X2, SHA1_X2, etc, which can make things MUCH faster than oSSL on some platforms. So it is not simply the initial 'clearing' and post final clearing that is saved with internal JtR hash code. Note, the 2x DOES break the oSSL interfaces anyway. Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.