[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120520220202.GA31706@debian>
Date: Mon, 21 May 2012 02:02:02 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: file synchronization backend for MJohn
On Mon, May 21, 2012 at 01:29:30AM +0400, Aleksey Cherepanov wrote:
> On Sun, May 20, 2012 at 10:41:24PM +0200, Simon Marechal wrote:
> > On 05/20/2012 10:14 PM, Aleksey Cherepanov wrote:
> > > 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.
> >
> > Automatically resolving conflicts is exactly something you should not
> > do. Why not do it how it should be done ? When you can't push because
> > somebody else did just before you did, you can :
> > - force push, destroying everything that was pushed by others and just
> > be obnoxious, or
> > - pull, hope for an automatic resolution and push the merge, or
> > - fetch, rebase your patch and push.
>
> git rebase says that there is a conflict too. So in any case I should
> fix conflict somewhere. And as of I want to do it automatically for
> .pot file it would be better to do it on server as I said because on
> client it will born race condition because there could be new changes
> on the server between our rebase and push according to the third algo
> (as I could imagine; though maybe git could solve that somehow?).
> Right?
We could try to store file with pairs hash => password or nothing,
i.e. having just hash when we do not know password (or we could use
some non existing password to say that this hash is not cracked yet).
Then there should not be any conflicts. Conflict will show some
problem. But it could be slow and probably database would be better
for such approach.
> > I like the git approach because you can explain the reason of every
> > change in the commit log and link every change to someone. It helps a
> > lot for after action report.
>
> Yes, it could also be a nice resource of statistics.
>
> In general to look onto newly cracked password like onto patches for
> .pot file seems unnatural because cracked passwords are set and do not
> regard order while patches are order sensitive.
>
> Also there is a problem with distribution: while it seems ok to have
> git where humans work it seems too heavy for nodes in cluster. So we
> may consider to write something small and easy in c.
But git is not only a patch mangler it is also tool to connect to the
server, authorize and download, it supports ssl, users and all nice
things that "small and easy" thing in c should not support. Although
there should be ssh or something similar (it seems logical to have
such thing on node) that could compensate such limitations.
But it could be worth to think about a database for .pot related stuff
(it also could support ssl and users).
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.
