Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Jan 2013 13:13:41 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: New plugin load order magic

On Fri, Jan 11, 2013 at 09:27:51AM +0100, magnum wrote:
> On 11 Jan, 2013, at 8:58 , Solar Designer <solar@...nwall.com> wrote:
> > On Fri, Jan 11, 2013 at 08:26:40AM +0100, magnum wrote:
> >> I was just considering reverting my patch for now.
> > 
> > Yes, I think you should.
> 
> I reverted it now but we need to fix this somehow. For the horribly slow iterated formats that are getting common now, we just can't default to CPU formats on a GPU build.

Well, maybe we can have ldr_split_line() skip calling fmt_init() if
source is non-NULL and the format is a GPU one.

> > We may want to eliminate the need to call binary() for --show, but this
> > may have non-trivial consequences (some desirable, some maybe not).
> 
> So we would compare the ascii representations after prepare() and split(), instead of the binaries. Could there be different representations of same binary? When?

Upper/lowercase variations of hex encodings is an obvious example, but
we should be taking care of them anyway.

IIRC, the uses of binary representations in --show are primarily to make
use of binary_hash*(), but there are also uses of source representations
and a corresponding hash function anyway.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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