Dear Maintainer, Please consider lowering the priority of ncat below nc.traditional, or remove it completely from the nc alternatives. At the moment, there are 3 alternatives for nc: # update-alternatives --list nc /bin/nc.openbsd /bin/nc.traditional /usr/bin/ncat The alternatives for nc.openbsd and nc.traditional are necessary as they both provide the bin/nc binary, however it's not strictly necessary for ncat, as it comes under the name bin/ncat. And indeed, for a long while ncat was NOT part of the nc alternatives, it was added only in response to bug https://bugs.debian.org/881639, and was released with src:nmap 7.70+dfsg1-2 in April 2018. Quoting the bug above: https://github.com/latchset/clevis/commit/9cdd0415 (Dec 2020). So the reason that prompted this change in ncat is not valid anymore. I think it's still useful to have ncat amongst nc alternatives though. Even though it's not needed for clevis anymore, this bug demonstrated that there can be use-cases for which it's useful to have nc == ncat. If only for compatibility with Redhat. However I think it shouldn't have a higher priority than nc.traditional. I think it should be opt-in, it should replace nc only if users want it to, by running update-alternatives manually. The main reason is that ncat is not a drop-in replacement for nc, it's not 100% compatible, it has a very different output, etc... We have users in Kali Linux who have been beaten by this. They use nc, they also need ncat for the extra options it provides, they install it, and then are very surprised that nc is now ncat. From their background (I'm talking about professional pentesters), nc and ncat are different tools, they really don't expect ncat to replace nc. Therefore I suggest to lower the priority of the ncat alternative to zero, so that upon installation it does NOT replace nc. Thanks, Arnaud
* Arnaud Rebillout: I'd like to see in what way people have been irritateed. Can you link to specific bug reports or mailing list/form discussions? Cheers, -Hilko
On Wed, 18 Jan 2023 23:04:54 +0100 Hilko Bengen <bengen@debian.org> wrote: > > We have users in Kali Linux who have been beaten by this. They use nc, > > they also need ncat for the extra options it provides, they install it, > > and then are very surprised that nc is now ncat. From their background > > (I'm talking about professional pentesters), nc and ncat are different > > tools, they really don't expect ncat to replace nc. > > I'd like to see in what way people have been irritateed. Can you link to > specific bug reports or mailing list/form discussions? From my understanding, one big difference between nc and ncat is the output. ncat's output is very different from nc, much more verbose apparently. This is not always suitable, for example some folks have teaching material with nc, where they demonstrate nc's commands and output. They also need to use ncat in those courses, but from the moment ncat is installed, nc's output become ncat, the output is much more verbose. It's kind of confusing, and even though they *could* update their courses to show ncat's output (instead of nc), and explain that "after installing ncat, nc is now ncat", it's just not what they want, because ncat's output is too verbose, while nc output is just right (for the purpose of teaching material). Another point, as I understand it, is just that ncat and nc have always been two different tools (although they clearly have some big overlap), at least in Debian & Kali, since before April 2018, they have always been distributed as two different tools. So users have been used to install & use nc when needed, install & use ncat when needed, and sometimes install & use both, each for a specific purpose. While the use-case of having ncat == nc exists, I have the impression that it's maybe not the main use-case. I will reach out to the folks who reported this issue, and try to get them to provide more details on this bug report. Also, for transparency: those folks are from Offensive Security, which is also my employer (Kali Linux is developed by Offensive Security). Apologizes for not stating that in my initial message. Cheers,
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