[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150113052700.GA9021@openwall.com>
Date: Tue, 13 Jan 2015 08:27:00 +0300
From: Solar Designer <solar@...nwall.com>
To: Dominyk Tiller <dominyktiller@...il.com>
Cc: john-dev@...ts.openwall.com
Subject: Re: Bug Report
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:
> https://github.com/magnumripper/JohnTheRipper/issues/982
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:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john.spec?rev=HEAD
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):
https://gcc.gnu.org/onlinedocs/cpp/Stringification.html#Stringification
> 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.
