[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 May 2011 16:40:43 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: patches to integrate into jumbo
It is a BIG sob (compared to most of the things dealing with John).
>From: magnum Sent: Saturday, May 07, 2011 4:13 PM
>> nice to add a 'make test' that would perform a john -test=1 and run
>> the suite. What say others about that?
>
>IMO it's not to be included in the normal distributions, but it should
>be packed nicely and used by all contributors. It could even be
>mentioned in the "how to make patches" page as a mandatory step.
>
>With "packed nicely" I mean it should be a tar file (or even a "normal"
>patch") that sets things up so you can just sit in the src directory as
>usual, and do
>
>make clean && make thisorthat
>make test
But, don't most people 'want' a make test? Make test could run
john -test=1
and then launch the tstall
Then we could include JUST the items required in tstall for a 'core' in the
john core. It would allow the user to do: make clean ; make whatever ;
make test ; make install (do we have an install?) and that would be much
close to the normal *nix build (minus the ./configure).
All I know is that script has shown me a LOT of problems, and allowed me to
spot them a quickly fix them. Magnum just had a taste for it, and found a
build that did not work well at all. I do not know if the john -test would
have had problems or not, but the test_suite showed problems quickly.
I agree, that contributors should run this, prior to releasing a format.
Possibly getting their test input file setup, which may mean getting a patch
to the perl script also, or some other mechanism to generate the hashes.
The self tests are a good idea, but there is simply too much that gets by a
self test, but in a real world run, the format is foobar.
The test suite in total is still a young package. If there are changes
needed (such as incorp into Makefile, putting into a 'fixed' directory,
etc), then it can easily be done. I have used it to get my code working
properly on BE systems, for 2X MD5 (from md5_std.c), and a few other things.
Without some way to run real world tests, major design changes like what
were just added are very hard to get finished properly. I had been
foundering for a while, and needed some way to validate (either good or
bad), that changes were working, and that changes did NOT screw up something
else. Now, the md5_gen code is 4-24x more complex than most formats
(because it handles some many different build configurations with #define
stuff), but for most formats, knowing that changes have not foobar'd their
running, and have not inadvertently foobar'd some other format is pretty
important.
Jim.
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.
