[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150420202030.GA6159@openwall.com>
Date: Mon, 20 Apr 2015 23:20:31 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [RFC] Johnny further development proposal
Shinnok, Mathieu,
On Mon, Apr 20, 2015 at 10:47:06AM -0400, Mathieu Laprise wrote:
> Hey guys, here is my first draft timeline. I put it on gsoc website and in
> the list too. I'll appreciate any comments. Like Aleksey says, some tasks
> like jumbo support and 2*john conversion are not clear to me at the moment
> so I put more time into these activities.
>
> This timeline start on the* first week of may(during the community bounding
> period) and at version 1.4 since 1.2-1.3 have Shinnok name on the roadmap.*
> I'm not really experimented at planning so if something takes less time
> than planned, I'll start working on the next sprint. And if something takes
> WAY more time than planned, I'll take a moment to brainstorm about is this
> feature worth it or should we priorize another feature for the best of
> Johnny ?
>
> Sprint 1(week 1 and 2) : Get familiar with john the ripper doc and
> codebase. Code, integrate, test version 1.4 requirements . Translation is
> already advanced but proper threading will introduce new changes and bugs
> that I'll fix.
Threading is a pain and unneeded complexity. So I propose to not
implement it as long as we can. Is there an example of slowness
solvable by threading?
Version 1.4
1. Make sure all strings are translatable and add language switching
support [Mathieu]
2. Add tooltips to all UI actions that are not very self explanatory
to a new comer
3. Properly separate the CLI wrapper from the UI and proper
threading. Any delays or crashes at the CLI side shouldn't be
mirrored by Johnny
4. Rename Output tab to CLI journal and also print JtR cmds (allows
the user to inspect whatever commands Johnny issued to JtR as
well as the output)
Version 1.5
1. Add the –fork option to the UI so that we can use multi core
2. Manual plain-text guessing for individual ciphers (directly in
the table view)
3. Hash type suggestion/guessing for individual hashes (which is the
best way? do we have any support from JtR jumbo with that)
I'd mix sprint 1 and sprint 2 to get -fork earlier. 1.4.1 should not
be hard to finish. 1.4.2 may be interesting at the beginning to learn
Johnny. 1.4.3 may be hard to implement right at the beginning, also
examples of bad behaviour are needed.
1.4.4: I'd print commands that can be copy-pasted to term. It may be
tricky to implement because there should be proper quoting that
depends onto platform. Though "Ability to select/deselect individual
hashes" makes it less important.
1.5.1 may be started earlier. 1.5.2 is either small (and ok to be done
at that position) or overlaps with 1.6.2 (though in such form it
should be small too).
1.5.3 may need support from john. We need it anyway so I may implement
john's part. Though there is a pitfall: there are hashes with 1 format
in john, some hashes have several identical formats in john (several
implementations), while some hashes may be of different formats with
different passwords (md5u vs md5).
So I'd move 1.5.1 earlier and 1.4.3 later.
> Sprint 2(week 3 and 4) : Code, integrate, test version 1.5
> requirements . *Make
> builds for major platforms and send it to the list and johnny website.*
We don't really send releases itself to the list, only announces.
Johnny does not have a separate website. It is hosted on Openwall's
wiki:
http://openwall.info/wiki/john/johnny
> Sprint 3(week 5 and 6) : Prepare for sprint 4 and understand *2john
> conversion support(from 1.7). Think about a plan and show it to the list
> for approval. Code, integrate, test version 1.6 requirements.
I guess multiple pwd files session management is quite big task.
> Sprint 4 (week 7 and 8) : Code, integrate, test version 1.7 requirements .
>
> Sprint 5(week 9 and 10) : If 1.7 isn't finished, continue here. Also, make
> some refactoring(if needed) to Johnny, retest everything we have so far and
> prepare for next sprint and think about jumbo support. Which thing do we
> want to implement? is it possible ?what are the risks ? how will we do it ?
> Maybe make a prototype ? Start implementing version 1.8. *Make builds for
> major platforms and send it to the list and johnny website.*
>
> Sprint 6 (week 11 and 12) : Work really hard on version 1.8
I hope to split "jumbo support" and prioritize parts.
> Sprint 7 (week 13 and 14) : Work really hard on version 1.8. Start
> brainstorming with the list about distribution channels and supported
> platform to be ready for next sprint. *Make builds for major platforms and
> send it to the list and johnny website.*
>
> Sprint 8(week 14 and 15) : (Version 1.9) verify that everything build on
> all supported platforms, do some tests using VM from different platforms,
> fix platform specific bugs. Figure out distribution channel with the list.
>
> Sprint 9 (week 16 and 17) (Version 2.0) is released, I polish stuff and fix
> left bugs. A lot of testing.
>
> After GSOC : Gather feedback from people regarding version 2.0 and work
> part-time when school allows me on fixing them.
It is good that you're planning to maintain Johnny after GSoC too. We
appreciate it.
So far, I think the only real feedback is here:
http://openwall.com/lists/john-users/2013/03/14/1
1) No build for Mac OS X
2) No support for rar (rar2john should be called to get the hashes
from .rar file, so it is part of *2john task).
I think you'll need to include the text of points into your
application. Shinnok - right?
Of course my words may be discussed. Thanks!
--
Regards,
Aleksey Cherepanov
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.
