Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120615192525.GA12169@debian>
Date: Fri, 15 Jun 2012 23:25:25 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Aleksey's status report #8

I am sorry for yet another prolonged status report. I just finished my
diploma work. Now I will have enough time for my project.

Done

Nothing.

To do

>>>>> - Fix markup on the wiki page
>>>> 
>>>>>> - Draft implementation of client side


> - Look into other possible collaboration server side tool
- Compare them by speed

Alexander pointed me out that request tracker was slow some years ago.
So it could be uncomfortable to use it. Especially if we will have
automatic addition of tickets for each attack. So I need to do
stress tests for request tracker and other possible solutions.

>>>>> - Draft implementation of server side


>>>> - Research possible statistics and their importance
>>> 
>>> - Keep discussions

- Develop plan B for server side

It could be a real problem if during the contest we get a problem in a
server side. If server side is a big application borrowed from
somewhere then it is very likely to drop it right after the first
critical problem found so any problem will downgrade us to what we
have now.

There are some options: we could write our own small application which
problems could be fixed fast, we could test chosen application
extensively, we could have secondary parallel solution (maybe with
some integration with primary solution).

In any case we should test our application. But it is not possible to
catch everything. Also it is natural to add something experimental
right before the contest. So familiarity with chosen application is a
good thing. Also it is important to make system modular to increase
fail resistance.

Also our own implementation could be faster due to limited
functionality. So there is something to think about. Now request
tracker is the primary plan.

I would like to see the full system as soon as possible to be able to
make changes. So I think it is right to shrink my timeline several
times and then repeat it for improvements.

>> - Implement part of wrapper to send attack description

This point is the most valuable now.

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.