Lua 5.3 adds several awesome features of particular interest to nmap including
bitwise operators and integers, a utf8 library, and standard binary pack/unpack
functions.
In addition to adding Lua 5.3, this branch changes:
o Complete removal of the NSE bit library (in C), It has been replaced with
a new Lua library wrapping Lua 5.3's bit-wise operators.
o Complete removal of the NSE bin library (in C). It has been replaced with a
new Lua library wrapping Lua 5.3's string.pack|unpack functions.
o The bin.pack "B" format specifier (which has never worked correctly) is
unimplemented. All scripts/libraries which use it have been updated. Most
usage of this option was to allow string based bit-wise operations which are no
longer necessary now that Lua 5.3 provides integers and bit-wise operators.
o The base32/base64 libraries have been reimplemented using Lua 5.3's new
bitwise operators. (This library was the main user of the bin.pack "B" format
specifier.)
o A new "bits" library has been added for common bit hacks. Currently only has
a reverse function.
Thanks to David Fifield, Daniel Miller, Jacek Wielemborek, and Paulino
Calderon for testing this branch.
See http://seclists.org/nmap-dev/2012/q4/334 for why this wasn't really
a big problem. This solution is essentially how netcat-openbsd does it:
mkstemp creates the file and opens it, but then we just unlink it and
only use the returned name. Functionality is pretty much the same as the
tempnam version.
John Spencer reported that musl libc doesn't automatically include
<stdlib.h>, as Glibc does, so the configure check was wrongly failing.
conftest.c: In function 'main':
conftest.c:35:5: error: implicit declaration of function 'exit'
The lack of this was causing PCAP_IS_SUITABLE to fail on Arch Linux, at
least. I think that in some cases this caused both -L../libpcap and
-lpcap to be added to the linker line, which could cause an error
because of the need to link with -lnl. (We check for -lnl when
--with-libpcap=included is used (since r23163), but the PCAP_IS_SUITABLE
failure went around this check and allowed linking with the included
libpcap without checking whether -lnl is required.)
Here are reported build failures and responses:
http://seclists.org/nmap-dev/2011/q3/449http://seclists.org/nmap-dev/2011/q4/33http://seclists.org/nmap-dev/2012/q1/369
If you have trouble updating after this revision you need to follow
these instructions. You have probably just seen an error like this:
svn: URL 'svn://svn.insecure.org/nping' of existing directory 'nping'
does not match expected URL 'svn://svn.insecure.org/nmap/nping'
This is caused by the replacement of SVN externals.
Here's what you need to do. First, save any local changes you might have
in the nping, nsock, nbase, ncat, and zenmap directories. (For example
by running "cd nping; svn diff > ../nping.diff".) If you don't have any
local changes you can skip this step.
Then run these commands:
rm -rf nping/ nsock/ nbase/ ncat/ zenmap/
svn update
svn cleanup
If all else fails, you can just delete your whole working directory and
check out anew:
svn co --username guest --password "" svn://svn.insecure.org/nmap
There may be further discussion in the mailing list thread at
http://seclists.org/nmap-dev/2011/q4/303.
