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.