[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 7 Aug 2016 11:58:50 -0400
From: Rich Rumble <richrumble@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: JtR homepage update; Windows builds
On Sun, Aug 7, 2016 at 10:54 AM, Solar Designer <solar@...nwall.com> wrote:
> On Sun, Aug 07, 2016 at 09:09:59AM -0500, jfoug wrote:
>> I feel that propagation of 'DOS' line endings is a very bad thing. Also,
>> renaming to a
>> .txt file, that is probably very questionable also. Why do you want
>> to do that?
>
> I am not sufficiently familiar with modern Windows (except for making
> these builds and doing other occasional little things, I don't use
> Windows), which is why I ask in here. My understanding is that there's
> still a notion of "filename extensions", even though multiple ones are
> allowed now, and the last one affects file associations, so that you'd
> be offered to view a .txt file as a text file when clicked, and having
> DOS line endings it would display correctly in whatever app Windows will
> launch for this (notepad or the like). Are you saying that
> "extension-less" files that just happen to be text, and with Unix line
> endings, work just as well these days in Windows file managers and text
> file viewers? My guess was that it'd vary across systems/settings and
> user habits (different file managers in use, etc.)
As a avid windows+JtR user, I like the proposed changes. Windows
doesn't have a text reader/editor for the CMD line. Most of windows is
GUI, powershell is changing that, but I've never seen anyone "vi" in
powershell. The file extenstions are a great idea. The Unix2Dos
conversion/line endings are necessary if the OS defaults to Notepad
(it still does, and alternate endings still aren't properly
understood) by that one program. Wordpad, MS Word, Notepad++ etc...
those have no issues with D or U line endings. But for some dumb
reason, Notepad still can't handle it.
I would have done these vary changes to my own contributed builds, but
I thought they may have been frowned on by *nix users. I've seen
something similar happen to Snort, which offers windows builds, but
uses the /etc/this/n/that directory structure rather than
c:\snort\something\something file structure in the Snort.conf. If the
configure script or make process would launch something to change
these file extenstions to .txt (which removes any ambiguity, from any
OS what is contained within) I'm all for it.
>> This is not dos any more, it is Windows and CMD. There is no need for
>> line endings
>> for sure, which will cause invalid files, that will likely make their
>> way back into the
>> code base, to only have to be changed. In no way should script files be
>> converted.
>
> OK, so you feel strongly against line endings conversion for scripts.
Again I've used wrappers for some python scripts in my contributed
builds because most of the 2john scripts are very useful and it's hard
for most casual users to know how to download needed python/ruby/perl
packages just to extract the hash they need from a 7zip file. The line
endings for scripts I don't feel need changed to CRLF.
> What about the documentation files? The config files?
.conf doesn't default to anything in windows, you're asked to choose
an editor/viewer, if you chose Notepad it would not render properly.
Just about any other editor will know better however.
> Related: IIRC, Cygwin offers to enable line endings conversion when you
> install it, and this probably affects files such as john.pot and
> john.log. Don't we want them to have DOS line endings? I think that's
> how it has been in the Windows builds of JtR I've been making years ago,
> and is probably still the same in this latest build.
>
>> Also, basing windows build on 64 bit is probably the right way to go, as
>> long as
>> there is a 32 bit build that can be downloaded.
>
> I agree. We definitely need to produce an official 64-bit Windows build
> for the next jumbo release.
>
> 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.
