[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <011201cc1974$5d76cfb0$18646f10$@net>
Date: Mon, 23 May 2011 13:08:05 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Ideas for jumbo-6
>From: magnum To: john-dev@...ts.openwall.com
>
>On 2011-05-23 15:29, JFoug wrote:
>> for #3
>>
>> Which ever method is chosen, the core formats declares would be in
>> -- snip
>
>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"?
Right now, today this will also NOT work. You cannot use the same structure
name. They are global name scope. However, the dupe param label is
something that must be addressed. There is nothing in the format structure
today, which would 'keep' this from happening.
>1. It's not detected, so the build will fail with cryptic errors.
Build should not fail (I think).
>2. The pre-build script bails out with a helpful error.
This would be the ideal way to detect global param.label stuff. However, I
am not sure this can be done script wise at compile time. It may have to be
something added to the 'about' screen dump from john.
Btw, I 'think' john still works with 2 formats using the same params.label.
One may hide the other, or they both may be 'loaded' (I think both loaded).
>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.
Well, I will be working on thin formats. I was planning on using
*_thin_plugfmt.c for them, as a 'naming' standard. Thus, we 'could' get
tricky. However, is the thin always preferred? I would guess not. I would
think the thin would be a standard install, but then a user has a problem
with thin, and tries to revert back to thick, by coping a thick format from
somewhere (possibly a repository on the wiki of the 'old' thick formats).
Being a user and not realizing how john is built, it now fails (or continues
to run with the thin format). Just poking out a hypothetical to keep the
thoughts flowing.
Jim.
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.
