Re: nmap in GSoC - student idea

[Hiemanshu Sharma <hiemanshu () gmail com>]

> > 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.
I am planning to redesign it in PyQt because for one the libs in GNOME 3 are
going to change, and you would have to maintain two copies for it if you
want to support both (Qt works on all 3 OSes much better than GTK does and
also supports mobile devices)
As for python 3, I am going to try and do the best to make the code
compatible between both python 2.7 and python 3.

> 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?
There are bindings for libxml and libxslt which should do the job.


> > 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.
Just a simple check which verifies the target, it shouldn't be too much code


> > 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.
This is one that needs a little more thinking and should be worked out


> > 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?
>
> For example the services tab is empty when you only do a ping scan, etc


> > 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.

Well I double checked this and the current setup of the GUI is just fine, it
doesn't need to be changed.


> > 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".
>
> Well yes there are going to be more options in the preferences. One of them
being if it should aggregate all the results together or keep them separate
.

> > 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.
>
> Yes but it should still display the current man page (this isnt
very intuitive and not everyone would know about this)

> 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


This seems like a very nice feature to add and use in Zenmap.

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).
Yes, I am looking at this right now, and the other stuff  that are tagged
for zenmap.

Regards,

-H
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/