[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
