Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 06 May 2011 23:00:04 +0200
From: magnum <>
Subject: Re: Following all the patch activity, not uploading
 to the wiki, which patches play well together, revising the wiki page to
 be better

[This is re-sent because the attached patches made it to big. I will 
upload these "bootleg patches" to the wiki instead, and ask the original 
authors to just delete them from the wiki when the real updated ones are 

On 2011-05-04 22:49, Robert Harris wrote:
> I'm finding it more and more difficult to follow all the patch activity we
> have had lately!

It will likely get even worse when Jim posts his "plumbing changes" 
patches for 1.7.7 and we start to rebase to that. Then eventually it 
will get much better.

> Some but not all patches are posted on the patch's wiki
> page and some patches don't work well with others.

Most patches work well with most others but there are ususally some 
manual editing needed because all format patches modify the same places 
in options.c and many other patches modify the version string in 
params.h. This is a problem with diff/patch that is hard to work around.

I have thought of ditching the format list in options.c and create it 
automatically from the structs instead. This will save us from almost 
certain collisions between formats.

> Some patches are
> updated to the next version, and the wiki page may reflects this,  but if
> you aren't paying close attention you'll miss it.

If you subscribe to that wiki page, you'll get a mail whenever things 
are added or updated. And maybe anyone updating a patch should move it 
to the top of the list, so we always have newest first? I think that 
would help a little. [EDIT: I started to do just that now with my patches.]

> Can we apply patch "john-1.7.7-jumbo-1-ssh-06-OpenMP.diff", before or after
> the OpenMP revision 4 and/or 7?   Or at all?

The OMP patches does not have jumbo in their names, so they are to be 
applied before jumbo. Having said that, they do apply fine after jumbo 
too. Either way, the version string in params.h gets rejected at some point.

I use to do it in this order:
1. john
2. one of omp4, omp7 or nsk3 (a.k.a Faster bitslice DES key setup)
3. jumbo
4. early release md5gen
5. intrinsics and intrinsics-fixes
4. fullmpi and utf8 in any order
5. any extra formats available

The "early relase md5-gen" patch applies just fine to 1.7.7 except for 
the dreaded version string in params.h. The intrinsics patches need a 
lot of hand editing. I managed to rebase it with good help from 
git-mergetool but it currently breaks md5a. As these patches are 
"bootlegs" I will attach them to this mail in case someone needs them, 
but I won't post them to the wiki. [EDIT see top of mail.]

> These patches all applied after some manual edits, but the build of this
> failed, at least on windows.
>     john-1.7.7.tar.gz with the patches:
>                  john-1.7.7-jumbo-1.diff
>                  john-1.7.7-jumbo-1-rar-01.diff
>                  john-1.7.7-jumbo-1-ssh-06-OpenMP.diff
>                  john-1.7.7-jumbo-1-utf8-1.diff
>                  john-1.7.7-SybaseASE-01.diff

The UTF-8 patch needs to be updated, rev 1 had an ugly bug and some 
32-bit problems. Other than that, I have no problems compiling the above 
and all self tests passes.

> I think the different multi-CPU branches we have is a little confusing,
> especially when we mix all those different trees of patches with the
> "normal" patches.  That is why I suggested before that we break out those
> patches into at least on other separate table.  But, Alex axed that idea.

I would not object to breaking them out but I think it's fine as-is. 
Note that OMP and MPI can be used together. For the single-host, 
multi-core case you'll just pass GOMP_NUM


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.