nmap man page lacks port state headlines

Bug #1684304 reported by Mikkel Kirkgaard Nielsen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nmap (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Triaged
Wishlist
Unassigned
Yakkety
Won't Fix
Wishlist
Unassigned

Bug Description

Something is wrong with rendering of the intended headlines of port states in chapter PORT SCANNING BASICS.

Viewing using man/info yields this where text is confusingly referring to missing state categories:

       The six port states recognized by Nmap

           An application is actively accepting TCP connections, UDP datagrams or SCTP associations on
           this port. Finding these is often the primary goal of port scanning. Security-minded people
           know that each open port is an avenue for attack. Attackers and pen-testers want to exploit
           the open ports, while administrators try to close or protect them with firewalls without
           thwarting legitimate users. Open ports are also interesting for non-security scans because
           they show services available for use on the network.

           A closed port is accessible (it receives and responds to Nmap probe packets), but there is
           no application listening on it. They can be helpful in showing that a host is up on an IP
           address (host discovery, or ping scanning), and as part of OS detection. Because closed
           ports are reachable, it may be worth scanning later in case some open up. Administrators may
           want to consider blocking such ports with a firewall. Then they would appear in the filtered
           state, discussed next.

Looking in the unrendered file show the intended headline (/usr/share/man/man1/nmap.1.gz):

\fBThe six port states recognized by Nmap\fR
.PP
.\" open port state open
.RS 4
An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port\&. F
inding these is often the primary goal of port scanning\&. Security\-minded people know that each open por
t is an avenue for attack\&. Attackers and pen\-testers want to exploit the open ports, while administrato
rs try to close or protect them with firewalls without thwarting legitimate users\&. Open ports are also i
nteresting for non\-security scans because they show services available for use on the network\&.
.RE
.PP
.\" closed port state closed
.RS 4
A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application
listening on it\&. They can be helpful in showing that a host is up on an IP address (host discovery, or p
ing scanning), and as part of OS detection\&. Because closed ports are reachable, it may be worth scanning
 later in case some open up\&. Administrators may want to consider blocking such ports with a firewall\&.
Then they would appear in the filtered state, discussed next\&.
.RE
.PP

Other sections look like they have the same problem.

I am not enough familiar with groff to know what the tag .\" should do, it might look like it is a comment by the file header. Nevertheless, the states are clearly missing from context so they should be present one way or the other.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

$ apt-cache policy nmap
nmap:
  Installed: 7.01-2ubuntu2
  Candidate: 7.01-2ubuntu2
  Version table:
 *** 7.01-2ubuntu2 500
        500 http://dk.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

Tags: manpage xenial
tags: added: manpage xenial
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Confirmed: Fixed in Zesty, still broken in Yakkety

Changed in nmap (Ubuntu):
status: New → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

New format is like this:

.PP
closed·
.\" closed port state
.RS 4

Changed in nmap (Ubuntu Xenial):
status: New → Confirmed
Changed in nmap (Ubuntu Yakkety):
status: New → Confirmed
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thank you Mikkel for your report and your Help to make Ubuntu better.
Fortunately in this case newer Releases already hold a fixed version so we need to do nothing to on these and any future releases.

And while it is an absolutely valid bug, given that it is a man page and not content that e.g. let users misconfigure the system but only makes it less readable I doubt it will qualify for the SRU [1] Process.

If you are willing to drive it please feel free to do so, might be a great case to learn .deb packaging and the SRU process.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates

Changed in nmap (Ubuntu Xenial):
status: Confirmed → Triaged
Changed in nmap (Ubuntu Yakkety):
status: Confirmed → Triaged
Changed in nmap (Ubuntu Xenial):
importance: Undecided → Wishlist
Changed in nmap (Ubuntu Yakkety):
importance: Undecided → Wishlist
Adam Bell (arbell)
Changed in nmap (Ubuntu Yakkety):
status: Triaged → Won't Fix
Adam Bell (arbell)
Changed in nmap (Ubuntu Xenial):
status: Triaged → Incomplete
Changed in nmap (Ubuntu Xenial):
status: Incomplete → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.