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.