Re: [RFC] Username/Password NSE library

["Patrick Donnelly" <batrick.donnelly () gmail com>]

On Wed, Jun 25, 2008 at 1:07 PM, Thomas Buchanan
> > 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.

It sounds like that could easily be done with an "if time_expired then
break end" statement.

> 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.

I envision that working like so:

for user in unpwdb.usernames() do
  for pass in unpwdb.passwords() do
    local ret = try_connect()
    if ret == "unkown user" then
      break;
    elseif ret == "got connection" then
    end
  end
end

> 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.

It is certainly ok to have both functionalities available. There isn't
a "significant" performance benefit. I want to emphasize my original
intention that I'm offering this because it seems a good solution to
the problem of looping over the table. The closure is perfectly
acceptable. It just seemed awkward to me and the generic for loop
offered (seemingly) what you guys were seeking.

Cheers,

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

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