Nmap Development mailing list archives

Re: Weird target specifications


From: Fyodor <fyodor () insecure org>
Date: Fri, 20 Feb 2009 23:19:19 -0800

On Fri, Feb 20, 2009 at 09:05:26PM -0700, David Fifield wrote:
On Thu, Feb 19, 2009 at 03:51:37PM -0700, David Fifield wrote:
On Thu, Feb 19, 2009 at 02:07:09PM -0800, Fyodor wrote:

Is there any reason why these half-open and full-open ranges aren't
documented? Looking at the TargetGroup.cc code, support for them was
intentional and not just an artifact of parsing.

Sometimes we just forget to document features (particularly true of
ancient ones such as this).  Other times (rarely) a feature is
considered minor enough that it isn't worth documenting due to the
increase in complexity of the documentation.  But even if that was the
case for this sort of half-open ranges, the addition of full-open
ranges pushes it into deserving documentation, IMHO.

There are also times when we don't document a feature because it is
deprecated and we don't really want to encourage its use.  For
example, perhaps if we document the use of '-' as an octet wildcard,
we don't need to bother documenting '*' for the same purpose.
Unfortunately, neither is perfect.  '*' needs to be shell-escaped on
many systems, while David noted that '-' causes can cause problems at
the beginning of a specifier (Nmap thinks it is an option flag).

I'm not sure which one (or both) of those we should document.  I'm
leaning toward just documenting '-' though.  We just need to mention
that if '-' appears as the first character in the specifier, you just
need to prepend a zero.  Or if it is easy to modify the argument
parsing logic, perhaps we could fix the issue there (ignore this case
during option parsing) and so we don't have to bother users with it at
all.

Cheers,
-F

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


Current thread: