MentoringGamePlan

What it's like to be a Summer of Code mentor

Overall mentoring goals

This is my mentoring game plan for the Summer of Code 2008. It's here to help me collect my thoughts, and also for my students to read so they know that I take mentoring seriously and so they know where I'm coming from.

Vision

During the community bonding period I will help my students develop a vision of what their projects will look like at the end of the summer. This is especially important for Zenmap. In his Mentoring HOWTO Federico Mena-Quintero mentions four things a mentor needs: time, evaluation of his student's work, knowledge of the relevant code, and a vision. Here's what he says about vision:

"You must have a clear vision of what your student wants to accomplish. If you cannot see the finished 'product' in your mind, you won't be able to communicate clearly with your student."

Aside from the code, my vision for my students is at the end of the summer they will be experienced software engineers, with new skills they didn't have before.

Code review

I will devote time to reviewing my students' code. In addition, I want them to review each other's code and code that has already been written. This means I will subscribe to the commits list. I will have to write some reviews myself first to show what I expect.

I want to start during the community bonding period by having my student review parts of the existing code that I will assign. They may comment the code as they go and will write a brief report to the mailing list. By this I hope that they will gain familiarity with the code, will become accustomed to the process of doing review, and will solicit advice from the readers of the mailing list.

Testing

We should do automated unit testing in Zenmap, because it's fairly easy with the unittest module. See SplitQuotedTest in zenmapCore/NmapCommand.py for an example. I don't have a clear idea of what this would look like yet.

Zenmap

Do not assume that you have to maintain compatibility. In particular, Zenmap does not have to be compatible with Umit or Umit's data files, or even current versions of Zenmap. We don't necessarily have to hold on to ideas like scan tabs or separate hosts/services views. In my opinion, there are a lot of parts of the design that needs to be re-thought or eliminated. In my opinion, the sooner we get rid of these, the better. If they last for another summer it only makes things harder to change later.

Design issues to be examined

Part of my responsibility as a mentor is working with you to develop a shared vision. These are aspects of Zenmap that I think should be included in that vision.

Umit scan results (`.usr`) files

As far as I can tell, a USR file is the same as an Nmap XML file with the addition of some extra attributes in the root nmaprun element: profile, hint, scan_name, profile_name, options, nmap_output, target, annotation, and description. Perhaps we can build Zenmap-specific information into its own namespace, like Inkscape does with SVG.

The recent scans database

The recent scans database in ~/.zenmap/zenmap.db is not very useful. All it does is automatically save scans, which is a useful feature, but it could be implemented more usefully and transparently by an auto-saver that saves USR or XML files to the filesystem. You can investigate the database using the sqlite3 command-line program:

$ sqlite3 ~/.zenmap/zenmap.db
sqlite> .tables
scans
sqlite> .schema scans
CREATE TABLE scans (scans_id INTEGER PRIMARY KEY AUTOINCREMENT,
                                                  scan_name TEXT,
                                                  nmap_xml_output TEXT,
                                                  digest TEXT,
                                                  date INTEGER);
sqlite> select * from scans;
<lots of XML output>

You can see that each scan is saved in the database as raw XML, which needs to be further parsed. The scans aren't broken down in the database so you can't for example, ask it for all hosts across all scans with a certain port open, which would be really useful. If we could do that then the database would be worth having. Keep in mind that the database does not have to remain compatible.

Output tied to a single scan

I would like to see Zenmap's output respond to events, and not be tied down to the XML output of a single scan. This would be rad for the network mapping mode, because you could see hosts and connections pop up in real time as they are discovered, and conceivably you could select an intermediate node and run a port scan on it, even while the network mapping is going on, and have the results all aggregated together.

Scan profiles

Scan profiles are a good idea. It's nice to say "Intense Scan" and go. But with the current implementation, you have to have a profile for every scan. It's not easy to adjust a command line to add a single flag (you can do it, but you have to be careful not to click the Target or Profile boxes before you click "Scan", or your command will be erased). If you want to add a -T5 or remove a -v, you basically need another scan profile to do it. That's why Zenmap ships with both an "Operating System Detection" and a "Quick Operating System detection" profile. That approach doesn't scale.

Not every scan should be required to have a profile. I want to be able to type in scan options and run the scan, without selecting a profile or clicking through a wizard to create a new one. (Or even click partway through a wizard so I can "quickly create a command and run it once.")

An idea I had is that the scan profile doesn't have to be a persistent quality of a scan. Selecting a profile can be a one-time thing that sets a bunch of flags and then allows you to edit the command. The user interface could show something like "Set command from profile".

I don't like having to use the wizard to create a new profile. I want a feature where I can type in a command line and then do "Save as new profile." One reason for that is I may want to run a bunch of scans to see how they work and then save the one I like.

"Novice" and "expert" modes

I would like to see this go away. When you open the command wizard you have to choose if you are a novice or an expert. If you choose "expert," you are taken to the profile editor (as if you had done a "New Profile" from the menu), which is confusing and redundant. If you choose "novice," you click through a long wizard (where you annoyingly have to think of a name before doing anything else) to pick your scan options. The only difference between that and the profile editor (expert mode) is you get to choose from fewer options, and you're forced to look at every option in novice mode because of its wizard nature, where the profile editor organizes option groups into tabs.

What I would like to see is "novice mode" be something like the current profile editor, and "expert mode" having you just type in a command line. Except there would be no reason for a distinction in the interface, because you should always be able to type in a command instantly. Thus there would be need for the terms "novice" and "expert."

(To see what options are different between novice and expert mode, do diff -u share/zenmap/misc/wizard.xml share/zenmap/misc/profile_editor.xml in the Zenmap source tree. The two files are so similar that I don't think the distinction is helpful.)

Search interface

Zenmap search is hard to use. Try clicking the "OS class" combo box and you'll see hundreds of unsorted OS classifications. It should at least let you select a classification piecewise like the online submitter, if the search dialog is not totally redone.

Also I believe it is a bit ugly behind the scenes. I think it creates and parses a temporary XML file for each entry in the recent scans database.

Feature creeping

I already have a good vision of what I want out of one part of this project: the OS integrator assistant requirements. It's my duty to communicate this vision clearly, and be open to changes that my student may suggest. For the rest, I suppose I should look through the TODO and find tasks that my student is willing to do, with the understanding that, at the end of the summer, Nmap is going to do those things.

Schedule

This includes the official Google schedule and other dates I have set.

April 27–May 3: Initial meetings and timeline development. Assign source files for code review.
May 5: Student timelines completed and committed to Subversion.
June 22–28: David away.
July 7–July 14: Send midterm evaluations.
July 14: Requirements/design documents for proposed Zenmap features finished.
August 11: Suggested "pencils down" date.
August 12–18: Vladimir away.
August 18: End of coding.
August 18–September 1: Send final evaluations.
September 3: Submit final code samples.