Re: Updating scripts

[Patrick Donnelly <batrick () batbytes com>]

On Thu, Aug 19, 2010 at 6:45 AM, Martin Holst Swende <martin () swende se> wrote:
> On 08/19/2010 06:39 AM, Ron wrote:
> > Hi Martin,
> >
> > I love the idea, and it's something I've been pushing for for awhile. The biggest issue I see is that certain 
> > scripts require certain minimum levels of Nmap to run, and the interface between scripts and Nmap is still fairly 
> > fluid version to version. For example, we just added pre- and postrule functions.
> >
> > For this to work, scripts would have to include the minimum level of Nmap that they require to run. And maybe if a 
> > certain number of scripts are disabled due to version issues, it could print a warning that Nmap needs to be updated?
> I had not thought of that, but now that I do, I see two possible
> solutions. One is like you say, which perhaps would be something like
> the scripts having not only action and portrule, but also versionrule:
> #pseudo:
> function versionrule(ver)
>    return ver > 5.20
> end
> #Or, for a script which is deprecated/replaced for new nmap versions
> (but for some reason maintained for old ones):
> function versionrule(ver)
>    return ver > 5.20 and ver < 6.0
> end
> #-- Alternate way would be to not use version numbers, instead some kind
> of compile-time variables made accessible to nse:
> function versionrule(features)
>    return features["postrule"] =~nil
> end
> --
>
> The other solution that could be used could be to use named branches. If
> changes that affect NSE does not occur too frequently we could use named
> branches to update from. Whenever a major change occurs which makes new
> scripts not being able to be used on old nmap versions, the NSE
> changeset tree is branched, and the new branch gets a new name. The old
> nmap versions still fetch from the old named branch (which can still be
> maintained for a period if we wish) and only new nmap versions fetch
> from the most recent branch. I have not worked much with named branches
> in hg, but afaik this could work.

If this were to happen it wouldn't be a "versionrule". Ironically
enough we've considered adding such a rule but for a different reason.
A versionrule would encompass "version" category scripts. The idea
being that categories exist for *choosing* which scripts to run (at
the command line) while a "versionrule" would exist for *deciding
whether a given version script will run*. The reason for not using a
portrule for a version script would be to separate the two scan phases
correctly. That is, a version script will try to incorrectly run
during a normal NSE host/port scan in addition to the service scan
phase. This only happens if a user gives a "version" category to
--script in addition to -sV.

In any case, after that digression, if a script wants to check the
Nmap version it would be better to check some field in the nmap module
(like nmap.VERSION) and test during script loading (that is, in the
file level block). For example:

if nmap.VERSION < 5.20 then
  error "Nmap version out of date for this script"
end

function hostrule (host)
end

function action (host)
end


Or something similar. Some library support (i.e. from stdnse) would be
appropriate to wrap this behavior. If someone wants to take a stab at
it go right on ahead :).

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