Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 07:16:49 +0400
From: Solar Designer <>
Subject: install types (was: John the Ripper 1.7.9-jumbo-6)

On Fri, Jul 06, 2012 at 07:07:16PM +0200, Frank Dittrich wrote:
> Meanwhile someone who apparently downloaded the windows .zip file
> complained about the lack of separation between user data and programs,
> the developers apparently "still living in the DOS era", because even
> the tutorial suggests to store config files and log files in the same
> directory as the program files.

Personally, I find this just convenient, and I am unhappy when other
tools unnecessarily force me to install them system-wide or to resort to
hacks to run them without installing.

> I don't know the Windows build. Would it be possible to alternatively
> provide a Windows build with JOHN_SYSTEMWIDE set?

As this shouldn't become the only new CLI build available, I think it'd
be very confusing (two CLI builds with different usage instructions).

Speaking of packaged builds of John, currently most Linux and *BSD
packages, including JtR Pro for Linux, do make use of JOHN_SYSTEMWIDE -
but that's in part because the package managers are such that they'd
only do system-wide installs reasonably.

JtR Pro for Mac OS X installs into the user's home directory, a feature
available starting with Mac OS X 10.5 (so that's the minimum version
supported currently) - yes, with the program and config files in the
same directory, but like I said this is just convenient for JtR in
particular, in my opinion. :-)

We don't currently have a native package for Windows.  All we have is a
.zip archive.  As long as this is how we distribute John for Windows, I
think it should use the current approach with doc and run directories.

When we have a package with some kind of installer, I guess what we do
may depend on the installer's capabilities.  Personally, I see little
need to install JtR on Windows system-wide - on the contrary, I think
installs local to the current account should be preferable - and in that
case I see no benefit from separating the program and data.

Another issue is that on Windows Vista and newer, UAC may be getting in
the way, unnecessarily making the installer run with administrator
privileges.  I am not familiar with Windows at all, but from what I read
a while ago this is triggered by typical installer filenames.  So we'd
have to either avoid those or bite the bullet and maybe actually do
system-wide installs.  What's the point in using administrator
privileges along with making a user-local install?  Maybe there's some
weird Windows reason for that combination?

...Oh, maybe privilege elevation can also be avoided with a manifest:

(although apparently it's normally used for the opposite thing).



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.