Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 May 2012 00:14:45 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: file synchronization backend for MJohn

I thought about some possibilities to utilize existing tools for file
synchronization between server and users.

There are some actions with files during collaborative cracking
(thinking as client, download means 'from server', upload - 'to
server'): to download recent .pot and/or not yet cracked hashes list,
to upload our newly cracked passwords, to upload and download files
for attacks.

Files for attacks include wordlists, configuration files, session
files, maybe program to generate candidates or more likely set of
candidates. (We could also transfer john itself to client but it seems
unnatural for me.) Are there any other files for attacks?

I think files for attacks seems to be easy because they are not likely
to be modified on different machines at the same time. So we may not
care about them. Though general mechanism could be applied for them too.

I looked over a big list of debian packages found by words 'sync' and
'file' and considered that to check everything is not worth the time.
So I have two candidates: git (or maybe other scm) and rsync.

Let's compare .pot mangling using these tools. I may be wrong here so
please fix me. Both of the tools could limit traffic to only
differences in versions. But both tools could not handle simultaneous
changes to .pot: rsync at all, git asks to fix conflict. Am I right?
Are there tools that could do what is needed more easily?

Looking deeply in git I found that the conflict could be easily fixed:
git inserts lines '<<<<<<< HEAD', '=======' and '>>>>>>> <commit_id>'
into file, these lines could be easily replaced by one sed call, also
git inserts new lines from file that are ok as is. Though I think it
is rather a hack but it could work and it may be hard to do it better.
So I will try to use it first.

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.