[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Nov 2010 21:15:04 +0100
From: Till Maas <opensource@...l.name>
To: john-users@...ts.openwall.com
Subject: Re: jumbo patch Makefile LDFLAGS modifications
On Fri, Nov 12, 2010 at 04:18:56PM +0300, Solar Designer wrote:
> Thank you for your work on the Fedora package of John the Ripper!
You are welcome. Thank you for having written it!
> 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.
This would be great.
> 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
Ah, I did not know about this. I will update the SPEC to make use of
this.
> 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.
I will have to check with the Fedora Guidelines. The current optflags
that are mandatory are these:
x86_64:
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
x86:
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables
> 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.
What do you think about adding some code to john to allow having several
binaries with several feature sets similar to the different binaries for
different CPU optimizations with the fall-back mechanism. E.g. the john
binary would have all patches and based on hash to be cracked and
the amount of CPUs it uses the john-plain or john-up-jumbo binary. Then
the user only needs to run john and there would not be any diversion
between distributions, if other distributions provide patched versions,
too.
> 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 1.7.6.1, which is currently in Owl.)
Ok.
Regards
Till
Content of type "application/pgp-signature" skipped
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.
