[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110222064115.GA17358@openwall.com>
Date: Tue, 22 Feb 2011 09:41:15 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Absolute latest version and patches?
> On 02/21/2011 10:42 PM, definitely crashing wrote:
> > Is there a reason that nobody has migrated the codebase to Git?
We're likely to get jumbo (and then perhaps branches of it) into a
repository. I just haven't decided on the details yet and haven't done
it yet. Some options are: use branches for Owl/packages/john in the
existing CVS repository (which holds the official JtR), use a separate
module in the same CVS repository (reuse the "infrastructure", but don't
"mix" with Owl and official JtR otherwise), setup a separate repository
and make it git.
> > Hasn't it
> > gotten a little too difficult to follow all of the patches and sequences to
> > apply and other bleeding-edge stuff that would be so well handled by Git?
On Mon, Feb 21, 2011 at 11:15:46PM +0000, Simon John wrote:
> I was just thinking the same the other day - all of these patches are
> getting a bit unmanageable now.
Maybe, or maybe not, but I think you're over-estimating the benefits of
git as it relates to this. I'd expect similar questions about the
"absolute latest version" when we have several branches in git, as
compared to when we have several patches (some of them incompatible, so
there's no "absolute latest version" in that sense).
> For 1.7.6 we have jumbo 12 and a further 3 patches on top and a manual
Some of this will be addressed with the next jumbo patch update.
Of course, new patches will keep being submitted. And that's fine.
No one is forced to use all patches. It is OK to wait for jumbo
updates. In fact, I started putting out full jumbo tarballs - it can't
get any easier (in terms of getting source code over a not-too-slow
link), can it?
What's the "absolute latest version" of the Linux kernel? Does it
include all patches ever posted to LKML? Is it a mix of all branches in
git? That's nonsense. And git does not "resolve" it, because the
"problem" is by far not just about merging changes.
To be fair, Robert's actual question did make sense, as it relates to
JtR at this time and excluding the parallelization patches.
> hack to add hmailserver support as it won't patch cleanly anymore.
Who needs it anyway?
I mean, I am grateful that this patch exists (for those few who need
this support) and I might get it merged eventually (likely along with
"own" SHA-256 and SHA-512 code), but this does not mean you have to
spend time to include it in every build you make now. Chances are that
no one will make use of that feature in your builds anyway.
If you like, you could submit a patch merging hmailserver support into
jumbo in a way that lets this be enabled from the Makefile (and keep it
disabled by default not to require newer OpenSSL than jumbo requires
currently). Then I'll include that patch (if it's done cleanly) in the
next jumbo update. This (and not git) will deal with having to merge
changes between these two patches going forward.
> Plus, if you want to use omp-des-7 we lose a massive amount of
> functionality and have to apply at least one patch that is already part
> of the jumbo's.
There are good reasons why omp-des-7 is not in jumbo, and why omp-des-4
is still on the wiki (not just omp-des-7). These patches could
potentially be merged into jumbo with lots of #ifdef's to allow all
reasonable build modes, but I am not sure that this would be such a good
move to take. Either way, git would be of no help with such merging -
it's manual work to do.
> If we moved to git it would at least [probably] make merging changes
> back into the trunk a bit easier - we wouldn't have to apply patches in
> a specific order and wouldn't have to develop patches for a specific
> version that won't work on any other version.
Yes, maybe, but that's only a small portion of the effort involved and
questions raised.
For example, it was not hard to update bartavelle's intrinsics patch
from jumbo-6 to jumbo-12 to make it apply cleanly again. However, that
resulted in failing self-tests, so then there was more work for
bartavelle to do. So it was not something an "end-user" would
successfully do anyway.
> Here's dreaming of a 1.7.7 with jumbo13+ompdes7 merged together ;-)
I'm not sure this is such a great idea, but I'll continue to think of
ways to reduce the number of different reasonable versions/builds that
people may want to use. For the DES/OpenMP stuff, I think it should be
completed and merged into the official JtR rather than into jumbo (and
it will also be available in jumbo builds in that way). By "completing"
it I mean several things, including figuring out and resolving the
omp-des-4 vs. omp-des-7 multi-salt performance mystery (7 is not
supposed to be any slower than 4, but it is) and making the code more
generic (e.g., the new DES key setup code should be implemented not only
for SSE2, like it is in omp-des-7, but also in a generic pure C fashion
and with other supported intrinsics).
Of course, as long as the project evolves there will always be some
experimental stuff that's not merged yet...
Alexander
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.
