[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100802225652.GA31120@openwall.com>
Date: Tue, 3 Aug 2010 02:56:52 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Wiki page on patches is confusing, outdated
On Mon, Aug 02, 2010 at 05:37:15PM -0400, Robert Harris wrote:
> I'm not always sure if an individual patch is still relevant, or if it is
> included in a jumbo patch
The "Status:" comments in the "Description" column were meant to always
make this clear, and I think that they do right now (I've just checked).
> I'd love to see a readme that tells us the list of patches a jumbo patch
> includes, and high level list of the bugs/fixes. (Otherwise we have to
> compare the difference patch files.)
Basically, a change log for the jumbo patch? Well, maybe I'll start
maintaining one if there's demand, but documenting every single fix
feels excessive considering the overall low quality of the jumbo patch
(yet the patch is very useful indeed!)
> john-1.7.6-jumbo-5-jmk-mschapv2.diff (so, jumbo 6 does not contain,
> MSCHAPV2)
Yes, I forgot about this one when generating -jumbo-6, which I did to
make my posting regarding SMTP AUTH. I am likely to include it later.
> john-1.7.6-jumbo-6-config.diff (applies fine, makes sense since it
> came out after jumbo 6.)
Right.
> john-1.7.6-fast-des-key-setup-3.diff (worked, but minor issue with this
> trying to modify the John_version number. So the jumbo patches don't
> include this for some reason)
I never tested my new DES key setup and DES OpenMP stuff with jumbo
patches. There was no point in doing so for me. It was experimental
code that is a prototype for new code to be written for the official JtR
(not jumbo). Besides, the new DES key setup patch is known to be right
for SSE2 only; it won't compile on other systems (non-x86 and older x86),
so applying it to jumbo would severely reduce jumbo's portability.
> john-1.7.6-jumbo-3-krb5-2.diff (did not patch, perhaps already in jumbo-6
> or lower?) (Yes, comparison of the Jumbo 6.diff to this patch seems to show
> it is in there)
Yes, merged. It's not even listed on the patches page, and it never was.
> john-1.7.6-single-have_words-fix-1.diff (did not patch, perhaps already in
> jumbo-6 or lower?) (Yes, comparison of the Jumbo 6.diff to this patch seems
> to show it is in there)
Yes, merged. It's not even listed on the patches page, and it never was.
> What determines if a patch will or will not be included in the next jumbo
> patch?
Lots of things - both relevant and not (like my time and mood). In
general, I am trying to include almost everything that is easy for me to
include, that is useful to have, and that is not known/expected to break
things too badly. Bugfixes have priority over new functionality/speedups.
> Let's say a patch "a" is for version "b" of JtR with jumbo patch "c", let's
> say a new version of JtR or a new jumbo patch comes out. I'd like to see
> the table get updated to say either patch A is integrated into the new
> version and/or jumbo patch, or say something else like still relevant, patch
> still can be applied to latest version X, or perhaps version X breaks this
> patch, and it needs to be reworked (by the author)
That's what I've been doing lately. Your only "complaints" so far are
about patches that are _not_ listed on the wiki page.
> Adding a date column.
I don't mind, but... date of initial revision, last update of the patch,
last update of the info about the patch (its status), or all three?
> Changing the order of the patches, so it is in chronological order
Makes sense, but...
> starting with the oldest on top
Why not the latest?
Also, when a patch is updated, should it be moved to top (or bottom)?
That would be nice, but it'd complicate wiki edits and reviews of the
diffs.
> Adding a status column (saying: added to current jumbo patch, apply this to
> version x.x, patch y, or separate patch- currently relevant, or something
> else)
I see no need for a separate column. I think status info included as
the first line of Description works better (keeps the table narrower).
> I'm willing to modify this page with these suggest, if the group tends to
> agree, but I might need some help.
>
> Anyone else have other ideas to make this page easier to understand/better?
Let's see what others have to say on this.
In the Subject you say that the wiki page is outdated, but I think you
failed to provide a single example of that. Please do.
Thank you!
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.
