RE: [RFC] Username/Password NSE library

["Thomas Buchanan" <TBuchanan () thecompassgrp net>]

> -----Original Message-----
> From: nmap-dev-bounces () insecure org 
> [mailto:nmap-dev-bounces () insecure org] On Behalf Of Patrick Donnelly
> Sent: Wednesday, June 25, 2008 1:12 PM
> To: Kris Katterjohn; nmap-dev () insecure org
> Subject: Re: [RFC] Username/Password NSE library
>
>
> It doesn't really return the table with the intent of sharing it with
> the caller, just so the for loop can iterate over it. The main
> advantage to this is the memory reaches a steady state; no new
> closures or tables are made in a call to the library.

Patrick,

Can you explain a little more about the memory impact of a closure vs.
your for-loop table return?  I have to admit I know almost nothing about
the underlying code, but as an amateur scriptwriter, I find the
flexibility of the closure has quite a bit of appeal.  Here's a couple
of examples where it doesn't feel natural to me to use a for loop:

1.  Testing for a specific amount of time.  I would envision a while
loop that checks against some timer for each iteration, and returns
either when the list of usernames/passwords is complete, or if the timer
expires.

2.  Imagine a service that returns a different error code for "unknown
user" vs. "invalid password".  We loop through usernames until we get
that magical "invalid password" code, then begin testing passwords with
that username. 

Now, it's quite probable that you could accomplish both of these with a
for loop, but it wouldn't be the first approach that I think of.

However, if there is a significant performance benefit to the for-loop
structure, then maybe we should sacrifice the flexibility of the
closure.  Another possibility might be to add your code to the library
as an alternative access method that is optimized for for-loops.

Thanks,

Thomas

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