[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110829011758.GA9796@openwall.com>
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.
