Date: Fri, 12 Nov 2010 16:18:56 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: jumbo patch Makefile LDFLAGS modifications Till, Thank you for your work on the Fedora package of John the Ripper! On Wed, Nov 10, 2010 at 10:16:54PM +0100, Till Maas wrote: > the jumbo patch from > http://www.openwall.com/john/contrib/john-1.7.6-jumbo-7.diff.gz > contains the following change for Makefile: > > -LDFLAGS = -s $(OMPFLAGS) > +LDFLAGS = -s -L/usr/local/lib -L/usr/local/ssl/lib -lcrypto -lm $(OMPFLAGS) > > This interfers with packaging john for a distribution like Fedora, where > binaries are compiled with debuging information and stripped by the > build program (rpmbuild) to store the information in a debuginfo > package. Without the jumbo patch, the LDFLAGS can be simply overridden > with a redefinition of LDFLAGS on the make commandline. But with the > jumbo patch LDFLAGS does not contain only optional flags, but mandatory > flags like "-lcrypto -lm". OK, problem understood. > Can the jumbo patch please be modified to use > these mandatory directly in each supported target like e.g. the -lcrypt > flag for the linux-x86-64 target? No, that would complicate the Makefile and further updates to it. I might consider another approach, such as splitting out LIBS from LDFLAGS, to be implemented in the official JtR. Meanwhile, I suggest that you pass the entire LDFLAGS from your RPM spec file, including the mandatory libs. > An alternate solution would be to move the -s flag to some other > variable, e.g. OPTFLAGS and perform this change in the original john > Makefile: > -LDFLAGS = -s $(OMPFLAGS) > +OPTFLAGS = -s > +LDFLAGS = $(OPTFLAGS) $(OMPFLAGS) Yeah, this is closer to what I am thinking. Here are some other comments on the Fedora package: 1. Last time I checked, the package did not include an SSE2-enabled build on 32-bit x86 (.i386.rpm or the like). This needs to be corrected. The main "john" should be SSE2-enabled, with a possible runtime fallback to MMX and then further to plain 386. You can see this implemented in: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john.spec 2. You might have the temptation (and/or policy) to override John's CFLAGS with your distribution-wide ones. If you do so, please be sure to add -fomit-frame-pointer but omit/exclude any -fPIE you might have. Not including -fomit-frame-pointer or/and adding -fPIE has significant performance impact on JtR on 32-bit x86. -momit-leaf-frame-pointer is also fine, and unlike the full -fomit-frame-pointer it does not break backtraces, but this option is x86-specific (both %ix86 and x86_64). Better yet, simply don't override John's CFLAGS. 3. While it is a good idea to provide a jumbo-patched flavor of John, please do not make it the only one. Please make the official John available as well since it is more reliable for cases when the jumbo patch functionality is not required. 4. Similarly, it is a good idea to include an OpenMP-enabled build (Fedora's gcc is recent enough for that), but not make it the only one (because the thread-safe code is slower when running on a single CPU, as well as for some other reasons). Please note that none of the hashes added with the jumbo patch are OpenMP-parallelized yet, so maybe an OpenMP-enabled build is only needed for the official JtR (not jumbo). So this gives you a total of 3 user-invocable binaries (and maybe 9 total binaries). The 3 user-invocable ones may be called john, john-mp, and john-jumbo. Alternatively, they may be john (OpenMP-enabled), john-up, and john-jumbo. Or maybe reduce this to two: john (OpenMP and jumbo) and john-up (no OpenMP, no jumbo). In any case, the differences should be explained or at least mentioned in a README.Fedora file or the like, and maybe printed to the terminal from %post. 5. When building non-jumbo-patched JtR 1.7.6, please include the john-1.7.6-single-have_words-fix-1.diff.gz patch from: http://download.openwall.net/pub/projects/john/contrib/ (This patch is already merged into jumbo, and it will be in the next release of JtR. It is part of 126.96.36.199, which is currently in Owl.) Thanks, Alexander
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.