Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 13 Jan 2015 05:41:25 +0000
From: Dominyk Tiller <>
To: Solar Designer <>
Subject: Re: Bug Report

Hi Alexander,

Apologies, I did actually intend to send it to that list but mistyped. I
apologise the subject was not as helpful as you would otherwise desire.

I suspect most people packaging JtR are just trying to package it in a
way that works consistently and is easy for anyone to maintain, not just
those with specific knowledge. That's perhaps the problem; package
managers by their nature often allow contributions from people other
than the original maintainer, otherwise said package would eventually
cease to be updated entirely and that's a whole other problem.

I appreciate the helpful link, and will endeavour to fix the issue more
successfully in future consequently. I do a little shell scripting, but
certainly, my C to put it bluntly, sucks.

Thanks for the reply, and your time,


Sent from OS X. If you wish to communicate more securely my PGP Public
Key is 0x872524db9d74326c.

On 13/01/2015 05:27, Solar Designer wrote:
> Hi Dominyk,
> I think your posting would have been more appropriate on the john-users
> list, and a better Subject would have been e.g. "system-wide install".
> You could want to do something like that for further problem reports, if
> any (unrelated to this one).  Since you've already brought this up on
> john-dev, let's keep this one thread in here.
> On Tue, Jan 13, 2015 at 01:49:56AM +0000, Dominyk Tiller wrote:
>> I've been trying to chase up this bug for a fair while now. It's not a
>> new bug report by any means, It's been around for years now. You can see
>> a bit of a summary on the Jumbo Github issue I created here:
> Basically, a lot of people who package JtR are not that experienced with
> shell escaping and with C.  Maybe we need some documentation to explain
> these things (even though they're not specific to JtR) or an example.
> When you override a pathname with a C preprocessor macro, you need to
> put the new pathname in double-quotes (to make it a valid C string), and
> further you need to escape those double-quotes to pass them via the
> shell.  Here's how it's been working fine for me for years:
> I am not overriding the default JOHN_SYSTEMWIDE_EXEC here, but I am
> providing CPU_FALLBACK_BINARY, which demonstrates the same issue and the
> same solution that you would use for JOHN_SYSTEMWIDE_EXEC.  Here are
> some of the relevant lines:
> FALLBACK='\"john-avx\"'
> %__make linux-x86-xop CFLAGS="%cflags -DCPU_FALLBACK=1 -DCPU_FALLBACK_BINARY='$FALLBACK'"
> Alternatively, we could use the C preprocessor's stringification feature
> to eliminate the need for external string quoting (but then we depend on
> an extra feature for "no good reason", which might break builds on some
> older/exotic systems):
>> Essentially, params.h has a note in it to not patch the file but use
>> cflags to set JOHN_SYSTEMWIDE_EXEC, but doing so causes a fairly massive
>> compile breakage:
> ... because you do it wrongly, which is in turn because this stuff is
> non-trivial for someone who is not into shell scripting and C
> programming.
>> So despite the file saying not to patch it, it seems patching it is the
>> only way to set the directories.
> Not true.
> Thank you for trying to help, and I hope this explanation helps.
> 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.