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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ