Date: Wed, 11 Jul 2012 22:45:13 +0200 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Re: Re: Aleksey's status report #10 On 07/10/2012 07:42 AM, Aleksey Cherepanov wrote: > On Wed, Jun 27, 2012 at 02:55:34PM +0200, Frank Dittrich wrote: >> --markov can have several colons, e.g. >> >> --markov=200:0:0:12 >> --markov=section:0:0:0:10 >> --markov:section:200 >> and so on. >> The first : (or =) separated the option name from the parameters passed >> into the markov mode function. > > I replace only first : with = and only in parameters started with - so > everything should work well. If there is already a '=' char, as in --markov=200:0:0:12 or -markov=section:0:0:0:10, replacint the first ':' with '=' would be wrong. >> We should prefer = (the separator used in the usage output) if possible. > > By the way should I prefer double dash or single dash? '-key' or > '--key'? I guess double dash is preferred due to john's usage output > and general idea of long and short options. Yes, I think the options should be used with 2 leading dashes, as mentioned in the usage output or --list=hidden-options (for options which don't appear in the usage output. There is one option which doesn't appear in the usage output and which doesn't (yet) appear when using --list=hidden-options, but it is not relevant for attacks: --make_check. You an just ignore this option. It should be relatively easy to create a mapping from abbreviated option names to their long names. (Don't do it by hard coding all possible combinations like I did for several options in john.bash_completion - I intend to change that as well.) The generic approach is: collect all the options listed in the usage output or in -list=hidden-options output. Remember which options do have an optional parameter (those with --option[=...]), and which have a mandatory parameter (--option=...). Now store mappings of abbreviated option names ("--o" ... "--optio") to the complete option name ("--option"), as long as this abbreviated name is not ambiguous): Built abbreviated forms for all of these options, by deleting the last character, check if there is already an existing mapping. If no, store the new mapping. If yes, that means, the abbreviated option is ambiguous, just map it to an empty string. (If it is easier for further processing, you can also store a mapping from "--option" to "--option", or you may prefer to store mappings for abbreviated options with just one leading dash...) Then, if the user specified abbreviated option names, just replace a single dash at the start with two dashes, and look up the long option name for the abbreviated option name. This way, the server will receive just long option names in the attack description, making sure those attack descriptions will continue to work even with future john versions which might have more options, possibly colliding with abbreviated forms of other option names.) >> For naming attacks, files, and so on: >> You could generate a checksum (sha1sum ...) on the contents, and use >> (part of) that as the name for storage on the server. > > Checksums are not good for names of files used by john because > original names could have valuable meaning. And I guess it is easier > to store checksum for files separately, not in file name. But file names are more likely to be not unique. You can't prevent a user to overwrite a file my_wordlist after creating one attack description and prior to the next attack description. So, storing the file name is useful, but a checksum makes sure to recognize if two files are unique, even if the name given by the user differs. (Instead of storing multiple names for the same file, I'd think about responding with an error message instead.) 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.