Date: Tue, 13 Jan 2015 05:41:25 +0000 From: Dominyk Tiller <dominyktiller@...il.com> To: Solar Designer <solar@...nwall.com> CC: john-dev@...ts.openwall.com 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, Dom 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: >> 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.