Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 May 2011 20:06:35 -0500
From: "JimF" <>
To: <>
Subject: Re: Plumbing changes (was: Re: Following all the patch activity, not uploading to the wiki, which patches play well together, revising the wiki page to be better)

That sounds like a wonderful addition.

However, somewhere, there still will likely be a spot with major patch 
clashes.  load formats is one of them. Every new format has to be declared 
at 'some' point.  One possible work around here, would be special include 
files or something where each developer got his own.  Then if he only 
changes that header, he would not impact anyone elses changes.  Including a 
source file is semi non-standard, but is one way to work around the multiple 
patching collisions.  Those changes (and the params 'version string'), seem 
to be the place with the most collisions.  We could get around the params.h 
change, by simply having only ONE person that can change that one (solar), 
and then if we need to, have multiple additional outputs again, in our own 
private developer headers, which could be output on a version check page. 
So then it would list 1.7.7 jumbo-1  and then list additional lines, for the 
other patches installed.   The jumbo would set each developers private 
header version string to "", and then they can make changes as they see fit, 
to their own string.

Just talking off the cuff here.


----- Original Message ----- 
From: "magnum" <>
> Maybe I should also implement that "auto-generated format list" for 
> options.c that I have been thinking about... this would mitigate a lot of 
> patch collisions. Together with your changes, most new formats would only 
> add one line in Makefile and two in john.c

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.