Nmap Development mailing list archives
Re: [RFC] Username/Password NSE library
From: Kris Katterjohn <katterjohn () gmail com>
Date: Wed, 25 Jun 2008 14:11:18 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick Donnelly wrote:
On Wed, Jun 25, 2008 at 10:23 AM, Kris Katterjohn <katterjohn () gmail com> wrote:I understand this, I was merely pointing out that the closure was the method of choice. I mentioned it initially[1], and nobody seemed to think that returning a table was better[2][3]. But, like I said, if returning a table is now the desired functionality, then your changes seem fine.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.
Responses like this would've been great a week ago :) Pure playfulness aside, returning the table like this is good for loops like the examples you and Thomas present, but will it be as simple as a closure if you're not in this specific type of loop? One of the main points IMO for the closure is the fact that you don't have to keep track of where you are in the list, you just call it again to get the next entry. Only one closure is needed for each list, which should be a max of two per script since Thomas' idea of being able to rewind the list. So I don't think this is too much overhead for being able to loop over the whole list, or pick and choose at any time without having to keep track of indexes or whathaveyou. I'm not going to pretend to know what everybody will be doing with this library in their scripts, but I don't want to restrict them, or cause them to have to keep track of more than they need to.
I have run into one problem which I didn't test last night: giving the library a non-existent filename. Rather than returning false and giving the caller an error message like mine did, or returning the error message like I assume yours is supposed to do[4], I get this rather nasty looking error message: SCRIPT ENGINE: error while initializing script rules: ./nselib/unpwdb.lua:29: bad argument #1 to 'lines' (none: No such file or directory) stack traceback: [C]: in function 'lines' ./nselib/unpwdb.lua:29: in main chunk [C]: in function 'require' ./scripts/unpwdbtest.nse:7: in main chunk [C]: ? [C]: ?This was just another design choice I added in. I don't feel the try/catch mechanism is suitable for something like this. The act of requiring the module (ex)(im)plicitly states a level of reliance. If the module cannot get a database it can't do anything useful and should therefore fail immediately.
But I don't think it should spew a bunch of crap on the screen when the script can easily be told of the problem and it can return silently, or do whatever else it thinks is appropriate (such as letting the user know of the problem). Maybe a simple, one-line debug message can be printed from the library for notification.
I also would suggest moving the module() call after loading the databases (where the module can error). If we allow the module to error, we do not want the call made before any errors. module() changes package.loaded to the library's table and will cause subsequent calls to require (by other threads) to return an empty library table. Hope that helps,
Thanks, Kris Katterjohn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSGKYVf9K37xXYl36AQKKLg//RNle+p6NSdBIZzHcbRAPI0GINzMjOJ08 1LM9ec+bHKOTeWlDq87LJ/9ORj72lT79e8NysS16XHSbMygmVKeVEruIuJ2S4pNu ekvfUOjB5h+vBP0jg0qWlVsvEJ7EaWM8N2M9T1u74mEbNEs5HsFi0Sry/xRVKdOr mZ4fdccRaiPSRaKA425YoDiP00vXfGsvvUdxO8FlBgHRaAeQpQufx0GpIFYLfV5u PHXUUxn1T7ynj6QnV5wO1aXkS088Pb8uatClPa9IH6ND0AaNwhf1tT4LQZte03D4 UXy3rbQOpd2MZgK9LB49LD/I6zRjWSDAh4JVkleBipOpe18i+qXaO6PekQf0ejYp ZQckOmXNsbdVnTsC0FQDfdk6mTdo/xRZeyrll5Kly7XprnzHP/UJqnTVoH+6ZFgE 5jAYbMdEyZCCH2kDEFkThpIChx/AOm+TBdB7F1BU7akEDhzGINj8rBTKjwNgURQC 3cytVxTjDBU41llFmocABGzVsoU+1ML8uRusHaHPZiBaRzU66dZ3Fl10Jm+svUDt y7RVGGDZP5BcAqcvFuxzo4cGBA2VTeCh7h3UkR9mHwar1Ycc9Gai8VnZ8l6EwZ5H r9EYxzo5OMOnJlUHZjKY1X8sUB3MtX0Fe5ML5aI21BllP+f5C6udak7EHlkb07/k 7sDLvjCTowA= =EHbe -----END PGP SIGNATURE----- _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Re: [RFC] Username/Password NSE library, (continued)
- Re: [RFC] Username/Password NSE library Philip Pickering (Jun 18)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 24)
- RE: [RFC] Username/Password NSE library Thomas Buchanan (Jun 24)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 24)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 24)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- RE: [RFC] Username/Password NSE library Thomas Buchanan (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)