Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: [RFC][PATCH] NSE version numbering
From: Ron <ron () skullsecurity net>
Date: Sun, 3 Apr 2011 15:34:12 -0500

Hash: SHA1

Hey Djalal,

I think this idea sounds promising! Using the svn revision number is a good way of doing it. 

I think the key will be mapping different functions/libraries to the svn revision when they were introduced. I can see 
that getting out of hand or confusing very quickly. Do you have any ideas of how we can manage that in, perhaps, an 
automated way?

Nessus tends to just die if the version isn't high enough. 

A lot of C programs will reduce their own functionality or implement things inline using pre-compiler defines 
(sometimes in an automated way). 

Do you see a way to automate it? That is, a script that'll look through a .nse, match up a list of functions that are 
used against a list of when each one was introduced, then tell you what the minimum svn version is?


On Thu, 17 Mar 2011 14:32:47 +0100 Djalal Harouni <tixxdz () opendz org> wrote:
Hi list,

This is a second attempt to add version numbering to NSE.

* The following proposal can be found at:

* The branch is at:
  svn co --username guest --password "" \

To see the effect: ./nmap --datadir . --script=all
--script-args='strictnse' Comments and tests are welcome.

NSE Version Numbering:

o Introduction
o The version numbering scheme
o The proposed interface for NSE

o Introduction:
Lot of users have requested an automatic way to update NSE scripts [1]
and since lot of new features are added to NSE, updating scripts
without updating Nmap/NSE core can introduce incompatibility errors.

This is an attempt to introduce version numbering to NSE, in order to
identify and load/execute only supported scripts.

o The version numbering scheme:
As proposed by Patrick [2] the version numbering should be the
revision number in the repository, this will be "automatic".

How to extract the svn revision number:
o Unix/Mac OS X:
  * Releases and tarballs (svn info missing):
  Write the appropriate revision number manually to a file
'svn_revision' or use some external shell scripts (nmap-private-dev)
to do it. This 'svn_revision' file should be distributed with Nmap.

  * SVN info is available (developers):
  Use svn to extract the correct revision number.

  Note: the content of the 'svn_revision' file will take precedence
over the svn info when determining the appropriate revision number.

  A new shell script 'svn_revision.sh' called by make during build
will write the svn revision number (NSE version) to the
'nse_version.h' file. This file will not be under svn control.

o Windows:
  Need help.

o The proposed interface for NSE:
o Add a new special script argument to load only the supported
scripts. The special argument is 'strictnse', if specified then NSE
will be in the strict mode, which means load only the supported
scripts. This may change in the future and the default bahaviour of
NSE would be: "strict mode by default: load only supported scripts".

o Add a new Lua number field to scripts: "nse = $VERSION"
  If this field is specified, and if it's greater than the version
  of the current NSE, then a warnning will be printed and the script
  will be dropped, which means that users must update their Nmap/NSE
  core version, otherwise the script will be loaded normally.
  If NSE is not in the strict mode (no 'strictnse' argument) which is
  *currently* the default behaviour, then this field will be ignored
  (all scripts will be loaded).

  Script writers should use a new NSE version only when their scripts
  need/depend on a new feature that was just added to Nmap/NSE core,
  otherwise using the *same* NSE version that was specified in the
Nmap release should be fine.
  Nmap developers will announce on nmap-dev mailing list the revision
  of each committed patch.

o Add a new variable to stdnse.lua "stdnse.VERSION" which contains the
  current NSE version (Lua number), this way scripts can run normally
  and check this variable before requesting an unsupported function or
  Perhaps we should use the word "REVISION" instead of the word

  If this variable is nil that means that the build process has
failed to determin and to write the NSE version, in this case a
warning messsage will be printed, and all scripts will be loaded
normally, no strict mode. This should not happen, however we make
sure that Nmap and NSE don't fail if this happens (to let the
possiblity to run other scripts).

o Show or print if the script is *fully* supported by NSE or not.
  Perhaps show this info in the output of the new option
--script-help. (not implemented).

In all these situations when loading scripts Nmap and NSE should not

Updating NSE scripts and libraries will be discussed perhaps in the
next proposal :)

[1] http://seclists.org/nmap-dev/2010/q4/420
[2] http://seclists.org/nmap-dev/2010/q4/694

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
Version: GnuPG v1.4.9 (GNU/Linux)

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]