|
Message-ID: <20120707031649.GC24409@openwall.com> Date: Sat, 7 Jul 2012 07:16:49 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com 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: http://en.wikipedia.org/wiki/User_Account_Control#Requesting_elevation (although apparently it's normally used for the opposite thing). Thanks, 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.