Please don't let ncat take over nc
Issue report
When you install ncat (from nmap package), the default nc symlink is changed to point to ncat rather than nc.traditional. This is annoying behaviour.
So, my problems are:
- I need to use the ncat proxy functionality
- I need to provide an environment with everything pre-installed, so that includes ncat
- However I also need to use the legacy nc (for compatibility, for it's extra features, and also for the output that is used in teaching material)
- Therefore ncat taking over nc is not practical. I need to use both ncat and nc: they are different tools. There isn't really a benefit to ncat overwriting the nc symlink, unless you're a conventional computer user who is happy "upgrading" to ncat.
nc-traditional
- support-e
, thus would be preferred optionnetcat
- does support-e
, but has like 3x extra lines of output, compared to saync-*
, so yeah, functionally it works, but the output is different.nc-openbsd
- doesn’t support-e
, but the output is " right "
Investigation
A story of 3 cats
So there are 3 packages that provide an alternative for nc:
nc-traditional: 10
nmap's netcat: 40
nc-openbsd: 50
None of them are 100% compatible. It is well-known that they have different options, missing features, extra features, different output, and so on...
In particular, OpenBSD nc is famous for lacking -e
and -c
options, and that's on purpose. Quoting https://salsa.debian.org/debian/netcat-openbsd/-/blob/debian/latest/debian/netcat-openbsd.README.Debian:
For record, the reason of not implementing features like -c or -e in this cat is about security. These options enable anyone on the system to open port and execute arbitrary command on local host from remote very easily, which is not desired for ordinary multi-user systems. If you do need such function, please try nc.traditional or nc6.
While nmap's netcat is a different beast, and it never attempted to provide a drop-in replacement for nc. The output is completely different. Looking at the man page, we can't find anything saying that it aims at compatibility, the only things we find regarding legacy nc are:
Ncat was written for the Nmap Project and is the culmination of the currently splintered family of Netcat incarnations. [...] While Ncat isn't built on any code from the “traditional” Netcat (or any other implementation), Ncat is most definitely based on Netcat in spirit and functionality.
If they are different cats, why provide the nc
alternative? Well, OpenBSD binary is really named nc
, the traditional nc is also named nc
, so obviously there's a need for an alternative to let them both be co-installable.
However for nmap's netcat, it's a different story, because the binary provided by upstream is named ncat
. So there is no strong reason to go and claim nc
name. So why?
What other distros do
The reason why it was added to the pool of nc alternatives can be found at https://bugs.debian.org/881639:
The clevis package (ITP #854410) needs a netcat for the dracut unlocker, and an alpha tester reported the implementations provided by both -traditional and -openbsd don't fit the needs. I was told Redhat (where clevis comes from) uses nmap's ncat for nc, and things work fine then.
In practice though, clevis dropped the dependency on ncat a while ago: https://github.com/latchset/clevis/commit/9cdd0415e018c7ef441788549f41261b7faf4f53. So the reason above doesn't really hold anymore.
Another interesting aspect of this story is that, in the Red Hat's world, it seems that nc is provided by nmap's ncat.
Without knowing much about Red Hat's side of things, I did a little research, and it appears that the legacy nc was never packaged over there, or it was removed a very long time ago. Maybe due to licensing.
Back in 2012, they dropped the OpenBSD version, in favor of nmaps' version: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MJOCCQGUY7PYL3G42JJA6JKRLMQ2YXBN/ . This was a hard replacement, as there was no alternative symlink. Not everybody was happy with that.
What follows is:
- 2016, bug report: #1321136: nc is not backwards compatible, breaking existing software
- 2018, use alternative symlink: #1653119: Make /usr/bin/nc a symlink using alternatives(1) to allow switching to OpenBSD nc(1)
- 2021, OpenBSD's netcat is back: #1939769: Review Request: netcat - OpenBSD netcat to read and write data across connections using TCP/IP
However, the details that matters is that it's NOT back in Red Hat's repo, but instead in EPEL, aka Extra Packages for Enterprise Linux.
So to this day, it seems that in Red Hat's world, nc = nmap's ncat.
Way forward
To sum up: nmap's ncat was added as an nc alternative for a reason that is not valid anymore. Still, having it in the pool of alternative still has the nice effect to provide some degree of compatibility with Red Hat nc, for those that need it.
It seems to me that we should keep it in the alternatives, but lower the priority below all the other ones. This way, it won't take over nc by default, but for users who need it, it's still possible.