Re: Removing tcpsequence "class" attribute in Nmap XML output

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Fifield wrote:
> The attribute is always "unknown class". It no longer conveys
> information, so I want to get rid of it. I don't want to break
> applications that parse Nmap XML, though (I checked and Zenmap will need
> a small patch). So this is a warning that I plan to remove the
> attribute, and a request for anyone to correct me if I'm off base in
> removing it.

I agree that removing it would be good.  However, I too don't want
anything to break.

I'm biased because my Ruby Nmap::Parser doesn't have to be patched:
tcpsequence_class will just be nil.  And--assuming somebody actually
uses it--if tcpsequence_class were to be printed, it wouldn't break the
script:

puts "TCP Sequence Class: #{host.tcpsequence_class}"

would just print "TCP Sequence Class: " instead of failing.  This
doesn't mean nothing would break, just that this case is safe.

But the real question is: would the Perl Nmap::Parser and/or
Nmap::Scanner need to be patched themselves, or would just the scripts
need to be edited, or would it all just behave like mine above?

If they will break then I'd try to consider some other means, but I
don't know what that would be.  But then again, this is the 2nd Gen
system so things are different.

If the actual parsers don't need to be updated, then I say go for it.

Tough call :)

Overall, I'd say it's best to remove it since it's not actually used and
it's because a new(er) OS Detection system is in place.

> David Fifield

Thanks,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBR/72xf9K37xXYl36AQIrvg/+NZdAhjr3a6NWkniCp1fC9VZKIHo0lU7d
iLQb4JKjm1EB830b13v/kaJOdJDYlbmbG3YPBuelKqq41GRoA4L8n65lh2qL8Ywq
e5x2/Az/l+c+SLKP1iEqEj5McoxLvbfSJLagIGa1xjj8KnIk6WT6h+Q+e7u5/56r
SLYgkUfBm3WhoxcKwTuvLuxPVLT8um1OoC7alXlB9ILQ6Y16SQvvXDAdlUqfsZZh
SdX6mUrpc0VnRg+OpfQeR+MXWuGCVJXMc/X3B1B9QPHsp3VnsbpiSC5NeTUKBWsp
bIXUft2oAkhRoU009MAMFqzm03KfJDjmP4mpXeEc0HHnRLJWP3VFLyAyHWbNR3+p
mU8UvNtM/XoqQsvVZSIo0Yb22SLXHTlVfm/rhd87uWB6co5g9hmA+IK+6A73Ws5E
lwsyS4fJODfA0QYonRwtKTxS/fLDYQVOigP6nx8uU10VOLp2aHh5HQDgeXmsbr7p
nUKIUEkmX2FIq4CFFaEXOTPa8a78MdV0ICrRMsyj5ffAJ8FSBPuruYlwd3Kw67bO
Zp499ChWv2hpaZUZh5WHnSPlqb/UGzsO7doLp4KqB4jikjKElD9ZQfxQZDNJgTkj
tx4IaIpzN7/N/XWlUOmPrOMmCDRqXevX8hjFd1x1ncOoWBxA4YqQ+fTqUkpM/MUD
D0+9OtqTZYc=
=SdHK
-----END PGP SIGNATURE-----

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