Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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