[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Aug 2011 13:12:54 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: #include "john.conf2" (a wish list item)
From: "Solar Designer" <solar@...nwall.com>
> On Fri, Aug 26, 2011 at 07:24:57PM -0400, David Jones wrote:
>> I think it would be better to establish a formal escape syntax to
>> identify comments that aren't really comments, such as ##!include rather
>> than just #include.
>
> I am not sure whether we want these directives to look like comments at
> all or maybe not.
> What are our reasons to make them comment-like? Just
> that it's the way it's done in the C preprocessor? OK, I identified one
> more reason - not introducing a new character that may sometimes need to
> be escaped.
I chose comments (which ANY line starting with a # is a comment), due to it
still 'can' run on any legacy version of john. Now, if a file is not
included, then of course, things may not work, but there is no 'new' syntax
added to john at all, which would cause legacy versions to fail.
> What do we want older versions of JtR to do when they see an include
> directive - silently ignore it (treat as comment) or complain about it?
It will silently ignore, which I figured would be the best way. There is no
way to 'change' the old version of john's behavior, without introducing new
code. Now, due to data not being loaded, someone my rely
on -rules=new_rules_data to work, but the file with
[List.Rules:new_rules_data] was not loaded, thus john complains about
unknown rule. There is no way to make every situation happy.
> If it's the latter, then we need to use a different syntax, not
> comment-like. But what syntax? If we use something like:
>
> [Include:File-or-Section]
>
> it will just be treated as a new section start by an older version of
> JtR - not what we want. If we use some new syntax like:
I actually like the above method. This could be extended to pull in a whole
file, or just grab a specfic section out of one.
>
> include "file"
> include [section]
>
> or:
>
> {Include "file"}
> {Include [section]}
>
> it will not always be detected as an error by older versions of JtR -
> depending on what section it's in. Also, it might introduce a new
> character that may sometimes need to be escaped.
>
> Yet this might be the best we can do. Any other ideas?
I tried to keep it from impacting legacy, other than it will not be able to
include, so as to reduce the issues with legacy john, until people have
upgraded.
Now, for the rules including other rules, that is a totally different
ballgame. The conf including conf is all at load time. we are simply
adding more lines into the set of config list objects. The rules loading
rules, happens after all lines have been read into the conf array, and after
all comments have been stripped. Thus, we can not use a comment, or other
means of 'hiding' it from legacy (unless we also added code into the load
conf also). The way I have it right now, it will have a bogus rule for a
legacy version of john.
So, if we really wanted to make it transparent to legacy, we could:
[List.Rules:RuleX]
:
Az'123'
#rule_include "RuleY"
Az[0-9][0-9][!@...^&*()]
....
Then in the loader, we allow the #rule_include line to NOT be removed, and
then in the rules initialization, use #rule_include syntax checking to load
rules.
However, on legacy john, the #rule_include line simply gets silently thrown
away.
Again, both of these patches are out as PoC, hoping for feedback. They do
both work, and work pretty well. I was hoping to hear other peoples ideas
(which some good ideas have started). It is likely that there are much
better ways to hook these changes in, than the methods I have chosen.
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.
