Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 12 Sep 2009 22:12:20 +0400
From: Solar Designer <>
Subject: Re: distro patches

Speaking of Gentoo's johntheripper-

On Thu, Sep 10, 2009 at 05:47:36AM -0600, RB wrote:
> It's called in the src_test stage that is turned off by default,

OK, so my guess was correct.

> and is actually bypassed if there aren't existing system-wide
> configuration files present from another installation.

That's very dirty.  Besides, it relied on "./john --test" returning a
non-zero exit code on any failed test, which was not the case until my
very recent changes for

While at it, I noticed that the ebuild uses "-fPIC -fPIE".  This is
probably part of a Gentoo policy, but the performance hit is hardly
desirable for John the Ripper.  Obviously, you need to benchmark it for
a make target and hash type where CFLAGS actually matter.  You won't
notice a difference for most officially supported hash types on 32-bit
x86 builds (due to the assembly code), but you should notice it for
some other hash types and other make targets.  In fact, even on 32-bit
x86 builds LM hashes may be affected somewhat (6.5% on my test build).

Then, do Gentoo's CFLAGS include -fomit-frame-pointer?  Probably not.
That's a further performance hit where it matters.

And just why is -funroll-loops omitted from OPT_NORMAL?

I've just tried making those three changes to a test build, and indeed
this hurt performance a bit.

In general, most distro packages of John I've seen so far override the
CFLAGS in a way that often results in worse performance.  This is not
just an arbitrary piece of software where the distro knows better; for
JtR, it's usually the other way around.  Why not just disregard the
policy and drop those overrides?  OK, it sometimes makes sense to add
things such as -march=..., but simply replacing all of CFLAGS with the
distro's is often a bad idea.

I guess I'll continue recommending custom builds over distro packages.

> >
> :)   I have a nightly script that tracks various OSS projects and
> syncs local copies of their SCM.  Since I read that summary email
> before this one, I was at least aware of the changes if not yet what
> they did.


> Thanks!  I'll re-base the patches off of those changes and submit them
> in the next round.

Would it be of any help if I release now?  (I guess so.)



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.