[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTimv5rY7LT=MZoy=hmWizA=sH70hTg@mail.gmail.com>
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.
