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:56:23 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [john-core] Getting John's stdout unbuffered for Johnny

On 2015-05-27 20:57, Shinnok wrote:
>> On May 27, 2015, at 9:26 PM, Frank Dittrich
>> <frank.dittrich@...lbox.org> wrote:
>> On 05/27/2015 08:09 PM, Shinnok wrote:
>>> 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

I take it this was discussed in some Johnny repo on Github? I wouldn't 
want to follow that very closely, but don't hesitate to alert me with a 
@mention to get my attention if needed.

> 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)

As far as I'm aware it treats input as a TTY if it is indeed a TTY, 
nothing weird about that. It doesn't default to reading candidates, 
there's an option for that.

I haven't ever experienced any problems with stdout buffering, perhaps 
it's somewhat different under Windows?

> 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.

My general feeling about this is you shouldn't try to use stdin/stdout 
for things they're not designed to do. If we're about to change JtR 
code, why not add a proper interface of some sort, intead of fflush 
bodges? How hard would that be? (that is a sincere question, not irony).

magnum

Powered by blists - more mailing lists

Your e-mail address:

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