[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <033701cc6647$ebf93230$c3eb9690$@net>
Date: Mon, 29 Aug 2011 07:33:56 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: #include "john.conf2" (a wish list item)
>From: Solar Designer [mailto:solar@...nwall.com]
>
>Jim -
>
>On Sun, Aug 28, 2011 at 07:31:36PM -0500, JimF wrote:
>> I do have a question. The .include "file" loading is done during the
>loop
>> that reads in the lines of the .conf file. However, as written (and I
>> believe it is MUCH easier to do this), I do the .include [section]
>includes
>> during initialization, before running the wordlist, or other mode.
>Do you
>> believe that to be the right choice of implementation? Along the
>same
>> line of question, I used an easy to find init within the rules to load
>more
>> rules. I assume there are equivelent locations within the code for
>inc and
>> extern, where we could grab other sections, and insert them.
>
>I think we should avoid adding any mode-specific code when we implement
>this. All changes should be to config.[ch] only, if possible (I think
>it is possible). This may mean non-optimal use of memory and slower
>startup - where we expand the includes even for sections that are not
All changes so far are in config.c (h). However, loading a section while
loading the conf file gets to be VERY ugly, because the section may not have
been read yet. That is why I postponed the loading of the sections until
used.
What we may be able to do, is loop to load the whole config, doing all the
includes. Once that is done, then scan for the section includes, and
populate them. I am not sure if we can walk the entire list generated from
the config like that or not, but if so, that would be one pretty easy
solution.
I really do not think startup will suffer much at all. I highly doubt it
will be really noticeable at all, unless the set of conf files gets very
huge. The big items that cause the most time lag at startup, are loading
multi MB/GB wordlists to memory, loading huge pot files, loading huge
candidate files, and validating rules when you have 10's/100's of thousands
of rules. That takes noticeable amounts of startup time. I doubt the .2s
extra used including a few files/sections, will be noticed, much more than
if all of that data was in the .conf file to start with. It may actually
be faster to include a bunch of smaller rules sections into several
'super-rules', than to have several of these super rules inlined. I bet the
section including will be faster than the original file IO.
>actually in use during a specific invocation of JtR - but it simplifies
>the program structure. To optimize this a little bit, you can copy
>pointers to config file lines instead of making copies of the strings.
What happens when a section gets included in more than one place? I am
pretty sure we have to make new lists, and then link that data into the
other list, like I am doing.
>I don't understand why/how you found your proposed approach "MUCH
>easier". To me, it sounds about as easy for one mode, and more
>complicated when you need it for more than one mode (and also for
>non-mode sections such as [Options] for consistency and future use).
I had not made plans on including anything other than rules section data.
I will what was written about 'include' paths to make sure it is doing what
you expect it to do. I wonder if adding a LIBPATH may not be a bad thing to
do? Also, in jumbo, if the --conf=/path/file is used, should '/path/' be
part of the search path? The user has already explicitly specified it as a
path holding the john.conf file he wants loaded.
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.
