Date: Fri, 20 Jul 2012 08:52:25 +0200 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Re: RFC: add more information to --list=build-info output? On 07/19/2012 05:58 PM, jfoug wrote: >> On 07/19/2012 10:36 AM, Frank Dittrich wrote: >> >> Nevertheless, a --list=run-time-info can be useful. >> Various library versions, CPU info, OS and version, available memory, >> locale setting (LANG=en_US.UTF-8 / LC_ALL=C) ... > > I fully agree with this. It might also be good to simply do: > > --list=john-system-info > > That has a 'build-info' section, and a 'run-time-info' section, and have it > all show up on one run. > > That way, if a user is having problems, he could simply be asked to use: > > run/john --list=john-system-info This is a good idea, because it makes it easier for developers to ask for relevant information (and for users to provide this information). But the option could just as well be names --list=system-info. I didn't add --list=run-time-info and/or --list=[john-]system-info, because in my local tree the john_list_options() changed doe to my implementation of sections, parameters:SECTION, list-data:SECTION, and I don't want to do merge in my local branches which I can easily avoid by postponing the next change until my previous patches have been applied. (Who is going to apply the patches? Do we have to wait for magnum?) The attached --list=build-info change shouldn't produce conflicts with any other pending commits, and should apply cleanly to 1.7.9-jumbo-6-fixes, magnum-jumbo, bleeding-jumbo. This is now the last line of --list=build-info output (after printing compiler information): OpenSSL library version: 10000003 If the version of the OpenSSL library loaded at run time differs from the compile time version, the line looks similar to this one: OpenSSL library version: 10000003 (loaded: 10000003) (except that both numbers would differ, of course). For the run time information, I intend to write something like OpenSSL library version: 10000003 or OpenSSL library version: 10000003 (built with: 10000003) followed by lines printing more verbose / human readable information provided by SSLeay_version(), see man 3 SSLeay_version. And --list=[john-]system-information should just print a heading *BUILD* *INFORMATION* followed by the output of ---list=build-info (needs to be moved into a separate function john_list_build_info()), then an empty line, then the next heading *RUN* *TIME* *INFORMATION* followed by the output of --list=run-time-info (which will also be a separate function john_list_run_time_info()). > and reply to the email chain with that information. It could show it all. > The build params, the runtime loaded modules (even an ldd on john would be > 'possible' for some systems), and the machine environment (CPU, MEM, os > name/ver, etc). > > But I do think this would be helpful. It may not be the smallest task, > since some of that information may be hard to obtain if the OS does not > provide tools to do it (like uname or ways to get mem, etc). Yes, some of these features will be tricky to implement. Even if we find a way to get version information for other libraries: We can't even be sure that these libraries exist. That's why I put the OpenSSL version information at the end of the --list=build-info output and even flushed the output buffers before attempting to call SSLeay(). OpenSSL will very likely exist at least in each Linux distribution. For other libraries, or for Windows and other operating systems, we can't be sure. Is my current approach acceptable? What else could I do to make sure I don't try to test the OpenSSL library version if that library doesn't exist? On a related note: I added #include <openssl/crypto.h> to john.c. May be my current approach is not such a good idea (at least not if the same approach will later be used for other libraries). I think I shouldn't print OPENSSL_VERSION_NUMBER if OPENSSL_VERSION_NUMBER is defined. I should only print it if the john build in question makes use of the OpenSSL library. So we might need to define _JTR_USES_OPENSSL (or whatever) for each run time library we really depend on, and check these definitions before attempting to access version information. May be we even need to distinguish dynamic and static linking, because the run time info is irrelevant if the library will not be loaded dynamically. As long as just one library version (OpenSSL) is checked, this is not that much of a problem, because even if this fails, all the other relevant information has been printed. Nevertheless, can someone test what happens on a Windows or MacOS system with this patch applied? Frank View attachment "0001-Add-OpenSSL-version-info-to-list-build-info.patch" of type "text/x-patch" (1356 bytes)
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.