General Nmap SoC Requirements

To help implement this program successfully, there are some general requirements that apply to all Nmap projects sponsored as part of the Google Summer of Code. If you have questions or concerns about these, please let us know before accepting a stipend:

You need to have sufficient time available. Since the program is so short and most of the tasks are quite challenging, you need to have 25–40 hours available just about every week. While it is possible for some extraordinarily motivated students to balance this with a full-time job or class schedule, we don't recommend it. The point of the program is to excite students about open source programming, not to burn them out :).
You need to be self-motivated. You will be working from home (or wherever you want) and choosing your own work hours. We aren't going to be regularly nagging you to work harder. So you must motivate yourself to work hard and focus on solving the tasks at hand.
Copyright for code produced must be assigned to the Nmap project (Insecure.Com LLC) so we can release and distribute it under an open source license. Let us know before you integrate any third-party code or dependencies (libaries or whatever) so we can ensure license compatability (not to mention portability and build system compatability).
You need to be responsive to emails. Don't just disappear for a week or two. If you will be away for more than a few days due to a vacation or whatever, just let us know in advance so we can plan around it.
All projects must be well documented. Where man pages are appropriate (separate applications) they must be written in DocBook XML so that it is easy to convert to HTML or NROFF. You can use the Nmap man page XML as an example. For changes to Nmap itself, just update that Nmap XML file and include that diff with your code diff.
While projects aren't expected to be completely bug free, they should be production-ready by the end of the summer. We are looking for code that can actually be deployed by millions of people in or in conjunction with Nmap -- not just a proof of concept. Obviously code must be secure, clean, and maintainable.
Most development communication should take place on the nmap-dev mailing list. This allows the whole Nmap development community to contribute ideas, try out your code and send feedback, etc. SoC-specific administrative matters or personal issues are more apropriately sent the SoC list or to Fyodor directly.

Status reports must be sent to the nmap-dev(a)insecure.org list every Monday by 11:59PM Pacific Time. The first one is due on April 27th, and the 17th (final) one, which should mark the successful completion of your project, is due on August 17. While you may know exactly what you are working on, this helps us track and plan for what everyone is up to. It can also lead to students providing useful suggestions for each other. And Google will ask me at the end of the program what everyone accomplished -- these will help me document how great you are! Note that you will be in the "community bonding" phase for the first four reports, and may still have shchool and other obligations to deal with. So while it is great if you are able to get some coding in early, you aren't expected or required to do so. It is fine if all of your accomplishments in your first four status reports relate to research, meetings with your mentor, project timeline completion, etc. Full-time coding doesn't start until May 23.

The subject line should be "Status Report #N of 17" where N, of course, is the week number. This helps to remind us how much time we have left. The body should have an Accomplishments section listing what you did since the last SR, and a Priorities section listing your upcoming tasks. Feel free to be as detailed as you would like (especially if you are soliciting feedback from others). Here is an example from 2005:

Date: Thu, 04 Aug 2005 01:48:51 +0100
Subject: Status report #6 of 10

Hey all,

Been working like crazy to get Ncat into a quasi-sane state. Seems to
be getting towards something resembling decent
now. Need.. more.. coffee..

Accomplishments:

* Ncat decently uses the Nmap infrastructure libraries to connect
  to hosts and hopefully will be using them to listen soon, too.
* IPv4 and IPv6 support.
* TCP and UDP support.
* Will resolve and connect to a host.
* Neatly split source across multiple files and with ncat header, etc.
* --exec /foo/bar working.
* --exec "/bin/echo dynamic number of arguments" is working
  (which always bugged me about Netcat.)
* --sendonly working.
* --recvonly working.
* --listen is working (of a fashion). Hopefully I can incorporate nsock's
  wonderful select(), read/write handling features to handle the
  shuffling data around part of Ncat listen.
* Varying levels of verbosity, -v, -vv and -vvv to get code verbosity,
  connection verbosity, code & connection verbosity, respectively.
* Ncat is verbose via stderr, which doesn't get dup()'d by --exec,
  etc, so you can still see your error messages locally without them
  being redirected.
* Working argument parsing with getopt_long. --help, --version, etc
  is all finished, too.
* Made one or two error messages a little more understandable that arrive
  from nbase, such as for connection timeouts and connection refused.

Mini Ncat Example:

$ ncat -4 -vvv -u -e "/bin/echo hello world" localhost 5000

..is a fairly good usage example of Ncat in its current state :)

Connect to IPv4 localhost on UDP port 5000 and echo "hello world" to the
server side.

Priorities:

* Get --listen in a better state (preferrably using nsock)
  now that most of the connect details have been ironed out.
* Once listen is in a better state, --max-conns,
  --socks-server, --allow, --deny, etc can all be written
  based on that code.
* Get in contact with Fyodor now he's back from DefCon to
  have a look at the current code and also to talk about
  --listen with nsock, etc.
* Start to create more separate releases and keep a nice
  CHANGELOG, or similar.

Cheers,
Chris