john-users - Questions about LARGE multiple patch files

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <C1405ABF00F44417A9C4DEC71D2246ED@ath64dual>
Date: Tue, 22 Sep 2009 11:55:03 -0500
From: "JFoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Questions about LARGE multiple patch files

List, 

I have several large and hard to deal with Patch files.  They are difficult for users to install, and very difficult for me to maintain, doing 'partial' patching, fixing and re-diffing trying to get collisions removed as much as possible.    There is also a pretty heavy inherent order which most of these patches have to be installed, before other patches work.

The patches I am working with and referring to, are:

MinGW-VC  
   This one 'should' not depend on other patches, but may collide. I am working on removing all collisions with my other patches.

fast-MD5  
   The changes I did merging the SSE2 and the 'fast' x86 methods.

phpass     
  depends upon fast-md5

performance-enhancements  
  depends upon phpass (and thus fast-md5)

Several-new-runtime-options
  Depends upon performance patch

generic-md5
  Depends upon at least one of the 'new' options, but adds several other new options.  This one collides heavily with the 'options' update


**** My first question to users (To Solar in specific).  Should I wind up all of these into a 'single' patch?  (well 2 patches, as the MinGW patch will not be part of the larger one)  ****

Yes, the user 'loses' the ability to select which part they want, and end up with all.  However, the patch should be easy to build to install directly to 1.7.3.4-jumbo-X level (jumbo-1 at this time).  It will be easy to get it PROPERLY patched in by the end user.  That is one of the problems right now.  It will also be much easier for me to maintain, and to make sure I get the proper items included into the patch.

If this is not poo-poo'd by the group, that is the plan I will be moving forward with.  I will NOT put the MinGW/VC build patch into the other 'main' patch, so there will end up being 2 patches.  The MinGW-VC will be made to work straight from the jumbo-1 or made to work correctly after the other large patch  (generic-md5-performance-options I think is what I will 'call it') patch.  That generic-md5-performance-options patch will also be done so that it works perfectly from 1.7.3.4-jumbo-1 or from 1.7.3.4-jumbo-1 + MinGW-VC   (i.e. both patches work in any order, and properly patch).

I have several reasons for this query.  One, I want to move things so that the properly link into the current stable 1.7.3.4 + jumbo-1 level.  Second, I have some significant changes in the md5-generic modules.  Performance gains, and also getting benchmarking working very good, and having to make changes to HOW benchmark code works (since there are now 17 generic md5's, so there is one format that tests 17 times).  So this required some changes to how bench does it's work.   Third, there are several 'built-in' formats which can be trimmed down to VERY minimal, and then simply 'hook' into the md5-gen code.   The ones I have already done are:
 
md5-raw
phpass
PHPS

and I am sure there are others.   But to get to the stage where I can 'release' these, I have to get to a point where the md5-gen is properly released.  Thus the 'spider-web' of patch collisions and dependencies, which I would like to alleviate by combining the patches into a larger 'super' patch.

Jim.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.