[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120713114919.GA3351@debian>
Date: Fri, 13 Jul 2012 15:49:19 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: Aleksey's status report #10
On Fri, Jul 13, 2012 at 12:54:10PM +0200, Frank Dittrich wrote:
> On 07/13/2012 11:19 AM, Aleksey Cherepanov wrote:
> > Frank, please, look onto the script.
>
> The daemon part:
>
> Maybe you need to add something like
>
> killall -s 1 john
>
> so that all currently running instances update the .rec/.log/.pot file.
> Otherwise you might push results that are (per default config settings)
> almost 10 minutes older than they needed to be.
>
> If a user has differently named executable files, e.g. a john-omp for
> formats where this makes sense), you'd need to remember the names of the
> executable files used by your attacks, and send a signal 1 to all of them.
> (Alternatively, if you can grab the process ID, you could also send the
> signal to individual processed.)
It makes sense. It would not be hard to implement but it could improve
monitoring and respective coordination.
In theory I could track pids and kill by pids but it is much harder.
Thinking about pids and status I caught myself on idea that I intended
to have a wrapper (with cli compatible with john) that would do
(transparent) distribution that probably would not have sighup
handler. I think I could assume that there would not be such wrappers.
But killall would not be a problem in any case (except windows).
> Also, unless I missed something, you'll currently use git add ... even
> if nothing changed compared to the previous time your daemon ran.
> (Most likely cause for that would be that the session finished, and you
> already committed and pushed its changes before.
> Should you somehow mark the attacks as finished when the .rec file
> disappeared (a session could also have been completed in a few seconds,
> so that you never found a .rec file for this particular session.
It says "Everything up-to-date" and does not commit or push anything
if files were not changed. So it adds changes by fact, i.e. only if
there are real changes (not just modified modification date on file).
By the way I realized that .rec files are not always portable: file
paths, especially absolute, are not portable. But I could replace all
paths with relative ones from the store's root. Though paths in
john.conf would be harder to change.
I missed that no .rec is the normal case. I assumed that it is always
presented like .log and .pot.
> Do we need to parse the end of the log file to see if the session
> completed or if it has been aborted?
I did not know how to distinguish finished session from just stuck.
But there is log. And session file disappears. Both ways does not seem
to be hard. I'd like to use both together.
Is .rec files wiped out not before pot is written? May we loose some
cracked password but think that session was ended?
> Could/should you skip the git push, if none of your git commit commands
> ended successful?
If there is not 'add' then `git commit` fails because I specify all
file names explicitly. If there are no commit then push does not do
anything. Though there could commit made by other instance (for
instance when creates new attack daemon sends status) but it does not
matter who invokes push. On the other hand there should not be fails
(except empty commits).
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.
