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.