|
Message-ID: <BLU0-SMTP187D904117C14B01D656A05FDCE0@phx.gbl> Date: Wed, 16 Mar 2011 07:37:52 +0100 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Changing --markov[=LEVEL[:START:END[:MAXLEN]]] to --markov[=SECTION] Hi, it might be a bit late to come up with this idea, since 1.1.7 will be released soon. Wouldn't it be a good idea to change the --markov option handling to make it more similar to other options like --rules and --single? That means, instead of specifying all the options on the command line (and falling back to values specified in the general [Options] section, --markov should get a separate section (let the default section be [Markov] (--markov=Markov) or [Markov:Default] (--markov=Default). The .rec file should include the markov section name, not just those values specified on the command line. Then it would be possible to use different markov sessions in parallel without using different config files or subdirectories. The main difficulty probably is distinguishing --markov=LENGTH[:other_options] from ..markov=SECTION. This could be achieved by either interpreting existing .rec files depending on the recfile version (I am not sure if it will be bumped for john-1.7.7) or by not allowing section names using only digits and colons). In my opinion, the distinction is only necessary for interrupted --markov sessions. The command line could always use --markov=SECTION, just make sure it is later on possible to know whether the .rec file contains a section name or length and other parameters. Even the usage output could be restricted to the new logic. Just keep the "(see documentation) comment, and describe the older command line and/or .rec files for these old sessions in doc/MARKOV. What do you think? I had this idea for quite a while (since I managed to continue --markov session with a different stats file that these sessions used at the beginning), but I never got to discuss this with anybody. After the separate john-dev mailing list existed, I wasn't sure which list would be more appropriate. Now I think it needs to be discussed on john-dev first. 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.