Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 May 2011 16:40:43 -0500
From: "jfoug" <>
To: <>
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


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.