Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 May 2015 08:44:46 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [john-core] Getting John's stdout unbuffered for Johnny

On Wed, May 27, 2015 at 09:56:23PM +0200, magnum wrote:
> On 2015-05-27 20:57, Shinnok wrote:
> >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 am with magnum on this.

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

No, what Shinnok describes about stdout buffering is actually the same
on Unix.  By default, libc has stdout line buffered when outputting to a
tty and fully buffered when not.

http://www.pixelbeat.org/programming/stdio_buffering/
http://stackoverflow.com/questions/13932932/why-does-stdout-need-explicit-flushing-when-redirected-to-file

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

This makes sense.

However, I don't mind changing stdout to always be line-buffered.  This
means JtR will run slower when someone redirects its stdout to a disk
file, but that's not typical and when someone does it for some weird
reason they quite possibly actually want it to be merely line-buffered.

I think setting it to unbuffered is overkill.

Shinnok, just let me know what the Johnny team decides on this.  If you
ask me to, I think I'll add a call to:

setvbuf(stdout, NULL, _IOLBF, 0);

to john.c: john_init().

It is important to keep stdout with its default buffering when john is
invoked via one of the un* symlinks, since they're commonly used with
stdout pointing at a disk file.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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