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 must 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
- 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 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 Nmap SoC list or to Fyodor directly.
Status reports must be sent to the dev(a)nmap.org list every
Time. The first one is due on May 2, and the 17th (final)
one, which should mark the successful completion of your project, is
due on August 22. Since the program actually finishes on August 23, you may send the final status report on that date instead. While you may know exactly what you are
working on, these reports help 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 us document how great you are! Note
that you will be in the "community bonding" phase for the first four
reports, and you may still have school 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 status reports relate to research, meetings with your mentor, project timeline completion, etc. Full-time coding doesn't start until May 25.
The subject line should be "[Your name]'s Status Report - #N of 17"
where N, of course, is the week number. This helps to remind us how
much time we have left. Adding your name there helps track replies
since we usually have many SoC students. 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 for Chris - #6 of 10
Been working like crazy to get Ncat into a quasi-sane state. Seems to
be getting towards something resembling decent
now. Need.. more.. coffee..
* 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
* 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
* 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.