Date: Mon, 19 Sep 2011 19:58:02 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Patch for dynamically loaded formats David, I finally took a closer look at your stuff (john_1.7.8.jumbo6.plugin.diff and jtr_vms_2-3.zip on the wiki). On Mon, Sep 05, 2011 at 11:55:04PM -0400, David Jones wrote: > Actually, I wasn't aware of compile-time plugins. I did the initial work for this enhancment a couple years ago on John 220.127.116.11, and earlier this summer decided to revisit it to update it for the official 1.7.8 release, not -jumbo. It appears the compile-time stuff assumes the module is a single source file, I have to consolidate 5 or so source files to follow that format. The project also includes a piece that lives on OpenVMS, i.e. the uaf_to_passwd program to convert the native password hash data to a ciphertext suitable for JtR to process. I think this would be best integrated into -jumbo fully, not even as a compile-time plugin. Then you don't need to merge any source files. uaf_to_passwd should probably become uaf2john, and be compiled/installed alongside ssh2john, etc. If it may only be compiled on VMS natively (I did not verify if this is the case or not), then only refer to it from the proper DCL scripts. You're not using the Makefile when building on VMS, right? A drawback is that we lose the test case for runtime plugins, but perhaps we can provide a sample one, just to show how this is done - for use by people preparing further plugins for stuff that's not in -jumbo at the time? We can't afford making pthreads mandatory, but your code appears to support building without pthreads as well, correct? > The module is naturally multi-threaded, but I disabled it We're currently using OpenMP and not explicit pthreads elsewhere in JtR, so it'd be best to use that. But we can make this change later (after integration of your code). > since I didn't know a simple way to test for the presence of pthread support. Assuming that you don't switch to using OpenMP yet, you can replace your NOPTHREADS with HAVE_PTHREADS (the opposite meaning), then add -lpthread -DHAVE_PTHREADS only in make targets where pthreads are known to be available (since we use a make target per target platform). Overall, I feel that you should have contributed your stuff earlier - before adding parallelization, etc. Then it would be easier to integrate and then update incrementally. But let's try to integrate what you already have. BTW, in vms_fmt.c you set MIN_KEYS_PER_CRYPT to SINGLE_HASH_MIN. This looks wrong to me: for "single crack" mode, the equivalent of this is done automatically, and for other modes the value of SINGLE_HASH_MIN is irrelevant. If your code reasonably supports MIN_KEYS_PER_CRYPT of as low as 1, just set it to that. Or set it to the number of threads, when applicable. Also, I think you shouldn't be setting FMT_BS - you don't have a bitslice implementation there. Regarding "FMT_CASE | FMT_8_BIT", are you only supporting a hash type for which this is right? As your aaareadme.txt says, some VMS hash types were not case-sensitive - are you not supporting those? I think it'd be best to integrate support for them as well (using Jean-loup Gailly's code?), but as separate formats (so that we can set the flags right). What do you think? Indeed, we can and should integrate any extras like this separately. Oh, and many source files say that they are copyrighted by me (as well as by you), but I don't recognize any of the code in them as mine. If this is just for the overall source file structure (such as what kinds of functions are defined and in what order), then I think this is not subject to copyright - so let's drop those notices (keep the files copyrighted by you only). Thanks, 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.