Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ