Notices

Do I understand it correctly as "no plans for putting it into repos, as I'll work on PPP"?

Just uploaded to the auto builder the new nmap 6.46 with fixed zenmap to run with python 2.5.

Nmap version 6.46 ( http://nmap.org )
Platform: arm-unknown-linux-gnueabi
Compiled with: nmap-liblua-5.2.3 openssl-0.9.8n nmap-libpcre-7.6 nmap-libpcap-1.2.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Enjoy the power of nmap scripts!

Examples:
nmap -sV -d --script=ssl-heartbleed domain.com
nmap --script ssl-enum-ciphers.nse domain.com
nmap -sV -d --script=broadcast-upnp-info

So I see NMap got updated (awesome) and that the prior devel version was pushed to testing (what?).

Now, I get that we're a dwindling community and the users of testing probably number in the single digits, but there was a reason why the original maintainer never pushed the update to testing: it simply didn't work on the stock driver like the prior versions, and only worked on the injection-capable one (I think something about interfaces changed and the new one had it while the old one didn't).

So what, we pushed a package that simply does not work with the stock driver, into testing? And we did NOT update the dependency list to specify that any of the packages that provide the injection drivers (that also provide whatever else we still need)? As maintainers we shouldn't be doing that.

I guess it's partly my fault: I actually failed to step up as maintainer myself (but in my defence, I also didn't know I was maintainer until about a month or two ago, no idea when my maintainer request got approved; and I have been trying to finish college and secure a fulltime well-paying job so that I could afford to contribute to things like this later.)

xes: All of the above said, I really appreciate you getting this release out (whether it's one release or indefinite maintenance).Thank you for taking the time and effort to do so.

Just did a cursory test with the new devel version: it works with both stock and injection drivers. That's awesome - maybe this was already addressed in this thread and I missed it, but in either case, props to whoever fixed it (whether those props have to bubble up the maintaner chain to nmap's maker or they stay down here with xes or whoever).

Now this to me seems much more worthy of promotion to testing than the 5.59-BETA1 or whatever was pushed to testing previously, simply by strenth of the increased compatibility and useful ease of usability alone.

QFT, because saying it once doesn't emphasize how much I feel this.

Oh, one more thing: I kinda half-flipped when I saw this, but been so busy couldn't get around to making a note of it here (seriously, someone please yell at me like once a week until it's addressed):

The aforementioned version of this in extras-devel added nmap and ncat to 'NOPASSWD' sudoers. This introduces a security issue. Why? Because ncat can launch arbitrary programs and then connect up to them. So even if you have a fairly locked down N900 with sudo password protected across all invocations (as I do on mine), that update comes in, and unless you KNOW it has been thus tweaked (which I didn't just getting the update over apt-get), that extra sudoers entry just opens the door to everything, because now effectively any process on the device can run 'sudo ncat [parameters to run 'sh' or arbitrary command]', and either do another ncat instance to connect up to that very root shell, or just sit back and let the aforementioned arbitrary command does it's thing.

...honestly, the more I think about it, the more I hate the convention we have here in our repos of adding entries to sudoers to let people run things at their leisure, because such habits cause things like this.

If no one else thinks of something better, what I'd like to do is push a separate package that provides the sudoers entries (like "nmap-sudoers") and that's it, and then push an upgrade that removes these new sudoers entries from the main nmap package.

I really appreciate your security worries and i would see more checks like this for all the crucial packages we have here.

Latest package followed the insane approach to make an intense use of sudo because the previous one was prepared in the same way and evaluating the long time since last update the painless step and more reasonable way (to me) was to pick up the package and update following the previous situation.

Now, since all the feedback received here sounds like a silent/consent to the last package version, we (I / YOU) can proceed with further changes.

Anyway, i think that have an updated nmap version is very important considering the package purpose and leaving it there "just sleeping" for 3 years sounds like abandoned and not acceptable.

I was expecting for the new version 6.47 to be released to prepare another package, but, if you have more time than me to take care of it, as older maintainer, feel free to go ahead!

I also appreciate your efforts.
But:
this is for one package only.
Even we/techstaff would find a solution, it is so much easy to put a postinst script adding whatever you do not like. So security wise one would need to throw a look into each deb you install.

Another but: go ahead, please.
Fixing it one by one is our only chance.

--
Just to clarify:
I just wanted to express that a 'safe' package needs to be checked either way. One could use such sudoers or just some postinst script to break into your device. But this is surely not the thing here but probably mis-packaging (like sudser package which I re-configured pretty early). So I would propose to change this behaviour in the sudoers file.

Re: sudoers

I think it would be too much effort to clean-up all packages to remove the package-specific sudoers files.

What might work nicely would be to re-work /usr/sbin/update-sudoers (part of sudo package), which is the one actually generating the sudoers file based on the files available under /etc/sudoers.d/ (which is where packages place their sudo-stuff).

My idea would be to patch update-sudoers so that it does nothing (hence preventing a rogue postint from breaking your system before you have a chance to fix it) and then make a customized version of update-sudoers (called "update-sudoers-really" or something to that effect), which either does everything automatically (like now) or interactively ("do you want to integrate nmap.sudoers in your sudoers list? [y/N]") or using some rule file ("01sudoers = Y, nmap = N, powertop = Y, default = ask", etc.)

I guess the issue is not so critical for now (after all, each one can take care of his/her sudoers file), but adapting the script would be quite easy.

Then we could provide a package like "sudo-sanitize" which could replace update-sudoers using some debian-fu (alternatives) to keep dpkg and apt-get happy with replacing a file which is part of the sudo package.

I'll add it to my list.

Yeah, good idea.

But that would help us geeks. Normal user does not know about sudoers. And maybe should not know ?

Some packages need some sudo voodooo (I do) to get things working. And to ask the user to run update-sudoers as root?

But I will accept any other good reason/explanation!

I'm getting following error when trying to install latest nmap package:

WTF?

For the record, there was other error that was breaking configure (trying to optify /usr/share/doc/nmap, which doesnmt exist), but it is well-known and workaround consist of just touch /usr/share/doc/nmap.

/Estel