Date: Mon, 9 May 2011 13:09:41 +0300 From: Shinnok <admin@...nnok.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 Hi all, Since this discussion is taking place on john-users, may I state with respect, *wtf* are you talking about here? A *normal* average user would have no idea what you are talking about and this will make people go away, running batshit crazy from the list and JtR. Community separated edition, jumbo, jumbo patches, incompatible branches and patches, bootleg patches?? Nonononono There must be a better way of achieving this, instead of running around with patches and tarballs in bare hands and wikis, therefore I'll propose an alternative solution to the issue at stake, based on the upcoming git repos, written after magnum's reply for the sake of context: On Sat, May 7, 2011 at 12:00 AM, magnum <rawsmooth@...dband.net> wrote: > > 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.] > > The way I see it we have JtR official and JtR Jumbo which is a *community-enhanced *version with lots of other community improvements and fixes over the base JtR, which is kept separate from the official version because of quality and review reasons(?). On top of that, we have *patches* and tarballs floating around on the wiki pages and mailing lists, for JtR and for Jumbo. Please feel free to correct my current understanding of the JtR dev flow. However, all of this can be nicely grouped into the following git repositories: 1. The main official JtR repository, where only Solar(and other select few?) can commit. All others can pull. Branches for exp. dev and tags for releases. Master for main dev. 2. The main official JtR Jumbo repository, where only Solar(and other select few?) can commit. All others can pull. Branches for exp. integration work from Solar(and others?) based on 3. repo branches. Tags for releases. Master for main dev(if any). 3. [Distributed]Clones of 2. repo, where people work on new or old jumbo functionality like rar, ssh or utf. Branches are the recommended way of working on functionality, using the ones already existing for improving experimental code not already in master or new branches for new functionality that can be cloned from your public external repo on demand(github, gitorious) or by submitting patches(git-format-patch). Now all that remains to be done is a wiki page explaining all of this and where the actual repos reside. People can edit the public part of this wiki page(or another one) where links to their public repos along with the functionality they bring to the table and all other info required are added. I do realize that this solution still has some fragmentation attached to it which is mostly added by git's distributed nature(though this is also one of its main strengths), but this can be resolved by helping minimize the learning curve. I welcome any improvements to the above. With this solution the development flow is limited to committing and advertising repos(and patches for the stubborn), the integration flow is limited to pulling and merging(and patching+commit for the stubborn), and the user flow is limited to cloning at most. -- User Joe to john-dev mailing list: Hey,, There's rumor flying around that JtR can crack bcrypt() passwords now, where can I grab that? Regards, UserJoe Reply: Hey UserJoe, Unfortunately, cracking bcrypt() passwords is not available in the official JtR at the moment, however you can grab a Jumbo version of Jtr that does that from here: git clone git.openwall.org/john-jumbo git checkout bcrypt ./configure make ./john --- 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.] Since people tend to be lazy when it comes to documentation and such by nature, another proper approach would be to create something similar to nmap-svn mailing list, where commit e-mail messages are sent every time a commit is pushed to an important repo(with commit msg and diff). Openwall could have that for the 1. and 2. git repos, however, I don't know how that can be achieved with git(nmap uses svn, though most surely possible, at least with hooks).*insert research here*. Now to cool off the possible *rudeness* interpretation at the start of the e-mail, it was on purpose, in order to grab attention. Besides that, there's no perfect wording, other then the one taken, if I'm going to impersonate an average Joe anyway. :-) Regards, Shinnok
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.