Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed
Thanks Paul. We did make some changes in Nmap 7.94 which could have caused regressions. I've opened an issue for this on our upstream tracker ( https://github.com/nmap/nmap/issues/2685). Please let us know if you figure anything else out. -Gordon
Bug#1029354: ncat: ICMPv4 Type 3 Code 13 not implemented
Sorry for the delay, but this sounds like expected behavior. Ncat is generally using the socket API rather than raw packets and so the host receives the ICMP response and translates that into a more generic error code that Ncat sees. You can use our Nping tool if you need raw packet sending and sniffing instead. -Gordon On Sat, Jan 21, 2023 at 8:30 AM Marco Moock wrote: > Package: ncat > Version: 7.93+dfsg1-1 > Severity: minor > Tags: upstream > X-Debbugs-Cc: m...@posteo.de > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate > *** > >* What led up to the situation? > ncat and reply is ICMPv4 Type 3 Code 13, wrong error > message > "Ncat: No route to host.". >* What outcome did you expect instead? > Correct message, like "Connection to administratively > prohibited". > https://datatracker.ietf.org/doc/html/rfc1812#section-5.2.7.1 > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages ncat depends on: > ii libc62.36-8 > ii liblua5.3-0 5.3.6-2 > ii libpcap0.8 1.10.3-1 > ii libssl3 3.0.7-1 > > ncat recommends no packages. > > ncat suggests no packages. > > -- no debconf information > >
Bug#1028372: ncat: Please lower alternative priority below nc.traditional
As the author of Ncat, I disagree that it has "very different output" from traditional and OpenBSD netcats. Unless you specify -v (verbose mode), Ncat usually doesn't have any output at all. It silently connects to a remote system (or listens for connections from remote systems) and relays exactly what those systems transmit. Also, nc.traditional does not even support IPv6. A failure because the remote host only supports IPv6 seems a lot more problematic than any alleged difference in output. The traditional nc doesn't support SSL encryption either. That's a problem for communicating with modern web sites and mail servers as well as for communicating securely between ncat instances. Also Ncat fully supports Windows and Mac, so users can interoperate between more systems. And it's more performance in many cases since it supports modern Linux I/O API's rather than just select and poll. Also traditional netcat is not maintained by any particular organization. For these reasons, we support having Ncat be one of the official Debian Netcat alternatives.It's already the default on many other distributions, including Red Hat Enterprise Linux, Fedora, etc. We also love traditional and OpenBSD netcats and are glad those are offered by Debian and Kali as well. Cheers, Gordon "Fyodor" Lyon
Bug#929272: nmap-common: executable distributed in nmap-common detected as malware
Hi Kim-Alexander. On behalf of the Nmap Project, I just wanted to say thanks for submitting the false positive file to all the AV vendors. That really helps. -Fyodor
Bug#773817: Some analysis regarding the socks4 related segfault
On Wed, Dec 24, 2014 at 6:57 AM, Hilko Bengen ben...@debian.org wrote: TLDR: Workaround: Bypass the name resolution attempt and provide the IPv4 address directly. I cannot upload a fixed package to Debian at the moment -- I'd be very grateful if somebody prepared an NMU. Hi Hilko. Can you send a report and your patch to the Nmap dev list ( d...@nmap.org) so we can hopefully get the issue resolved upstream? Cheers, Fyodor
Bug#765999: ncat man page says see the ncat manpage
On Sun, Oct 19, 2014 at 5:52 PM, 積丹尼 Dan Jacobson jida...@jidanni.org wrote: Package: nmap Version: 6.47-3 Severity: wishlist File: /usr/share/man/man1/ncat.1.gz $ man 1 ncat|grep manpage See the ncat(1) manpage for full options, descriptions and usage examples Thanks for the report. That section of the man page is just Ncat's ncat -h help output shown verbatim. I guess we could set up some sort of hack to remove that line about the man page, but I don't personally think it's worth the hassle. Cheers, Fyodor
Bug#748958: nmap: Contains a ca-bundle
On Thu, May 22, 2014 at 9:53 AM, Kurt Roeckx k...@roeckx.be wrote: Your package contains a ca-bundle with the certificates. Maybe you could switch to using those provided by the ca-certificates package? Just for what it is worth, we (Nmap Project) would support this. We include our own bundle for systems which don't have one. But if the Debian Nmap packages use a system-wide bundle they have instead, that is probably a better solution. Cheers, Fyodor
Bug#744938: nmap: manual page missing text
On Wed, Apr 16, 2014 at 6:15 AM, Oskar Liljeblad os...@osk.mine.nu wrote: Package: nmap Version: 6.40-0.2 Severity: minor In the PORT SCANNING BASICS The six port states recognized by Nmap section of the Nmap manual page, the actual state names are missing. Thanks for the report. This happens on my Fedora box too with our Nroff man page (which is generated from Docbook XML, just like our HTML rendering you reference is). I don't know what the problem is. I've added this to our todo file (which doesn't mean anyone will actually fix it, but hopefully someone will figure it out). Cheers, Fyodor
Bug#737950: liblinear1 pulls in more than description
On Tue, Feb 18, 2014 at 1:18 AM, Marco Tedaldi teda...@hifo.uzh.ch wrote:
Am 18.02.2014 09:52, schrieb Hilko Bengen:
Thank you very much. Just tested (purged the liblinear1 and nmap before)
and it worked.
This apparently works around the issue!
I've created 90NoRecommends in /etc/apt/apt.conf.d/ with this content:
+
# Prevent apt to pull in packages that are not dependencies but only
recommended.
APT{ Install-Recommends false;};
+
But is this really intended behaviour? Shouldn't this recommends be
moved into suggests?
Well Liblinear is definitely recommended for Nmap since it is required for
the IPv6 OS detection system. Maybe the Liblinear dependencies should be
changed so it doesn't pull in all that other stuff.
Cheers,
Fyodor
Bug#724580: nmap: ncat segfaults when scanned with nmap --script 'ssl*,tls*'
On Wed, Sep 25, 2013 at 3:10 AM, Timo Juhani Lindfors timo.lindf...@iki.fiwrote: Package: nmap Version: 6.40-0.1 Severity: normal Steps to reproduce: 1) ncat -k --ssl -l localhost 443 2) nmap -sC --script-trace --script 'ssl*,tls*' -6 localhost -p 443 Expected results: 2) ncat does not segfault Actual results: 2) ncat segfaults, dmesg shows Thanks for the report. I was able to reproduce this with our latest Nmap svn version on Fedora, so it doesn't seem specific to the Debian package. I am adding an entry to our todo list for fixing this. -Fyodor
Bug#696446: nmap: Errors out at startup if running as root and there is a network interface in monitor mode
On Thu, Dec 20, 2012 at 1:32 PM, Daniel Franke dfoxfra...@gmail.com wrote: Package: nmap Version: 6.00-0.2 Severity: important nmap errors out at startup if it is run as root and the system has any network interface which is in monitor mode: Thanks for the report. This bug should have been fixed in Nmap 6.01 in June (and also the latest version, 6.25). You can download these versions from nmap.org, or hopefully Debian will do an update soon. Cheers, Fyodor
Bug#691774: nmap: dependency on python is not needed
On Mon, Oct 29, 2012 at 8:09 AM, Dmitry Nezhevenko d...@dion.org.ua wrote: nmap package has dependency on python which looks like not needed. I think that python is only needed for zenmap frontend. Found it while trying to install nmap on embedded system. Also I can confirm that nmap works after removing python packages manually. For what it is worth, our Ndiff utility (I'm not sure if it is included in Debian's Nmap package) does require Python. Zenmap does too, but I'm guessing that is in a separate package from Nmap. Nmap itself does not require Python as Dmitry notes. Cheers, Fyodor
Bug#671064: nmap: FTBFS[kfreebsd]: error: 'CLOCK_MONOTONIC' undeclared
On Tue, May 01, 2012 at 08:09:57PM +0100, Steven Chamberlain wrote: While here, I also saw what looked like Microsoft .exe redistributables in the source tarball / Git repository? We currently include those in our upstream Nmap tarballs (they are needed on Windows and MS gives permission to redistribute them). But of course there is no need for Debian to include them. And, in fact, we may cease including them in the Nmap source tarball too. They are mostly just needed for our Windows binary packages. Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663217: zenmap's sys.path includes /tmp locations
On Fri, Mar 09, 2012 at 02:57:03PM +0100, chrysn wrote: Package: zenmap Version: 5.21-1.1 Severity: grave Tags: security the zenmap script modifies its sys.path to include '/tmp/nmap-5.21/debian/tmp/usr/lib/python2.6/site-packages/', which is inserted at build time from setyp.py. Thank you for the report. This is indeed a problem if you initially build and install into a world-writeable directory (e.g. /tmp/nmap-5.21/debian) and then copy the files elsewhere as part of a distribution. This feature is meant to set the module path for cases where people install Nmap in nondefault (but secure) locations, such as their home directory. But it isn't a very important feature, and we may be able to support that in other ways. So we have removed the set_modules_path function and the call to it from nmap/zenmap/setup.py in our source code repository. That change will be in future Nmap releases, and here is the patch: Modified: nmap/zenmap/setup.py == --- nmap/zenmap/setup.py(original) +++ nmap/zenmap/setup.pyMon Mar 26 19:14:22 2012 @@ -205,7 +205,6 @@ install.run(self) self.set_perms() -self.set_modules_path() self.fix_paths() self.create_uninstaller() self.write_installed_files() @@ -307,32 +306,6 @@ mode = ((os.stat(uninstaller_filename)[ST_MODE]) | 0555) 0 os.chmod(uninstaller_filename, mode) -def set_modules_path(self): -app_file_name = os.path.join(self.install_scripts, APP_NAME) -# Find where the modules are installed. distutils will put them in -# self.install_lib, but that path can contain the root (DESTDIR), so we -# must strip it off if necessary. -modules = self.install_lib -if self.root is not None: -modules = path_strip_prefix(modules, self.root) - -ufile = open(app_file_name, r) -ucontent = ufile.readlines() -ufile.close() - -# Insert our custom import after the first non-comment line. -re_sys = re.compile(^#) -uline = 0 -for line in ucontent: -if not re_sys.match(line): -break -uline += 1 -ucontent.insert(uline, \nimport sys\nsys.path.append(%s)\n % repr(modules)) - -ufile = open(app_file_name, w) -ufile.writelines(ucontent) -ufile.close() - def set_perms(self): re_bin = re.compile((bin|\.sh)) for output in self.get_installed_files(): -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630144: nmap: New upstream release
On Mon, Mar 19, 2012 at 03:43:27PM +0100, Raphael Hertzog wrote: We're 9 months later and we're still at 5.21 in Debian unstable. I don't want to get embroiled in any Debian politics, but I will say, on behalf of the Nmap Project, that we'd love to see Debian include a modern version of Nmap. Version 5.21 is more than 2 years, and 10 releases, behind the current version. In our CHANGELOG (http://nmap.org/changelog.html), the first 3,138 lines describe improvements and bug fixes we've made since 5.21. We're actually hoping to release a new stable version of Nmap within the next couple weeks. It will be extremely similar to Nmap 5.61TEST5, which can be obtained from http://nmap.org/download.html. So if someone at Debian can make a 5.61TEST5 package, you will be ready to package the upcoming Nmap stable just as soon as it comes out. Debian could even be the first distro to do so! PS: In case you did not pay attention, there's also a security bug to fix in this source package (see #663217). I'll take a look at that too. Cheers, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614765: liboss-salsa-asound2: Cannot install, dependencies problems with libasound2
2011/2/23 Samuel Thibault sthiba...@debian.org: And if you blacklist the alsa drivers, the applications don't fallback to the OSS interface? Some do, but some don't. jackd2 doesn't have an OSS driver, and I couldn't make jackd1 produce sound of acceptable quality with OSS. Audacity crashes when playing through OSS. I couldn't make non-free Flash Player work with OSS when I had version 4.2-build2003 from the Debian archive installed. BTW, oss4-dkms 4.2-build2003 doesn't compile with kernel 2.6.37, so I had to build and install a deb from the vanilla OSS 4.2-build2004 package. After that Flash Player plays sound at least, but I still have problems with jack and Audacity. Thanks, Fyodor. -- С уважением, Фёдор Ковин. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614765: liboss-salsa-asound2: Cannot install, dependencies problems with libasound2
2011/2/23 Samuel Thibault sthiba...@debian.org: And if you blacklist the alsa drivers, the applications don't fallback to the OSS interface? Some do, but some don't. jackd2 doesn't have an OSS driver, and I couldn't make jackd1 produce sound of acceptable quality with OSS. Audacity crashes when playing through OSS. I couldn't make non-free Flash Player work with OSS when I had version 4.2-build2003 from the Debian archive installed. BTW, oss4-dkms 4.2-build2003 doesn't compile with kernel 2.6.37, so I had to build and install a deb from the vanilla OSS 4.2-build2004 package. After that Flash Player plays sound at least, but I still have problems with jack and Audacity. Thanks, Fyodor. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614765: liboss-salsa-asound2: Cannot install, dependencies problems with libasound2
Package: liboss-salsa-asound2 Version: 4.1-build1052b-2 Severity: normal Although the package provides libasound2, it still cannot be used instead of it, because many other packages depend on specific versions of libasound2. The following packages depend on libasound 1.0.18 and become broken when trying to install liboss-salsa-asound2: chromium-browser emacs23 lxpanel mplayer libportaudio2 libesd0 xulrunner-1.9.1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.37-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#322137: patch
On Wed, Dec 22, 2010 at 05:13:20PM -0500, Daniel Echeverry wrote: tags 322137 + patch thanks patch to rewrite option section to mention privileged users/normal user Thank you for the patch, but there are a couple concerns: o This patch adds a [privileged user] tag to the docs for some operations, but there are other options which require privileges as well. Plus, at least one of the options you add this tag to (-sT) does not actually require privileges. o The nroff man page is automatically generated. We only make changes to the source Docbook XML file (http://nmap.org/svn/docs/refguide.xml) Thanks, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605347: say format for -i
On Mon, Nov 29, 2010 at 10:55:37AM +0800, jida...@jidanni.org wrote: Package: nmap Version: 5.21-1 Severity: wishlist File: /usr/share/man/man1/ncat.1.gz -i time, --idle-timeout time (Specify idle timeout) . Set a fixed timeout for idle connections. If the idle timeout is reached, the connection is terminated. Say how to specify. Are these seconds etc. Thanks for the suggestion, but the top of that section already says: These options accept a time parameter. This is specified in seconds by default, though you can append ms, s, m, or h to the value to specify milliseconds, seconds, minutes, or hours. (At least that is in the current man page. I didn't check older versions, but if your version of the man page does not have this text, it will be in our next release). Cheers, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593526: nmap: incorrect services listed for port numbers 9101-9107
On Wed, Aug 18, 2010 at 04:34:08PM -0700, Brian Murray wrote: nmap reports the service jetdirect for port 9102. This is wrong. It should report Bacula File Daemon. The port 9102 is officially assigned to Bacula File Daemon. That may be the official assignment, but the sad reality is that my HP printer (purchased this year) still has jetdirect listening on: 9100/tcp open jetdirect 9101/tcp open jetdirect 9102/tcp open jetdirect I'll bet there are more HP printers doing this than there are Bacula installations :(. It would be great if HP would get their own proper port assignments. Otherwise, maybe Bacula can apply for a new port number which hasn't been inappropriately commandeered by HP? Normally we would suggest adding a version detection signature for Bacula so that it can be distinguished from Jetdirect, but 9100-9107 is the one port range for which we don't do version detection by default since Jetdirect is so broken :(. I have added a comment on Bacula to the 9102 entry for what little that is worth. Cheers, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584301: nmap broken with resolver setting 'options inet6'.
On Fri, Jun 04, 2010 at 08:13:48PM +0200, Mats Erik Andersson wrote: fredag den 4 juni 2010 klockan 14:08 skrev Mats Erik Andersson detta: Is innocent! So are a multitude of other calls to gethostbyname(3). to be at the source of the problem. I will conduct a further study to better localize the faulty behaviour, be it mine or the archived software. The culprit acts in TargetGroup.cc lines 214 -- 237. The code does not seem easily maintainable, so I can offer no quick resolution. Let me just remark that the easiest testing can be done using the call $ RES_OPTIONS=inet6 nmap -v -p 22 ipv6.google.com This avoids the insertion of 'options inet6' in '/etc/resolv.conf'. Thanks for your report and help. We believe it is now fixed in our latest SVN, as described here: http://seclists.org/nmap-dev/2010/q2/899 Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584301: nmap broken with resolver setting 'options inet6'.
On Fri, Jun 04, 2010 at 08:13:48PM +0200, Mats Erik Andersson wrote: The culprit acts in TargetGroup.cc lines 214 -- 237. The code does not seem easily maintainable, so I can offer no quick resolution. Let me just remark that the easiest testing can be done using the call $ RES_OPTIONS=inet6 nmap -v -p 22 ipv6.google.com This avoids the insertion of 'options inet6' in '/etc/resolv.conf'. Thanks for the further details and debugging. I have forwarded your report to the nmap-dev mailing list in the hope someone will pick it up: http://seclists.org/nmap-dev/2010/q2/787. Cheers, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584301: nmap broken with resolver setting 'options inet6'.
On Thu, Jun 03, 2010 at 01:38:30AM +0200, Mats Erik Andersson wrote: Package: nmap Version: 5.00-3 Severity: important In an environment with IPv4 as well as IPv6 active, and with /etc/resolv.conf containing the statement options inet6, the present Nmap is broken when it comes to resolving IPv4 host addresses. Thanks for the report. Can you try with Nmap 5.30BETA1, available from http://nmap.org/download.html and report whether that fixes it? There are a couple post-5.00 items in the CHANGELOG which I hope have resolved this: o Fixed handing of nameserver entries in /etc/resolv.conf so it could handle entries containing more than 16 bytes, which can occur with IPv6 addresses. Gunnar Lindberg reported the problem and contributed an initial patch, then Brandon and Kris refined and implemented it. o Added support for connecting to nameservers over IPv6. IPv6 addresses can be used in /etc/resolv.conf or with the --dns-servers option. The parallel reverse DNS resolver still only support IPv4 addresses, but it can look them up over IPv6. [Ankur Nandwani] If that works for you, maybe you can get Debian to update to the latest Nmap. Or I suppose they could backport the IPv6 changes, but there are hundreds of other important changes in the latest versions of Nmap. Cheers, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574533: RFP: liarliar -- a computerized voice stress analysis (CVSA) tool
Package: wnpp Severity: wishlist Package name: liarliar Version: 0.5.2 Author: Gene Ruebsamen gurur...@gmail.com Project URL: http://liarliar.sourceforge.net/ License: GNU General Public License (GPL) User Interface: Gnome Programming Language: C++ Description: LiarLiar is a voice stress analysis tool for Linux. Voice-stress analysis, an alternative to the polygraph as a method for lie detection, is already widely used in police and insurance fraud investigations. LiarLiar's main purpose is to detect stress in a person's voice. Higher stress levels can be an indication that the person is not being truthful. LiarLiar uses voice stress analysis techniques to attempt to quantify the amount of stress present in speech. LiarLiar is not a lie detector; however, many people will probably use it as such. Moreover, lie detection using voice stress analysis (VSA) techniques have come under much scrutiny as of late. More recent information and technical details about the software can be found in the forums. Features of LiarLiar include: * Utilizes GStreamer to support multiple input file types (microphone and/or file input) * Plugin system to support addtional computerized voice stress analysis (CVSA) plugins * Able to detect microtremors in the 8-14 Hz range. * Quantification (between 0-100%) of level of stress in speech based upon microtremor analysis * Written in C++ and utilizing GTK toolkit * Future versions will make use of additional speech parameters for better accuracy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564559: makepasswd: Default settings generate insecure passwords
I'd appreciate it if you could have a look at the code I just uploaded to unstable, and review it for correctness. You can see the diff here: http://bzr.debian.org/loggerhead/users/cjwatson/makepasswd/trunk/revision/20 I've reviewed the code. The only possible problem I've found is in the line my $max = 1 ($bytes * 8); Theoretically overflow can happen here resulting in zero or negative result and then the program can hang in the loop below this line. But for all reasonable values this line is just fine. Cheers, Fyodor Menshikov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571189: makepasswd: Insecure password distibution if several password lengths possible
Package: makepasswd Version: 1.10-5 Severity: normal makepasswd has the following command line arguments: --minchars and --maxchars. They allow generating passwords of length from minchars to maxchars. Default settings is to generate passwords of length from 8 to 10 characters. The problem is algorithm makepasswd uses to select length of password it generates. It chooses length of password with equal probability. So for example if --minchars=1 and --maxchars==10 then with probability 1/10 an absolutely insecure password of length 1 will be generated. For real world examples (default --minchars=8, --maxchars=10) the problem is not so killing but exists also because default probability of a 10-character password is 1/3/62^10 ~=~ 4e-19 but probability of an 8-character password is much greater 1/3/62^8 ~=~ 1.5e-15. I suggest to choose length of generating password not with equal probability but according to amount of passwords of given possible length. For example for --minchars=8 and --maxchars=10 amount of passwords of length 8 is 62^8, of length 9 is 62^9 and of length 10 is 62^10. So ideally probability of length 8 should be 62^8/(62^8+62^9+62^10) ~=~ 0.00026, probability of length 9 should be 62^9/(62^8+62^9+62^10) ~=~ 0.016 and probability of length 10 should be 62^10/(62^8+62^9+62^10) ~=~ 0.98. It is also clearly seen that there is no reason to specify range of password lengths because the absolute majority of passwords come from the maximal length. So I suggest to set default --minchars and --maxchars to the same value - for example 10. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-xen-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages makepasswd depends on: ii libcrypt-openssl-random-perl 0.04-1+b1 Access to the OpenSSL pseudo-rando ii libcrypt-passwdmd5-perl 1.3-9 interoperable MD5-based crypt() fo ii perl 5.10.1-8 Larry Wall's Practical Extraction makepasswd recommends no packages. makepasswd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564559: makepasswd: Default settings generate insecure passwords
I'm not sure how calling srand every time would help at all, though. Your point is that there are only 2^32 possible seeds. If we call srand every time, then there are still only 2^32 possible seeds. In fact, calling srand every time makes it worse; at least at the moment the administrator can tell makepasswd to produce some large number of passwords and select an arbitrary (if not truly random) one from that list. Since Debian's Perl is configured to use drand48() as its implementation of rand, there are in fact considerably more than 2^32 passwords available to an administrator following this strategy. Forcing makepasswd to reset the random seed every time *worsens* the situation because now there are only 2^32 possible passwords no matter how many you tell makepasswd to generate at once, because you only ever get the first value from the PRNG sequence. No, calling srand function with 32 bit cryptographic secure random number argument before each rand function call does _not_ make things worse and number of available passwords is not limited by 2^32. With this approach first char of password depends on first 4 bytes read from /dev/urandom. The second char depends on second 4 bytes read from /dev/urandom. The third char depends on third 4 bytes read from /dev/urandom. And so on. But! /dev/urandom is based on cryptographic secure pseudo random number generator so none can easily forecast next bytes given the previous ones. I think that cryptographic strength of /dev/urandom is 256 bit so number of generated passwords using data from /dev/urandom may be estimated to be not less than 2^256. How about we use libcrypt-openssl-random-perl instead? You can seed its PRNG with an arbitrary amount of data; I expect 256 bits would be quite adequate given that that's vastly more than the space of available passwords for the default lengths, and you'd have to be generating somewhat over 30-character passwords before you started reaching that kind of entropy. (Plus, urandom(4) recommends reading no more than that amount of data per invocation.) I think that using either of libcrypt and /dev/urandom is secure and which one to choose is just matter of taste. To my taste system internal cryptographic PRNG (/dev/urandom) is more tested and secure than any third party library. And it is _already_ used by makepasswd package. So all required to do is just ignore --rerandom key and fix this parameter value to 1. On the other hand makepasswd has key --randomseed=N Use random number seed N, between 0 and 2^32 inclusive. A zero value results in a real-random seed. I think that this key should be made deprecated and disallowed at all. But if it is absolutely necessary to allow creation of predictable (but secure!) passwords then /dev/urandom cannot help, libcrypt should be used instead (and range of arguments to --randomseed should be extended to 2^256). Or for backward compatibility it is possible to use old approach (internal rand without reseed) if --randomseed argument is specified. Anyway users of --randomseed were warned that there are only 2^32 cases. Cheers, Fyodor Menshikov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564559: makepasswd: Default settings generate insecure passwords
Package: makepasswd Version: 1.10-4 Severity: critical Tags: security Justification: root security hole By default makepasswd gets 32-bit random seed from /dev/urandom, initializes Perl random numbers generator with it using srand function and then generates password length and password chars using rand function that is not cryptographic secure and absolutely predictable by initial seed that is only 32 bit strength. Default settings for makepasswd is password length from 8 to 10 characters inclusive and password consisting of characters A-Za-z0-9 (total 62) so theoreticaly it is possible to create 62^8+62^9+62^10 = 8.5e17 passwords in default mode. Actually I think that security in this case better estimated by 62^8 = 2.1e14 because all lengths have equal probability. But because rand function depends completely on srand seed the amount of possible passwords lowered from 8.5e17 or 2.1e14 to just 2^32 = 4.2e9. So any root user (hence root security hole justification) that uses password generated by makepasswd package is vulnerable to brute force attack. 4 billions paswords brute force attack is quite possible. The best solution of the issue I've found is using --rerandom=1 command line switch that initializes srand with cryptographic secure /dev/urandom value before each rand function call. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-xen-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages makepasswd depends on: ii libcrypt-passwdmd5-perl 1.3-9 interoperable MD5-based crypt() fo ii perl 5.10.1-8 Larry Wall's Practical Extraction makepasswd recommends no packages. makepasswd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564575: RFP: Flinks -- a text-mode flashing word webbrowser, intended for speed-reading and/or skimming
Package: wnpp Severity: wishlist Package name: flinks Version: 0.3 Author: Martin Bays (mb...@sdf.lonestar.org) Project URL: http://mbays.freeshell.org/flinks/ License: GPLv3 Description: Flinks is a text-mode flashing word web browser. It is intended for speed-reading and/or skimming webpages and text. Written in Python using ncurses for display and requiring lynx for rendering. Should run without trouble on any unix-like system, and with some trouble on other systems. Runs happily on very small terminals, so ought to work well on hand-helds, or even eye-glass displays... I would be very interested to see this done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556101: zenmap: Sort hosts in host list
On Fri, Nov 13, 2009 at 03:13:41PM +, George B. wrote: I think it would be nice to sort the list of found hosts. E.g. I scanned a subnet and have about 100 hosts - they are currently listed randomly rather than from .1 to .254 etc. Please send Nmap suggestions to the nmap-dev mailing list (nmap-...@insecure.org) as Debian is not going to add features to Nmap, and most Nmap developers do not follow the Debian bug tracker. Thanks! Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501371: nmap 5 failed to determine route too
On Mon, Oct 26, 2009 at 01:44:02PM +0100, Michael Gebetsroither wrote: Nmap 5.00-3 shows the same symtoms as the old version 4 nmap. The problem seems to be my 2 upstreams and the necessary policy based routing. Thanks for the report. This sounds like more of an Nmap issue than a Debian one, so how about if you resend your report to nmap-...@insecure.org so people can discuss potential workarounds and solutions? Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546564: nmap: [INTL:DE] Upgraded German translation
On Mon, Sep 14, 2009 at 09:11:32AM +0200, Chris Leick wrote: Package: nmap Version: 5.00-3 Severity: wishlist Tags: l10n Please find the new version of the German translation for nmap attached. Thanks Chris. We've integrated this upstream in our SVN. Next time you make an update, you may want to send it to nmap-...@insecure.org too (you don't even need to be a subscriber to send there). Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#282952: typo in nmap-services file
On Wed, Aug 26, 2009 at 08:01:45PM +0200, Gerfried Fuchs wrote: Hi again! Going through old bugreports of mine, I stumbled upon this: * Gerfried Fuchs rho...@debian.at [2004-11-25 17:22:51 CET]: There is a typo in the nmap-services, please accept this mini pseudo-patch: #v+ -sco-dtmgr 617/tcp# SCO Desktop Administration Server or Arkeia (www.akriea.com) backup software +sco-dtmgr 617/tcp# SCO Desktop Administration Server or Arkeia (www.akreia.com) backup software #v- www.akriea.com but www.akreia.com is correct. ^^ ^^ I wonder, is there any deeper issue with fixing this typo that I am not aware of? Anything I could help with? Hehe, actually the patch still gets it wrong as their is a 2nd typo in that URL. The actual URL is www.arkeia.com. I've fixed this in SVN for the next version of Nmap. Thanks for the report! -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542388: nmap: FTBFS on GNU/kFreeBSD
On Wed, Aug 19, 2009 at 01:16:54PM +0200, Petr Salinger wrote: Hi, the current version fails to build on GNU/kFreeBSD. It needs a small change to configure.in/configure in libdnet-stripped subdir, see attached patch. It would also be nice if you can ask upstream to integrate this change in their next release. Thanks for the report and patch. I have applied this for the next version of Nmap. Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541984: nmap: Build process isn't thread safe
On Mon, Aug 17, 2009 at 03:57:19AM -0300, Nelson A. de Oliveira wrote: Package: nmap Version: 5.00-1 Severity: minor Hi! nmap fails to build if built with more than one thread (using -j2 in DEB_BUILD_OPTIONS, for example). See the attached pbuilder log for the errors when building the package with 2 threads. Thanks for the report. Are you able to reproduce this with the unmodified Nmap tarball (http://nmap.org/dist/nmap-5.00.tar.bz2) and make -j2 or -j4 or whatever? I've been using -j4 on almost all my Nmap builds for years and haven't encountered problems. I looked at your attached log.txt, but it doesn't seem to show the exact error. It just finishes configure and then says: Configuration complete. Type make (or gmake on some *BSD machines) to compile. touch configure-stamp dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting dev/pts filesystem I: unmounting proc filesystem - Cleaning COW directory forking: rm -rf /var/cache/pbuilder/build//cow.24037 Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542054: nmap: partially overlaps with ndiff package
On Mon, Aug 17, 2009 at 11:18:25AM -0400, Aaron M. Ucko wrote: Package: nmap Version: 5.00-1 Severity: serious Justification: Policy 6.6(4) nmap 5.00 introduces the /usr/bin/ndiff script, already present (along with a handful of related scripts) in the separate ndiff package, yielding a file conflict that would render the latter uninstallable in a clean unstable system: Preparing to replace nmap 4.68-1 (using .../archives/nmap_5.00-1_amd64.deb) ... Unpacking replacement nmap ... dpkg: error processing /var/cache/apt/archives/nmap_5.00-1_amd64.deb (--unpack): trying to overwrite `/usr/bin/ndiff', which is also in package ndiff dpkg-deb: subprocess paste killed by signal (Broken pipe) Please sort out with ndiff's maintainer (Ola Lundqvist o...@debian.org, X-Debbugs-Cc:ed) how to proceed. Both versions of ndiff have a similar purpose: comparing Nmap scans and showing the differences between them. The old Ndiff (from the Debian ndiff package) was a nice tool, but the author stopped developing it at version 0.05beta1 and hasn't maintained it for nearly 8 years. Our new Ndiff is actively maintained (distributed with Nmap) and far more featureful than the ancient version. So the Nmap Project recommends resolving this conflict by either removing the old Ndiff package or renaming the ndiff executable from that package to ndiff.pl since it is a Perl script. Don't hesitate to contact me if you have any questions. Thanks, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542054: nmap: partially overlaps with ndiff package
On Tue, Aug 18, 2009 at 06:59:51AM +0200, Ola Lundqvist wrote: As I'm the maintainer (and actually creator now when I look in the chnagelog) of ndiff and do not really have a problem to get that package removed. The old ndiff (ndiff package) is old as you Fyodor states. Thanks Ola. Even though the Nmap project now has an official, supported ndiff tool, we do appreciate your efforts in packaging this 3rd party ndiff for all these years! So the following needs to be done: 1) Update nmap to conflict and provide ndiff (at least conflict). This part will solve this bug and must be done in any case, as we have ndiff in the archive now and people can have it installed already (like me). I'm not a Debian developer, but maybe someone else can do this? I only follow the Debian Nmap bug tracker since I'm the author and maintainer of Nmap. 2) Please check whether the ndiff script works in the same way as the old ndiff. They serve the same purpose (show the difference between two Nmap scans), but I haven't used old ndiff in many years. 2) Please check whether the nrun and ngen scripts work with the new nmap. Given how much Nmap has changed in the last 8 years (and these scripts haven't), they at best work on a small subset of Nmap features. I haven't tried them for the better part of a decade. If it does, you can merge that code to nmap. As these third party scripts are unrelated to the Nmap Project, we don't think they should be merged with Debian's Nmap package. Even the original author no longer supports them, and we don't want to either. If it do not work we need to remove ndiff package anyway. 3) File a bug against ftp.debian.org requesting the removal of the package. If the ftp team needs my approval before it is removed, please Cc me and I'll answer that. Would this be ok with you? That sounds good although I think a Debian developer should do it. By the way, we have no problem with old ndiff continuing as a package, but we think the name of the package and script executable should be changed to avoid conflicting. For example, the package could become nwatch or nrun or ngen and the ndiff script could become ndiff.pl. Removing the package entirely is another reasonable option. We believe that most people trying to apt get ndiff are expecting the official supported Nmap project Ndiff tool which we've been promoting, and not an 8 year old set of unmaintained Perl scripts. Thanks, Fyodor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539244: nmap doesn't work with IPv6 Nameservers
On Thu, Jul 30, 2009 at 07:29:51AM +0200, Friedemann Stoyan wrote: I'm using IPv6 nameservers: $ cat /etc/resolv.conf nameserver ::1 but nmap complains: $ nmap -R -sP 192.168.19.0/24 Starting Nmap 4.62 ( http://nmap.org ) at 2009-07-30 07:20 CEST mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns_servers Explicit nameserver setup doesn't work too: $ nmap --dns-servers ::1 -sP 192.168.19.0/24 Thanks for the report. We (Nmap project) have added an item to address this to our TODO list (http://nmap.org/svn/docs/TODO). The next step is for someone with the right motivation and skills to come along, investigate the issue, and write/submit a patch. We would be happy to integrate such a patch if Friedmann or someone else writes one. Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527997: nmap: links against embedded copy of liblua
On Mon, May 18, 2009 at 03:12:02AM +0200, Jan Christoph Nordholz wrote: the patch to the configure.ac files is no problem - I'm having trouble however to get the autotools to cooperate. Rerunning autoconf alone in nselib-bin/ fails (read as: produces lots of scary warnings), and if I run aclocal autoconf, the generated libtool fails at the build stage. Bugs like #527503 suggest that I'm not alone with this problem; I'm afraid I can't do more than to give you my .ac patch. The configure scripts run fine (including the lua5.1/lua fallback), it just doesn't build until someone figures out what's wrong with libtool. Thanks Jan. Our current svn does not have an nselibs-bin directory anyway. I've applied your patch to our configure.ac and regenerated configure in our latest SVN. It still works for me on my system which uses /usr/include/lua.h, but if you could test our latest SVN and report the results, that would be great. For instructions, see: http://nmap.org/book/install.html#inst-svn o Patched configure.ac to detect Lua include and library files in lua5.1 subdirectories of /usr/include and the like. Apparently Debian puts them there. We still check the likes of /usr/include/lua.h and /usr/include/lua/lua.h as well. [Jan Christoph Nordholz] Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527997: nmap: links against embedded copy of liblua
On Tue, May 12, 2009 at 08:02:15AM +0200, Jan Christoph Nordholz wrote: tags 527997 = patch thankyou I might as well attach the appropriate patch... (autoconf is called from the upstream Makefile, which makes the build process a bit cumbersome now that we're patching configure.ac - you might choose to patch configure itself instead, or call autoconf early in the build process yourself) Thanks Jan. But if you get a chance, I'd love to see a patch which checks for both the plain lua and lua5.1 versions. That way it would still work on platforms which just use plain lua and so it would be appropriate for upstream integration. If we add it to an Nmap release, Debian doesn't have to worry about maintaining their own custom patch. Would you write a patch in which configure checks for lua first and then falls back on lua5.1 if that fails? Or, I suppose, the other order would probably be fine too. Thanks! -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#195299: nmap: 'massping' breaks certain ping scans
On Wed, Apr 01, 2009 at 04:46:35PM -0400, Justin Azoff wrote: I used git bisect against git://git.debian.org/~lamont/nmap.git to track this down to a commit, and the result was d37f15389455ff474c00223cbf18be4117cedd76. The changelog for that says: +o Included David's major massping migration project. The same + underlying engine is now uses for ping scanning as for port + scanning. We hope this will lead to better performance and + accuracy, as well as helping to de-bloat Nmap. Please test it out + and report your results to nmap-dev! For more details, see + http://seclists.org/nmap-dev/2007/q3/0277.html the test I ran was: time sudo nmap --host_timeout 2000 -n -sP -PE a.b.0.0/16 -oG - | grep 'Status: Up' -c I verified that with the previous rev (f501df2e2a74f0bc8ce35a9ddc67d6864afddf96) the results are: num: 3868 time: 9:36 with d37f15389455ff474c00223cbf18be4117cedd76 the results are: num: 291 time: 1:11 so it runs in 1/10th the time, but finds 1/10th the hosts. As a workaround I changed the timeout to 3. That finds the expected number of hosts, and still runs in about 13 minutes. Unfortunately I'm not sure what the fix for this is :-) It may be working as designed and something just needs to be documented better... Hi Justin. If you can reproduce this with the latest version of Nmap (4.85BETA7), we'd be happy to hear about it and might be able to fix it upstream. You can obtain the latest version of Nmap at http://nmap.org/download.html. Then you can find bug reporting instructions at http://nmap.org/book/man-bugs.html. Nmap 4.62 was released on May 3, 2008. So it is almost a year old now. Cheers, -F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495241: zenmap: Leaves temporary files in /tmp
On Fri, Aug 15, 2008 at 01:06:29PM -0300, Nelson A. de Oliveira wrote: After running zenmap, there are a lot of temporary files left behind at /tmp. While it doesn't cause any problems, zenmap should clean them after the usage. We have fixed this in the Zenmap svn, and the fix will be reflected in the next release of Nmap/Zenmap after the current (4.68) release. Thanks for the report! -Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#201858: Our company in United States helping individuals in online business.
International company Dex. Union Inc is looking for top candidates for a number of opportunities: Sales representative, Finance representative. We are searching for individuals in United States who have the intellectual capacity and interested in good earnings. Get job in 3 hours after your answer, and start earning! No relocation, cell phone and email required. High Salary! If you're seeking a convenient job location, consistent hours and great opportunity for growth than this is the perfect position for you in USA! Company Details and How to apply? Please write: [EMAIL PROTECTED] Regards Adam Nelson Dex. Union Inc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468753: 'man zenmap' typo: vebosity
On Sat, Mar 01, 2008 at 02:12:08AM -0500, A. Costa wrote: Found a typo in '/usr/share/man/man1/zenmap.1.gz', see attached '.diff'. Thanks for the report -- fixed for the next release of Nmap. -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466595: zenmap: No module named gtk error
On Tue, Feb 19, 2008 at 09:07:09PM +, Sheridan Hutchinson wrote: I'm a KDE man and I'm using Lenny with the absolute minimum of GTK stuff installed. Zenmap's dependencies though are probably not as aggressive as they should be because I get the following error: In case this is useful for improving the Debian package (if necessary), here is the dependency string we use for the Nmap RPM distribution of Zenmap: Requires: python = 2.4, nmap, pygtk2, python-sqlite2 Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459884: nmap: Error in man page
On Thu, Jan 10, 2008 at 02:33:45PM -0800, Fyodor wrote: On Wed, Jan 09, 2008 at 11:41:14AM +0100, Richard van den Berg wrote: This is because in /usr/share/man/man1/nmap.1.gz twice a line starts with \.nse which is confused for the .ns nroff no-space mode command. A fix suggested at http://seclists.org/nmap-dev/2007/q4/0305.html is to put the \.nse on the previous line. I'm afraid it isn't that easy. nmap.1 is generated from DocBook source (docs/nmap.xml in the Nmap tarball) using xsltproc. The best solution would be to fix whatever part of the toolchain is producing the invalid nroff. I'm afraid nobody came up with ideas for fixing this the right way (which would likely involve fixing the DocBook XSL to nroff man page stylesheets). So I just wimped out and did the easy workaround--reworded the man page to talk about files with the nse extension rather than using the string .nse which caused problems. So the next Nmap release should resolve that, and the regenerated man page is already available at http://insecure.org/nmap/data/nmap.1 or in SVN if someone wants to test it further. My version of man didn't complain about the previous version. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459884: nmap: Error in man page
On Wed, Jan 09, 2008 at 11:41:14AM +0100, Richard van den Berg wrote: This is because in /usr/share/man/man1/nmap.1.gz twice a line starts with \.nse which is confused for the .ns nroff no-space mode command. A fix suggested at http://seclists.org/nmap-dev/2007/q4/0305.html is to put the \.nse on the previous line. I'm afraid it isn't that easy. nmap.1 is generated from DocBook source (docs/nmap.xml in the Nmap tarball) using xsltproc. The best solution would be to fix whatever part of the toolchain is producing the invalid nroff. If you have suggestions or ideas, I'd be happy to hear them. We use DocBook as the official man page source because we also generate HTML and PDF versions. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455405: FTBFS with GCC 4.3: #define redefined
On Sun, Dec 09, 2007 at 04:53:51PM -0700, Martin Michlmayr wrote: Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. GCC 4.3 has converted a number of warnings into errors. With GCC 4.3, you're no longer to just redefine a previous #define. You need to either avoid redefinitions directly or to use #ifndef to make sure that something has not been defined already. See http://www.cyrius.com/journal/gcc/gcc-4.3-pedwarn.html Thanks for the report, Martin. Do you think you could try with Nmap 4.49RC6 and mail the results to [EMAIL PROTECTED] ? You can obtain it from: http://insecure.org/nmap/download.html Also, I think our HAVE_AF_INET6 test macro isn't working on your system, probably due to the new compiler. So if you would also send your nbase/config.log with the report, that would be great. Thanks, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451841: nmap displies the wrong service for 953
On Sun, Nov 18, 2007 at 10:51:55PM +0200, Jabka Atu wrote: Package: nmap Version: 4.20-2 Severity: normal When running nmap 127.0.0.1 on machine that hosts a bind progrma (named bind) nmap will print : 953 open rndc instead of 953 open rndc? or 953 open bind RNDC is the name of the bind configuration service listening on that port. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451842: nmap displies the wrong service for 953
On Sun, Nov 18, 2007 at 10:58:27PM +0200, Jabka Atu wrote: Package: nmap Version: 4.20-2 Severity: normal When running nmap 127.0.0.1 on machine that hosts a bind progrma (named bind) nmap will print : 953 open rndc instead of 953 open rndc? or 953 open bind RNDC is the name of the bind configuration service listening on that port. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397183: nmap: logic errors in regular expression parsing code
On Sun, Nov 05, 2006 at 05:15:55PM +, Jochen Voss wrote: recently I found some logic errors in nmap's copy of the pcre library. Thanks for the report. Nmap currently uses LibPCRE 6.4. The latest version at www.pcre.org is 6.7. I took a quick look at that version and found that the code you report in 1) and 2) still seems to be there, while 3) may have already been fixed. Would you report this to PCRE author Philip Hazel ([EMAIL PROTECTED]) and let us know what he says? If 6.8 is forthcoming, I may wait and upgrade to that rather than 6.7. Cheers, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397183: nmap: logic errors in regular expression parsing code
On Sun, Nov 05, 2006 at 08:04:46PM +, Jochen Voss wrote: All of these look correct to me. I think you should be fine by just using pcre 6.7. Do you agree? Yeah, I think you're right. I have upgraded to 6.7 for the next version of Nmap. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394784: debian's nmap is outdated, cannot upload fingerprints.
On Mon, Oct 23, 2006 at 11:40:15AM -0600, LaMont Jones wrote: Fyodor - any hints on when a compatible version of nmap will be official? It is hard to predict, but I would like to have a stable version out by the end of the year. People who want to submit fingerprints for the new 2nd generation system (which is highly encouraged!) can install the latest ALPHA release from Insecure.Org. ALPHA9 is available now, and I'll probably release ALPHA10 within the next day or two. It is probably best for Debian to stick with 4.11 for now, except maybe if you have an experimental tree people who want the latest goods can draw from. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386284: pearpc virtual nics for nmap-mac-prefixes
On Wed, Sep 06, 2006 at 03:20:49PM +0200, Robert Millan wrote: Pearpc uses the following default MAC addresses for its virtual nics: DEADCAFE1234 DEADCAFE1235 You might want to add them (or DEADCA) to nmap-mac-prefixes. Thanks, I have added this for the next version of Nmap. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376355: add a pair of bo2k auxiliary ports (user input/output)
On Sun, Jul 02, 2006 at 12:05:20PM +0200, Robert Millan wrote: VeritasNetbackup 13782/tcp # bpcd client VeritasNetbackup 13783/tcp # vopiedclient +bo2k 14141/tcp # Back Orifice 2K BoPeep mouse/keyboard input +bo2k 15151/tcp # Back Orifice 2K BoPeep video output swgps 15126/tcp # Nortel Java S/WGPS Global Payment Solutions for US credit card authorizations Thanks - applied for the next version of Nmap. -Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376105: nmap: returns 0 even if scan fails
On Fri, Jun 30, 2006 at 10:31:14AM +0100, George B. wrote: This is a minor/wishlist bug. I am using nmap in a script to check if a remote router (which unfortunately blocks pings) is alive. The problem is that nmap will exit with 0 even if the host is down. E.g: --- nmap -sS -p 500 -P0 10.1.75.139 echo -e \nReturns code $? Starting Nmap 4.10 ( http://www.insecure.org/nmap/ ) at 2006-06-30 10:25 BST Nmap finished: 1 IP address (0 hosts up) scanned in 0.235 seconds Returns code 0 --- Any chance nmap could be made to distinguish between successful and failed tests? For now I have to use the grep '0 hosts up' bodge to get around this. I can kind-of see your point. On the other hand, Nmap completed successfully and returned the results (the host was down). Nmap returns nonzero when there is an error and Nmap cannot complete. If Nmap was to return nonzero in your case, what should it do if you scan two machines and one machine is up and another is down? What if you scan two and they are both down? If the RC is nonzero based on whether hosts scanned are up or down, how do we inform the script that Nmap encountered an error and failed to complete? Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369669: requires working DNS even when specifiing target by IP
On Thu, Jun 01, 2006 at 11:18:30AM +0200, Robert Millan wrote: Sorry, I don't know. However, the big problem here is inability to use nmap when /etc/resolv.conf is broken. When this happens, instead of aborting, I think it should just disable whatever functionality is associated with reverse-resolution. This should be fixed in 3.10 (which Lamont just uploaded to Debian). Please give it a try and let us know if it works for you. Cheers, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373648: new boinc ports
On Wed, Jun 14, 2006 at 09:29:29PM +0200, Robert Millan wrote: - Apparently, even though the port number 1043 is assigned to BOINC (see http://www.iana.org/assignments/port-numbers) Microsoft IIS binds to it on some systems. So... core client: if can't bind to 1043, bind to 31416 BOINC mgr: if can't connect to 31416, connect to 1043 If something is bound to 31416 we're screwed. Thanks a lot, Microsoft! Patch for nmap: Thanks, applied. -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369669: requires working DNS even when specifiing target by IP
On Tue, May 30, 2006 at 07:59:15PM +0200, Robert Millan wrote: nmap requires working DNS even when specifiing target by IP: $ sudo nmap -sS -O 192.168.100.1 Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2006-05-30 19:56 CEST Unable to determine any DNS servers. Try using --system_dns or specify valid servers with --dns_servers QUITTING! Sounds like-overzealous sanity check, anyway. Once the host is determined to be a domain name, why not just attempting to resolve it using the standard library calls instead? Thanks for the report. The error message is for reverse-resolution, so it doesn't matter that you specified an IP. Do the standard library calls find DNS servers for you? If so, how? We would like to fix it so Nmap can determine the DNS servers the same way. Also, please try to reproduce the problem with the latest version of Nmap, 4.04BETA1: http://seclists.org/lists/nmap-dev/2006/Apr-Jun/0326.html Cheers, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369681: add MAC addresses for QEMU and Bochs
On Wed, May 31, 2006 at 01:49:09PM +0200, Robert Millan wrote: For nmap-mac-prefixes: 525400 QEMU B0C420 Bochs Thanks for the report, I have added these for the next version of Nmap (due out within a week): o Updated nmap-mac-prefixes to reflect the latest OUI DB from the IEEE (http://standards.ieee.org/regauth/oui/oui.txt) as of May 31, 2006. Also added a couple unregistered OUI's (for QEMU and Bochs) suggested by Robert Millan (rmh(a)aybabtu.com). Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362305: nmap: Typo in documentation: --max_scan-delay
On Thu, Apr 13, 2006 at 11:19:55AM +0200, Daniel Albers wrote: The documentation mentions --max_scan-delay and --max-scan-delay while only --max-scan-delay is valid. See the attached patch-file. Thanks for the report -- this will be fixed in the next version of Nmap. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348925: wrong example in manpage
On Thu, Jan 19, 2006 at 11:04:02PM +0100, Nico Golde wrote: Package: nmap Version: 3.95-1 Severity: minor Hi, the manpage of nmap says: This scans 4096 IPs for any webservers (without pinging them) and saves the output in grepable and XML formats. host -l company.com | cut -d -f 4 | nmap -v -iL - This will not work: host -l debian.org | LC_ALL=C cut -d -f 4 | nmap -v -iL - cut: the delimiter must be a single character Try `cut --help' for more information. The parenthesis got lost somehow -- it was supposed to be 'cut -d -f 4'. Anyway, this is a lame example for numerous reasons and so I have removed it for the next version. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342563: nmap: FTBFS on GNU/kFreeBSD
On Thu, Dec 08, 2005 at 05:00:09PM +0100, Petr Salinger wrote: the current version fails to build on GNU/kFreeBSD. It needs small changes to configure.in/configure in libdnet-stripped subdir and updated config.guess/config.sub. Please find an attached patch to configure.in/configure. I have applied your patch for the next version of Nmap. Unfortunately, there has not been a new autoconf release in more than two years :(. But I found the latest config.sub/config.guess files at http://cvs.savannah.gnu.org/viewcvs/config/config/ and have updated to those for the next Nmap release. I hope they work. Cheers, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336609: Formatting issue in the nmap.1 man page
On Mon, Oct 31, 2005 at 03:02:12PM +0100, Nicolas François wrote: Please find attached a patch which fixes a formatting issue in the nmap.1 man page. A line starting by a single quote introduce a groff macro. As the h' macro does not exist, the line is not displayed. \ is a zero width space, and prevent this issue (you can also choose to wrap the line at another place. I believe this is fixed in the all-new man page, which you can find at: http://www.insecure.org/nmap/data/nmap.1 Cheers, -F
Bug#339474: nmap: please document -I non-support in man page
On Wed, Nov 16, 2005 at 04:03:18PM +0100, Marc Haber wrote: nmap doesn's support the -I switch any more. While investigating what nmap -I does (saw the switch in a command line in an nmap process spawned by nessus), I searched in the man page and didn't find it. Please document in the man page that -I is no longer supported. Thanks for the suggestion, but I don't think I want to clutter the man page with obsolete options from older versions of Nmap. If someone has a version of Nmap that supports -I, it should still be documented in the man page associated with that version. Also, the Nmap changelog documents interface changes such as this. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339475: nmap: please document default values for options where applicable
On Wed, Nov 16, 2005 at 04:46:26PM +0100, Marc Haber wrote: Package: nmap Version: 3.93-1.0.1 Severity: wishlist Hi, please document the default values for the appropriate options in the man page. For example, it would be nice to know the defaults for -min/max_parallelism. The next version of Nmap will have an all new man page which does document this. The man page announcement (with appropriate links) is at http://seclists.org/lists/nmap-hackers/2005/Oct-Dec/0001.html . If you have any suggestions for the new man page, please do send them my way. Thanks, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324843: nmap: illegal use of varargs
On Wed, Aug 24, 2005 at 01:38:50PM +0200, Tollef Fog Heen wrote: it appears that output.cc:log_write is a bit buggy. In some cases, vsnprintf or vfprintf will be called multiple times with the same vararg argument. This is illegal according to va_start(3): We don't have a stable version with this improvement yet, but it is fixed in 3.84ALPHA1: http://seclists.org/lists/nmap-dev/2005/Jul-Sep/0041.html Thanks, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277532: nmap -oS segfault
On Thu, Mar 10, 2005 at 03:36:45AM +0100, christophe wrote:
Hmm ... that is curious. I wonder if the 4096-byte stack buffer is
too large for your system. Could you try changing:
If that has something to do with my system, I can precise it's an ibook
first generation (clamshell) with a G3 366 MHz and 128 M Ram.
Thanks for the report. I think the problem is that I used
varargs/vsnprintf in a non-portable way. You must reset the va_list
between calls to vsnprintf. Here is a patch, which will be in the
next version of Nmap:
--- output.cc (revision 2656)
+++ output.cc (working copy)
@@ -523,9 +523,10 @@
bool buf_alloced = false;
int rc = 0;
- va_start(ap, fmt);
if (l LOG_STDOUT) {
+va_start(ap, fmt);
vfprintf(o.nmap_stdout, fmt, ap);
+va_end(ap);
l-=LOG_STDOUT;
}
if (l LOG_SKID_NOXLT) { skid=0; l -= LOG_SKID_NOXLT; l |= LOG_SKID; }
@@ -534,7 +535,9 @@
{
if (!o.logfd[i] || !(l1)) continue;
while(1) {
+ va_start(ap, fmt);
rc = vsnprintf(buf,bufsz, fmt, ap);
+ va_end(ap);
if (rc = 0 rc bufsz)
break; // Successful
// D'oh! Apparently not enough space - lets try a bigger buffer
@@ -545,7 +548,6 @@
if (skid ((1i)LOG_SKID)) skid_output(buf);
fwrite(buf,1,strlen(buf),o.logfd[i]);
}
- va_end(ap);
if (buf_alloced)
free(buf);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277532: nmap -oS segfault
On Tue, Mar 08, 2005 at 02:43:07AM +0100, christophe wrote: [EMAIL PROTECTED]:~/nmap-3.81$ gdb nmap GNU gdb 6.3-debian [blablabla] (gdb) r -oS - 192.168.0.1 Starting program: /home/christophe/nmap-3.81/nmap -oS - 192.168.0.1 Program received signal SIGSEGV, Segmentation fault. 0x0fd8481c in strlen () from /lib/libc.so.6 (gdb) bt #0 0x0fd8481c in strlen () from /lib/libc.so.6 #1 0x0fd5363c in vfprintf () from /lib/libc.so.6 #2 0x0fd73d68 in vsnprintf () from /lib/libc.so.6 #3 0x1001a944 in log_write (logt=1, fmt=0x100513e4 \nStarting %s %s ( %s ) at %s\n) at output.cc:537 #4 0x10005bfc in nmap_main (argc=4, argv=0x7554) at nmap.cc:790 Hmm ... that is curious. I wonder if the 4096-byte stack buffer is too large for your system. Could you try changing: char b[4096] to char b[1024] on line 520 of output.cc, recompile, and let us know if it still crashes? If it DOES still crash, what would be useful to see is log of: gdb nmap break log_write r -oS - 192.168.0.1 [ when it stops execution, press 'n', then just keep pressing enter until it crashes, which should be less than twenty keypresses ] If you could send me the output from that test, it would be quite useful. Thanks, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294518: check for 8021/tcp (ftp-proxy)
On Thu, Feb 10, 2005 at 06:35:57AM +0100, Robert Millan wrote: 8021/tcp is a common port for ftp-proxy service in PF installations. See: http://www.openbsd.org/faq/pf/ftp.html Added for the next version of Nmap. Cheers, -F -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292419: nmap: NMap possibly violates The Debian Free Software Guidelines (DFSG)
On Wed, Jan 26, 2005 at 05:11:48PM -0500, astronut wrote: The DFSG #5 states that The license must not discriminate against any person or group of persons. Although nmap is liscenced under the GPL, it specifically forbids the SCO Group from distributing nmap. That is not discrimination against any specific person or group-- the GPL states (section 4 and 5) that companies must accept the GPL in order to redistribute GPL'd software such as Nmap. Since SCO refuses to accept the GPL terms, they have no right to redistribute Nmap. This clarification in the changelog is not meant to modify the Nmap license, but only to provide a concrete example of how we interpret the GPL. SCO has no right to redistribute Nmap unless they accept its license terms. Accordingly, I believe that they have ceased distribution of Nmap. This exact issue has been hashed over by legal minds much better than me in the Slashdot and Groklaw articles on the topic. Cheers, Fyodor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
