[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110505205607.GA1862@openwall.com>
Date: Fri, 6 May 2011 00:56:07 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Following all the patch activity, not uploading to the wiki, which patches play well together, revising the wiki page to be better
Robert, all -
On Wed, May 04, 2011 at 04:49:52PM -0400, Robert Harris wrote:
> I'm finding it more and more difficult to follow all the patch activity we
> have had lately! Some but not all patches are posted on the patch's wiki
> page
I think that all patches, except maybe for trivial compiler warning fixes
and the like, should be getting uploaded to the wiki. For trivial
patches that are of little use to end-users - that is, warning/typo
fixes that I am expected to apply in the very next revision of the code,
it is OK to post them to john-dev (and not bother uploading to the
wiki). I am then copying them to my john-contrib folder, which I review
before I release new jumbo patches.
> and some patches don't work well with others.
Unless you're into JtR development, you should assume that none of them
work together unless the opposite is stated explicitly. Specifically,
for some patches it is stated that they're to be applied on top of jumbo -
obviously, they work together with jumbo (and in fact they don't work
without jumbo). But that's the only major exception.
I understand that users want to have lots of functionality available at
once, in the same JtR build. This is what jumbo is for. End-users who
want the community-contributed functionality are supposed to use jumbo
rather than mix various smaller patches together on their own. As an
exception, end-users who need specific bits of functionality that is not
yet in jumbo (nor in the official JtR) may use the corresponding smaller
patches, without mixing them with any other patches. For example,
1.7.7-omp-des-4 may be used when this functionality is needed, but on
top of clean 1.7.7, without jumbo.
> 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.
I suggest that contributors who upload end-user relevant patches to the
wiki should announce those in here once in a while (major updates and
stable versions).
If anyone wants to be aware of any and all updates to the patches on the
wiki, that person may subscribe to the wiki page (register for a wiki
account, go to the http://openwall.info/wiki/john/patches page, click
the Subscribe button at the bottom). The wiki will then send e-mail
notifications of page changes...
...which reminds me: when you edit wiki pages, please describe your
changes in the "Edit summary" line. So far, most contributors leave
this field empty on most of their edits, which makes it difficult to
spot just what was changed in an e-mail with the diffs.
> I like to build the "latest" version of John with all the patches possible,
This is not necessarily the "best" version to use. Personally, I would
not use it.
So far, I found your ahead-of-jumbo builds (integrating recently
contributed patches) to be useful to get those patches tested before I
integrate them into jumbo. That's a valid reason for you to spend the
effort and for some people to use such builds... but frankly, those
builds are probably not the best for an end-user to use, if we don't
consider possible benefits to the project.
> but figuring out all the latest patches that play well together has been
> tough lately. Because of other builds I can tell that there are two tracks
> of OpenMP revision 7 and 4 and the description helps, but that is a little
> confusing.
I don't see how to make it less confusing other than by actually working
on that code to eliminate the need for having two versions of -omp-des
and then to integrate the resulting more generic and cleaner code. I am
going to do that. Meanwhile, those patches are not to be used without
need. They're available to people who need them, but they're not in
jumbo for specific reasons.
> Here is an example of the type of things that should be clear on the page,
> but aren't.
>
> Can we apply patch "john-1.7.7-jumbo-1-ssh-06-OpenMP.diff", before or after
> the OpenMP revision 4 and/or 7?
I guess this is untested. You should assume no. Moreover, the -omp-des
patches are not to be applied along with jumbo anyway. These things
might work, but they were not meant to.
> Or at all?
It should apply on top of john-1.7.7-jumbo-1.
> I attempted to build the following, the other day, and it failed. (All the
> patches took, with some manual adjustments). The other day, I considered
> this as the "latest version", that has changed a little since
Why not just wait for -jumbo-2? Are you just trying to help test those
patches? If so, that's fine, and is appreciated.
> 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
Of these, the utf8 patch is an invasive one. If you choose to apply it
(on top of john-1.7.7-jumbo-1), I suggest that you don't apply anything
else, unless you're prepared to actually develop code on your own.
> I think the current patch's wiki page needs to be revised. I think a
> starting list might be to include additional columns such as "modified
> date", "OS patch applies to" , etc. Others?
How would these extra columns help with the issues you bring up? They
may be helpful to have (although I am not sure if they're worth the
table space or not), but I don't see them helping with these issues.
I think a statement that patches are only meant to apply/work with the
exact versions of JtR they've been made against would be of more help.
For example, john-1.7.7-jumbo-1-utf8-3.diff only applies on top of
john-1.7.7-jumbo-1 (and not on top of anything else), and when you apply
it you can't reliably apply any other patch. Ditto for
john-1.7.7-jumbo-1-ssh-06-OpenMP.diff. This implies that you can't
reliably apply these patches together. (In practice, you might be able
to if you're lucky, but this is not something that patch contributors
test and try to support.)
> 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 still don't see how moving the -omp-des* patches and the MPI patch
(revisions of it against different versions of JtR) into a separate
table would be of much help. However, I don't really object to the
change. If you choose to make it, please be sure to edit the
descriptions of -omp-des-7 and -fast-des-key-setup-3 accordingly (these
patches are related to each other, but with the proposed change they
would end up in separate tables...)
> Please chime in on how to what you all think of the patches page, and
> possible ways of making it better.
I see the following three major improvements to make:
1. Add a statement about patch incompatibility, as I suggested above
(assume incompatible unless stated otherwise).
2. I should work on integrating the recently submitted patches into
-jumbo, etc. This includes some patches submitted before the 1.7.7
release, which I did not merge into 1.7.7-jumbo-1 because I wanted that
release to stay somewhat stable.
3. I should work on generic, clean, and official DES/OpenMP code. This
would eliminate the need for having those -omp-des patches on the wiki.
Of course, there will almost always be tasks like #2 and #3 - new
patches will be getting contributed, and I will have my own experimental
code too. I don't see how this may be addressed in a generic way with a
change to the patches page layout.
We're going to try setting up a git repository for john-jumbo (and maybe
more), but I am not ready to say whether and how it will affect our
needs for the patches page.
Thanks,
Alexander
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.
