Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 May 2015 21:57:55 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [john-core] Getting John's stdout unbuffered for Johnny


> On May 27, 2015, at 9:26 PM, Frank Dittrich <frank.dittrich@...lbox.org> wrote:
> 
> On 05/27/2015 08:09 PM, Shinnok wrote:
>> Mathieu,
>> 
>> Your description of the problem is too hasty. You need to do a more informative writeup based on the Github discussion, so that the JtR developers understand the problem from Johnny's perspective and provide useful feedback from JtR's perspective. With the current definition, I don't expect anyone to weigh in.
>> 
>> You need to describe the two Johnny problems:
>> 1. Console log output;
>> 2. Getting status lines from JtR(gratuitous or on-demand; for additional functionality and monitoring);
>> And the three solutions:
>> 1. flush() and writing '\n'
>> 2. prospective --no-tty option could be unbuffered (setbuf(stdout, NULL))
>> 3. --progress-every && --crack-status
>> 
>> Shinnok
> 
> Please also explain why these options are not good enough:
> 
> kill -s USR1 <pid> (might not work under Windows)

You have one of the reasons right there(signals just aren't an option on Windows). The other one is, that still doesn't get any message passed the stdlib buffer to Johnny.

NB: What I find weird about JtR is that by default, it treats input as a tty(and if not tty then defaults to reading password candidates) and output as standard buffered stdout. This discussion will probably evolve towards trying to be more flexible on that front so that wrappers(like Johnny) can properly communicate with it.

Shinnok

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ