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.