Re: [RFC][PATCH] NSE version numbering

[Ron <ron () skullsecurity net>]

-----BEGIN PGP SIGNED MESSAGE-----
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?

Ron

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:
>   svn://svn.insecure.org/nmap-exp/djalal/nse_version_numbering.txt
>
> * The branch is at:
>   svn co --username guest --password "" \
>   svn://svn.insecure.org/nmap-exp/djalal/nse-version-numbering
>
> 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.
>  
>   Note:
>   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
>   behaviour.
>   Perhaps we should use the word "REVISION" instead of the word
>   "VERSION" ?
>
>   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).
>
> Notes:
> In all these situations when loading scripts Nmap and NSE should not
> fail.
>
> 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
>
> -- 
> tixxdz
> http://opendz.org
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk2Y2cQACgkQ2t2zxlt4g/SFGQCeID+GE6ud/ss5CEQlUHlG2x4N
/xsAoL5GLC1/6ARBKrC7L+LIHwcO5Gv0
=45bj
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/