Re: Google Summer of Code 2013 (Feature Creeper and Bug Wrangler)

[Usman Zaheer <usmanzaheer53 () gmail com>]

Hi David,
             First of all, thanks a lot for your feedback. I actually set
the milestones to the implementation of basic infrastructure (APIs) for NSE
to support various scan techniques.

Further, when I submitted my proposal last night, the formatting
(especially the white spaces), that I saw in Google's word processor didn't
actually show up in the final version of the proposal somehow which I got
to know this morning. I would be grateful if I am given the chance to
rectify the formatting of the document only.

Regards.
Usman Zaheer.


On Sat, May 4, 2013 at 10:43 AM, David Fifield <david () bamsoftware com>wrote:

> On Thu, May 02, 2013 at 07:58:01PM +0500, Usman Zaheer wrote:
> > (1) Firstly, regarding the "Exploring port scanning from within NSE"
> > project, I need suggestions about whether we are going to implement
> modules
> > in lua only as part of NSE modules? Further, as it turned out from a
> couple
> > of discussions at the Nmap IRC channel, we can potentially add a
> > script_port_scan phase between NSE prerule and portscan phase.
> Currently, I
> > am thinking about how and what can we leverage from the functions already
> > performed in portscan phase. Any further suggestions?
>
> I don't quite get what you're asking here. Port scanning from NSE will
> definitely require both Lua coding and C++ coding.
>
> > (2) Secondly, I am interested in the following idea from Nmap TODO which
> > was also discussed in Nmap mentors meeting and according to Fyodor it's
> > quite challenging and he was skeptical about assigning it as GSoc
> project.
> > "Consider re-architecting Nmap to have more of a scanning pipeline
> >
> > approach rather than fixed sets of hosts which start and finish one
> > phase and then move into the next in parallel.  This could potentially
> > allow us to add hosts one by one to a phase as other hosts finish that
> > phase and, ideally, the phases could run in parallel too."
> >
> > Although it was not decided in the Nmap meeting about whether this
> > project can be divided into smaller chunks, I will be glad to atleast
> > start some work on this during the summer and then continue with
> > completing it afterwards. Any suggestions about what can be the
> > possible smaller chunks?
>
> This project is, in my opinion, too big for someone without previous
> Nmap development experience. Design is harder than implementation. I'm
> afraid that if a new GSoC stuent works on this project, it will just be
> the mentor doing all the design, and the student not really
> understanding the reason for the changes.
>
> A reasonable beginning step would be to implement a proof of concept
> that, say, does port scanning against many hosts, without scanning more
> than 10 targets at a time, but also without breaking the input into
> chunks of 10 targets.
>
> > (3) Is it okay or too ambitious to aim for one of the following
> combinations:
> > (a) "Exploring port scanning from within NSE" + some part of the
> > project mentioned in (2).
> >
> > (b) "Exploring port scanning from within NSE" + "XML parser for NSE"
>
> I think both are too ambitious.
>
> > (4) Finally, because the "Exploring port scanning from within NSE"
> > project has some exploration part associated with it, will it be best
> > to provide time line of my tasks in terms of features implemented. (an
> > alternative could be to mention what I will be exploring/coding
> > potentially at different points in time approximately).
>
> Better milestones for this task are the delivery of running prototypes.
> It's too early to start thinking about features. Features are
> comparatively easy once the design is settled.
>
> David Fifield
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/