Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Apr 2015 16:59:42 +0300
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: Shinnok <admin@...nnok.com>
Cc: john-dev@...ts.openwall.com
Subject: Re: [RFC] Johnny further development proposal

On Sat, Apr 18, 2015 at 05:42:12PM +0300, Aleksey Cherepanov wrote:
> On Sat, Apr 18, 2015 at 05:27:25PM +0300, Aleksey Cherepanov wrote:
> > On Sat, Apr 18, 2015 at 05:06:03PM +0300, Shinnok wrote:
> > > 
> > > > On Apr 18, 2015, at 4:36 PM, Aleksey Cherepanov <aleksey.4erepanov@...il.com> wrote:
> > > > 
> > > > Hi Shinnok,
> > > > 
> > > > On Sun, Apr 05, 2015 at 01:19:19PM +0300, Aleksey Cherepanov wrote:
> > > >> On Thu, Mar 26, 2015 at 05:09:21PM +0200, Shinnok wrote:
> > > >>> http://openwall.info/wiki/john/johnny-roadmap
> > > >> 
> > > >> I have some comments:
> > > > 
> > > > More comments:
> > > > 
> > > > Do you plan automated tests?
> > > 
> > > I'm inclined to say that automated tests is too far fetched for Johnny. Not even JtR has that(?), which would be the real beneficiary of such a test suite.
> > 
> > JtR does that. It has 1) self-tests, 2) test suit. Though tests are
> > limited: they check correctness of formats for good hashes, they cover
> > neither ui, nor wrong hashes. Though it may (or may not) be improved
> > by Kai Zhao during this summer.
> > 
> > > > 
> > > > It may be helpful to mark all points of the roadmap with complexity
> > > > estimation including marks about obviousness of solution. Well, maybe
> > > > it would be better to write possibilities right there with estimation
> > > > of maturity.
> > > 
> > > We think we are already working enough on process, maybe start focusing more on getting to write the actual code?
> > 
> > Please struggle with your temptation to not think through the tasks
> > before coding.
> > 
> > On wiki, I see
> > 
> > Version 1.7
> >  3. Figure out how to implement *2john conversion support and
> >     implement it
> > 
> > Version 1.8
> >  1. Jumbo support (this task needs an evaluation and a further
> >     breakdown)
> > 
> > In other proposals, I saw that students figure out things before the
> > coding period. Of course it is not fully possible to figure out
> > everything beforehand. And of course you may prepare a draft
> > implementation to "think" (though just non-formal description may be
> > enough). Nevertheless I think it would be useful to separate thinking
> > and coding periods to not come up with only drafts in the end. These
> > periods have very different expectation of resulting quality.
> 
> I think more attention and time should be invested into planning of
> jumbo and *2john tasks because they're most important there. So in
> tough words: the core of your roadmap is not thought well.
> 
> And I'd put these tasks earlier.

I am sorry. I did not get the idea that I have to cover these points.

> BTW
> Version 1.5
>  1. Add the –fork option to the UI so that we can use multi core
> -fork is not the only option for multi threading (openmp, mpi).

Solar Designer wrote:
MPI is not needed.  Only --fork and OpenMP, please.


Also he did wrote:

I'd like Johnny to learn to work with *2john, and then we need binaries
for OS X and Linux (new ones).  We'll need to have them tested across
versions/distros.

Also important is --fork support, and maybe some tweaks for OpenMP
support - e.g., in case Johnny itself competes with John for CPU, maybe
we'd have to run one fewer OpenMP thread? or we need to ensure Johnny's
CPU usage is so low that even with OpenMP the impact would be minimal.


And excerpt from jabber quick chat:

Solar Designer would like to see practical results right in the first
month of development. So we need to realize show-stoppers that prevent
Johnny from being popular now, fix them and bake releases every month
during GSoC, make binary builds and test them on various systems.


For me, it sounds too general. We need some work to convert these
guidelines into changes to your roadmap.

Thanks!

-- 
Regards,
Aleksey Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ