Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 May 2011 16:43:45 +0200
From: magnum <>
Subject: Re: Ideas for jumbo-6

On 2011-05-23 15:29, JFoug wrote:
> for #3
> Which ever method is chosen, the core formats declares would be in
> john.c and then a #include fmt_externs.h  and the core formats
> init_one() calls would be in john.c with #include "fmt_registers.h" in
> the middle of them. All other extern stuff or init stuff would be removed.
> *******************
> for #4
> This goes along with #3.  The POC designed, only worked with the
> *_plugfmt.c (thus, that is likely going to be a factor in choosing for
> #3).   This is very simple.  There is a build rule done, that finds all
> of the wildcard *_plugfmt.c files.

Sooner or later we will probably have to handle plugformat collisions so 
we might as well give it a thought now. What if a user has foo_plugfmt.c 
and bar_plugfmt.c but both formats declare its struct as "fmt_sha2" 
and/or a params.label of "sha-2"?

1. It's not detected, so the build will fail with cryptic errors.
2. The pre-build script bails out with a helpful error.
3. The pre-build script emits a warning, but solves the problem by 
chosing one of them using whatever heuristics - like "prefer thin over 
thick" and "prefer new over old (file timestamp)".

We should strive to keep this as simple as possible though so I guess 
number 2 is the way to go. But just maybe we could want that 
thin-over-thick thing hacked in? Not that I know how we would tell them 
apart in a canonical way.


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.