[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 May 2011 10:41:06 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: patches to integrate into jumbo
>-----Original Message-----
>From: Solar Designer [mailto:solar@...nwall.com]
>Please propose what I should integrate into 1.7.7-jumbo-2 (I think Jim
>even wants to prepare a release candidate for jumbo-2, all on his own?)
>and then into -jumbo-3.
>
>Please keep your proposal(s) short and clear. It is OK for you to
>discuss this in here first, but then please post the conclusions -
>specific proposal(s).
The proposal I had for J-2 RC was more specific to my own changes. However,
if there are multiple changes which should go into J-2, then I am not sure I
would be the proper coordinator for getting the jumbo built. It would be
nice to have an RC for the jumbo, prior to dropping it on the masses, since
the changes are so intrusive. An RC would also give other patch maintainers
(or magnum, lol) a little time to get patches ready for J-2.
Here are 'my' proposals (only with tunnel vision of code that I am working
on):
*******************************************
J-2: - My recent patch set.
J-3: - Any patches I have to md5_gen (or generic_*
if the name gets changed) for any intrinsic
code missing or not working
- Optional: john_test_suite (possibly a make test)
- Optional: john hash building perl script(s) I
have currently placed on the wiki
1.7.8 - The changes to format structure and new 'default'
functions should be included in core.
- All field morphing done in loader.c should be put
into the 'core' prepare function of the core formats
(so that jumbo is not tasked with 'fixing' them).
*******************************************
Here is discussion:
--------------------------------
What I would like to see in J-2 are:
--------------------------------
The patch I have recently released (enhanced md5 + changes to the format
structure).
Caveats: There are also several changes to formats, which I found during my
'test_suite' building/running. These have not seen drastic testing, other
than within the scope of the runs of the test_suite. However, I believe
those changes to be correct. There is still one outstanding nit in loader
(that I am aware of), and I have let Solar know where that is, and why I am
hesitant to try to simply 'port' it. There is also one omission in md5_gen
for type (27) and type (28), md5/md5a in intrinsic builds. Also, I have not
done recent testing on intrinsic builds of md5_gen, so that will need to be
investigated again when I have time.
I will release patches soon after J-2 that gets the proper intrinsic stuff
working (hopefully almost all of it will still be running fine), in the
md5_gen stuff. I may also change from md5_gen to generic_ as proposed by
magnum (the md5_gen scripts would still work, but be considered deprecated).
This should all be self contained, impacting NO other formats.
I will also release patches containing 'thin' version of many formats. When
they are released, there will also be the *_thick_fmt.c file. That is
simply the existing format from today. Then if there are problems (or the
thin version is slower on some system I have not been able to test on), the
person with the problem can simply put the fat format back and rebuild.
This will give me a chance to get thin formats out, or know that the fat
format has to be supported on certain systems.
--------------------------------
For Jumbo-3
--------------------------------
I would like to get the above things added, IF I get that far. The thin
formats may need more user testing, prior to packaging them into the jumbo.
Also, the test suite, might not be a bad jumbo addition. But before we do
that, we need to make SURE that it is doing what we want it to. It also is
not small. It is 2mb compressed, so is a rather large thing. It would be
nice to add a 'make test' that would perform a john -test=1 and run the
suite. What say others about that?
Also the hash building perl script I have on the wiki might not be bad to
add here. I might cut it into 2 scripts. One that does specific 'generic'
compiling / processing. And one that does 'named' format processing. That
script has been instrumental in building the test suite, and the test suite
has been instrumental in flushing out a few bugs (and getting me to finish
up some formats) on the perl hash building script.
This is all I have to propose. I do not build/use john as hard core as some
others.
Possibly a GUI might be nice to start looking at for jumbo, if some of the
google coders have something up and running by then. J-3 might be a little
early for that code, however.
--------------------------------
Beyond 1.7.7-jumbo-x:
I think the core changes to the format (from my patch, with changes to
loader.c/bench.c/format.c) and any core changes needed for the new
fmt_default_load_salt function, should be moved into 'core' john at the
1.7.8 level, so that the jumbo does not have to 'patch' the core format
files to give them the new look and feel. There should be zero impact on
runtime changing the format structure as laid out. I would have loved to
have gotten things stable enough, prior to 1.7.7 release, but I did not have
time. Now, I feel the format changes are solid. We may have to patch a
nit or 2 in the prepare functions (new code that moved the logic from
loader.c into the format), but that can be addressed during the life cycle
of 1.7.7
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.
