Re: nmap says “variable 'keys' is not declared” trying to run ssl-ccs-injection.nse

[nnposter () users sourceforge net]

Daniel Miller wrote:
> To the list at large:
>
> This issue is one that I would like to see fixed in a larger context. We
> link publicly to our development-version scripts, but in many cases
> (Windows in particular), users are not easily able to run the development
> version of Nmap. I see a few possibilities, and I'd like to solicit your
> opinions:
>
> 1. We can work on developing an automated build capability for the binary
> packages we distribute, and offer those for download as a "nightly
> snapshot." This would be a good thing in terms of stability, since breakage
> would be more evident sooner, and users on multiple platforms could more
> easily test without an explicit beta release. But it would also mean more
> bandwidth usage and the costs involved in running multiple build platforms
> for hours every day.
>
> 2. We can split the Nmap development tree to have a "stable" and a
> "development" branch. The NSEDoc portal would link to the stable branch,
> and we could still backport fixes and new, hot scripts from the development
> branch as needed. This would mean extra work, though, and it's likely that
> the stable branch would just stagnate until a release.
>
> 3. On a very related note, we could resurrect the nmap-update project as a
> distribution platform for non-recompile changes to NSE scripts and
> libraries and Nmap datafiles. This involves pretty much all the same work
> as the last suggestion, but with a more explicit responsibility to keep
> both branches updated.
>
> I'm sure there are other options. I've made efforts in the past to ensure
> that newly popular scripts (like ssl-poodle, ssl-heartbleed, etc.) are
> backwards compatible with older releases, but this is tedious and clutters
> up the scripts with hacks and FIXMEs.

First of all I must admit that I have no idea about the process behind
determining and producing nmap releases so I have no appreciation of
all the specific constraints and costs that need to be accounted for.

On a general level it seems to me that it would perhaps make sense
to link the main, publicly-facing documentation to the most current
release because the prevailing consumers of this information are likely
release-based nmap users. The contributors that are tinkering with the
scripts and need to see the bleeding information should always use the
actual source code instead of the nsedoc. Similarly the people that are
willing to pull SVN snapshots should be reasonably comfortable looking
at the scripts.

That said, having more frequent releases, perhaps every two months or
quarterly, could go a long way towards keeping the general user
population current while reducing the amount of documentation
discrepancy between the latest release and development codebases. It
would also cut down on the level of effort and code pollution by
making scripts backward compatible.


Cheers,
nnposter
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/