[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110328143704.GB10755@openwall.com>
Date: Mon, 28 Mar 2011 18:37:04 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Interface for John
There were a couple of postings on Qt to john-dev recently:
http://www.openwall.com/lists/john-dev/2011/03/24/1
http://www.openwall.com/lists/john-dev/2011/03/27/2
Summary: Qt is within consideration, along with wxWidgets.
Shinnok's lengthy proposal (above) covers many other topics as well.
On Mon, Mar 28, 2011 at 05:16:45AM +0400, Aleksey Cherepanov wrote:
> I wrote a simple interface for John. It is not complete and is more an
> example of code rather than a real interface. It is available at
> http://code.google.com/p/aleksey/downloads/detail?name=john_simple_gui.001.py&can=2
I gave this a try under Fedora 13/x86_64 running in an OpenVZ container
on Owl (displaying to a remote X server - my desktop). It worked, with
the major limitations as per your description indeed.
I have mixed feelings about prototyping in wxPython before starting to
work on the real thing, but this approach is within consideration.
> I make a gui from the code but with WxWidgets it
> is also possible to use xml to define gui and there are tools to do it
> easily. For instance, wxGlade seems to be for WxWidgets like Glade for
> GTK providing a featurefull gui designer.
This approach has both pros and cons, but we may discuss it (on john-dev
since it is not something we need users' feedback on).
> During this small development i studied that there are wxCheckListBox
> that is a listbox which each element has checkbox in. Also i found that
> wxGrid has a way that is suggested for big amounts of data by
> documentation (wx2.8-doc/wx-manual.html/wx_wxgrid.html): "For
> applications with more complex data types or relationships, or for
> dealing with very large datasets, you should derive your own grid table
> class and pass a table object to the grid with wxGrid::SetTable."
Sounds good. Thank you for finding and sharing this.
> It should drows first time faster but for instance scrolling may be
> slow. But with so big table scrolling seems to me as about useless
> thing. To manage such tables it could more useful to have flexible
> filtering system.
Scrolling might be of little use for large tables, but it should not
lock the application up for a minute if accidentally invoked. Also,
scrolling a little bit up/down from a certain place makes sense (e.g.,
search for something, then see what's nearby).
Sorting and filtering are also nice to have. With sorting in place,
scrolling makes more sense.
> On other hand i faced a problem with parsing of John's output. I think
> about password as about untrusted data that is unpredictable (at least
> if a user is not restricted to brute only alphanumeric, for instance
> with its own algorithm that includes fancy charachters). Both filtering
> system and unpredictable input make me think about some sort of database
> to interchange with John.
Yes. If we choose the wrapper approach, yet want to process the results
(not just display them in a text viewer window), then we may implement
and use the proposed "--show=csv" mode.
> Also it may improve John's scalability. But
> changes in John and writing gui for that changes will make gui not
> compatible with any old versions of John that someone could value. Even
Maybe the GUI will need to probe for "--show=csv", but have a fallback,
or maybe this should be configurable. We can approach this later.
> with the right data exchange between John and gui there is a problem
> about how to show strange data in the ui. I could imagine problems with
> charachter encodings, exactly with bad utf-8 sequences.
Right.
> Also as i understood gui should bring new users to JtR but it is also
> needed to support all advanced features like very big hash files. Hence
> there should be a lot of settings. But they could afraid new users. So
> who is gui for firstly? If gui is for new users then it may be important
> to concentrate on a usability and work "out of the box" with many hints
> for new users rather than on advanced features.
We should be able to add advanced features once the basic functionality
is in place, but any advanced-only features should be in tabs, menus, or
whatever - not confusing new users. That said, just what advanced
features are you thinking of that would be confusing new users if not
"hidden"?
I don't see how supporting large data sets is a problem for new users.
It does not involve any extra setting.
Being able to produce pretty reports is not a confusing feature, and it
is useful to new users too.
Perhaps some of the features of the current command-line JtR may be
considered advanced and moved out of the main program window, though -
such as the "--salts" setting.
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.
