mailing list archives
RE: [RFC] Username/Password NSE library
From: "Thomas Buchanan" <TBuchanan () thecompassgrp net>
Date: Wed, 25 Jun 2008 14:07:33 -0500
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.
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
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
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.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org
Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 24)