[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120823091021.GG15190@openwall.com>
Date: Thu, 23 Aug 2012 13:10:21 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: make install (was: Johnny 1.1, the GUI for John the Ripper)
On Wed, Aug 22, 2012 at 02:24:10PM -0400, Rick Zero_Chaos Farina wrote:
> Really? What is is with password crackers with not wanting to be
> installed? john doesn't like being installed, hashcat doesn't like being
> installed, cryptohaze doesn't like being installed... it can't just be
> me that sees this as an issue can it?
"make install" for a password cracker is primarily useful for distros'
packages. However, at least for John the Ripper (I can't speak of the
others) something trivial like that, if it were supported in the obvious
way, would usually not be the best thing a package can do anyway. For
example, Owl's package of John the Ripper builds as many as 10 separate
binaries on 32-bit x86 (and 6 on x86-64), enabling the various runtime
fallbacks (e.g., XOP -> AVX -> SSE2 when running on a CPU only capable
of SSE2, and OpenMP -> non-OpenMP when the thread count would be 1 and
thus the non-thread-safe code would likely be faster). It places the
transparent fallback binaries in /usr/libexec/john. I'm not sure if
it'd be good for a "make install" to include such distro-specific things
in it or not, whereas without those it'd be of relatively little use (a
smart package would need to do better anyway).
That's for the core tree and CPUs only. When we add non-jumbo vs.
jumbo, CUDA and OpenCL vs. not, we get even more binaries. Indeed, a
package could choose to build jumbo with both CUDA and OpenCL only, and
it might even be OK for a distro that always provides the prerequisites
(BackTrack maybe?)
Maybe Gentoo is a special case here, since on one hand it uses packages,
but on the other those are commonly tuned for the specific system (thereby
reducing the need for having multiple alternative binaries in one package).
Also, what should "make install" do if John the Ripper was not built for
system-wide install? Should it include a check for that and refuse to
work if so (suggesting how to rebuild for system-wide install)? Maybe.
Without this check, we'd annoy a lot of people (they build, install, and
then see John fail to work). As to possibly making builds for
system-wide install the default, I'd rather not, because I find it most
convenient to use John without installing. I think that's how most
"pro" users use it (and will continue doing so), whereas the system-wide
mode is primarily for distros, and the inclusion of John the Ripper in
distros is primarily to make people aware of it and for casual uses.
That said, I might in fact add a "make install" in 1.8+. I just need to
decide on how to approach these issues.
For Johnny (as it is), implementing "make install" should be trivial.
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.
