Nmap Development mailing list archives
Re: nmap in GSoC - student idea
From: David Fifield <david () bamsoftware com>
Date: Thu, 24 Mar 2011 12:28:08 -0700
On Wed, Mar 23, 2011 at 08:11:01AM +0530, Hiemanshu Sharma wrote:
So after looking completely in the way the GUI works, I have come with a few ideas and they are listed below.
Thanks for these ideas! It's good to see that you're putting a lot of thought into it.
1) Updating everything to current python and Qt (and also lay foundation for a python 3 port)
What do you mean by "current Python"? We use the most recent Python 2.6 and PyGTK as far as I know. We don't use Qt at all. If we move to Python 3, we would abandon the Python 2 code completely (unless we can make the same code work on both)--we don't want to maintain two copies of the program.
2) Adding a new save as option to save as HTML (fancy reports are cool)
This is a nice idea. We have documentation on making HTML reports from XML: http://nmap.org/book/output-formats-output-to-html.html#output-formats-html-permanent What do you think would be the best way to do this? Fork and call xsltproc? Or is there a convenient XSLT processor in Python?
3) Checking for targets in the GUI before even sending it to the backend (http://i.imgur.com/TOrRQ.png shouldn't happen, it should tell you even before it starts that its illegal)
This is a good idea. It can warn you (though color or whatever), but it must still allow you to run any command you want. Otherwise we have to duplicate all of Nmap's target parsing exactly in Python.
4) Also check for the options being sent to the console (this is something that can keep changing every version but the GUI should be patched to support the new options as well) http://i.imgur.com/eOHam.png
This is another one where it can warn you, but it must still run exactly the command you type. It should be possible to upgrade Nmap independently of Zenmap. We take extraordinary measures to handle unknown options intelligently in Zenmap: see zenmapCore/NmapOptions.py.
5) The tabs that are empty shouldn't be displayed
I'm not so sure. If I only see three tabs, for example, how will I know how to make the others appear? How will I know when all available tabs are displayed? Which tabs can be empty, anyway? Sometime Topology, while not exactly empty, shows only a single unhelpful dot if you don't enable traceroute. But the others always display something after running a single scan, correct?
6) Show the console output the current way but when scan is complete show the output in a new fancy window (with the current tabs and other stuff)
Can you make a mockup of this? It sounds like an interesting idea but I can't picture what you're describing.
7) Add options to show new scans in a new window or the current way (Preferences? )
Whether scans are shown in the same window indicates whether they are part of the same aggregation. http://nmap.org/book/zenmap-scanning.html#aggregation I admit this probably isn't very intuitive for people. Currently, the way to do what you describe is 1) New Window and 2) Scan. But I can see there being an option for where you want the scan to appear, like we have menu items "Open Scan" and "Open Scan in This Window".
8) "Where is my documentationz?" Currently there is no help that can be seen from the GUI (This is fine for *most* linux users, but imagine a windows user with no internet connection[doing a test on a internal network in his basement] will have no access to the documentation, the current man page can be put up in the help section, but it should be there)
I agree with you. We have a Help menu option, but it just shows a short HTML page directing you to online documentation. It's not completely true that there is no help inside the program. In the profile editor we have mouseover help for all the Nmap options. That help is stored in share/zenmap/misc/profile_editor.xml.
This is just a few changes that I think the GUI needs right now, I am sure there are a lot more stuff to be changed, but not all ideas don't occur instantly. Looking forward to hearing from you.
For more ideas, look in the file todo/nmap.txt for items tagged [Zenmap]. Two that I consider high-priority, that would be great to do this summer, are o [Zenmap] should actually parse and use script results. See http://seclists.org/nmap-dev/2010/q1/1108 o Make Zenmap settings get upgraded when the Zenmap executable is upgraded. The per-user configuration files such as scan_profile.usp and zenmap.conf are never overwritten once installed by Zenmap, so changes and fixes to those files don't reach anyone who has installed Zenmap already. This is most noticeable with changes to profiles and highlight definitions are notably affected. This fix may involve hard-coding settings that are not normally configured by users (like highlighting) or updating the per-user files at startup (only those parts that haven't been changed by the user). David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- nmap in GSoC - student idea Hiemanshu Sharma (Mar 21)
- Re: nmap in GSoC - student idea David Fifield (Mar 22)
- Re: nmap in GSoC - student idea Hiemanshu Sharma (Mar 22)
- Re: nmap in GSoC - student idea David Fifield (Mar 24)
- Re: nmap in GSoC - student idea Hiemanshu Sharma (Mar 25)
- Re: nmap in GSoC - student idea Hiemanshu Sharma (Mar 27)
- Re: nmap in GSoC - student idea Hiemanshu Sharma (Mar 27)
- Re: nmap in GSoC - student idea David Fifield (Mar 27)
- Re: nmap in GSoC - student idea Hiemanshu Sharma (Mar 27)
- Re: nmap in GSoC - student idea Hiemanshu Sharma (Mar 22)
- Re: nmap in GSoC - student idea David Fifield (Mar 22)