[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP1643813970584936217128FFDB40@phx.gbl>
Date: Sun, 5 Jan 2014 18:07:36 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Enhance john.local.conf to allow redefining individual john.conf
options
I'd like to be able to redefine (part of) what has been defined in
john.conf.
Reasons:
As a developer, I'd like to be able to change config options without
risking to accidentally commit those changes.
As a user, I'd like to be able to get the latest and greatest version
without worrying about what changes that I made to the old john.conf
will be needed in the new john.conf.
Of course, I can just create my own config, e.g., by copying john.conf
to another name, and always use --config=my.conf
I could also just continue to use my old john.conf file even after
upgrading to a new version.
It is also possible to include the definition of an existing option into
your john.local.conf.
But then you have to duplicate the complete section, not just add your
changes.
All of these options have their drawbacks.
What would I like to change/redefine?
Most importantly, anything inside [Options], [Options:MPI],
[Options:OpenCL], [UserClasses]
Nice to have: [Markov:Default]
(Defining another Markov mode is possible, but being able to redefine
[Markov.Default] setting would save typing.
All of the above sections are "parameter sections".
Here it should be possible to redefine the value of individual
parameters, while keeping the value of other parameters defined in the
original section.
If we should allow to redefine other sections (like [List.Rules:Single]
or [List.External.Filter_Policy]) is another question.
Instead of redefining [List.Rules:Single] and [List.Rules:Wordlist], we
could also allow to define general options variables
WordlistRules = Rules
SingleRules = Single
which could then be redefined in john.local.conf (or any other config
file included in john.conf) to change the default List.Rules sections
used for --single or --wordlist.
(Along the same lines, we could also define a new variable
MarkovMode = Default in the [Options] section.)
If you agree that this is a useful addition, the syntax could be like this:
[Redefine.Options]
Idle = N
# all other options defined in [Options] remain unchanged
(Such a redefinition section must always be placed after the original
section.)
[Redefine.UserClasses]
9 = something
2 = \x0d
# 0, 1 remain unchanged, 2 redefined, 3 - 8 not defined..., 9 added
[Redefine.Incremental:ASCII]
MaxLen = 10
# MaxLen reduced, everything else unchanged
I would not allow stacking redefinitions, e.g. [Redefine.Redefine.Options]
If it turns out to be easier to implement this if the redefinition must
completely rewrite the contents of the original section, this would also
be possible, with a little more effort required for a redefinition:
[Redefine.Options]
.include [Options]
Idle = N
What do you think? Is this too complicated/too confusing for users?
Do I miss something?
Will we provide users just one more way to shoot themselves into their feet?
It shouldn't be too complicated to implement.
Probably these redefinition sections should not be listed by
--list=sections (if yes, they should be suppressed in bash completion)
On the other hand, --list=parameters:options should probably list the
parameters after all the redefinitions have been applied.
Frank
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.
