Date: Mon, 29 Aug 2011 05:17:58 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: #include "john.conf2" (a wish list item) 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 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. 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). > So, for #2, you would list that "file" would find the file in ./file or in > mode -config=/path/conf_file would also search in /path/file (the second > one is only a jumbo command I think). Then <file> 'appends' $JOHN/ the > path. That works fine, and is very easy for a C programmer to grasp. An important detail here is that we must not trust the current directory contents (unless it is already trusted for other reasons) - e.g., if we have a system-wide install of John and happen to invoke "john" (found via PATH) when we're in /tmp (a bad thing to do, but still), it must not unexpectedly probe for (and maybe load) files like /tmp/something.conf. So "file" must _not_ actually try ./file. It should only look in the directory from where the current config file is loaded. This should probably apply to recursive includes in a similar fashion (using the including file's directory). <file> will differ in that it will look in the $JOHN directory instead. With "path/file" or <path/file>, it's similar to the above, with the paths applied relative to the appropriate directories. With "/path/file" or </path/file>, absolute paths are used as-is, and there's no difference between these two. > So, #1, #2, #3 look pretty simple for me to change what I have done right > now, into something that works for them. The only difference between core > john, and jumbo john, may be in the -config=path path also being part of > the searchpath for conf includes. The rest should be a simple port between > core and jumbo, with exact same logic. Right, except that I think only one directory should be checked in each case - not a search path. The only exception to this is that $JOHN, when it applies, means checking two directories with system-wide installs (JOHN_SYSTEMWIDE_HOME and JOHN_PRIVATE_HOME). Thanks, Alexander
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.