Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Nov 2010 16:18:56 +0300
From: Solar Designer <>
Subject: Re: jumbo patch Makefile LDFLAGS modifications


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
> contains the following change for Makefile:
> +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:
> +OPTFLAGS = -s

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:

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:
(This patch is already merged into jumbo, and it will be in the next
release of JtR.  It is part of, which is currently in Owl.)



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.