Comment 23 for bug 681423

Hi Seth,
thanks for your reply on this long ongoing discussion.
Looking back it seems while the two libs are alternatives to each other things slowly tend to lean more towards libssh, so less reasons than int he past to promote it IMHO.

You brought up something interesting with nmap...

# General thoughts
I think nmap is still a common tool to use and needs to stay in main.
So lets strike unseeding it from the list of options.
For curl I have no deep insight/opinion - ack to for now keeping the delta there as is.

That leaves the question what we could do about nmap.

# Only libssh2?

The same considerations are needed for libdnet as well.
That also is used as bundled lib, should/could be split and use the in-archive version.
This can be checked via the nmap prefix:
# nmap --version | grep nmap-
Compiled with: liblua-5.3.3 openssl-1.1.1c nmap-libssh2-1.8.2 libz-1.2.11 libpcre-8.39 libpcap-1.9.1 nmap-libdnet-1.12 ipv6

We see that libssh2 and libdnet are currently used as embedded libs.
But other than libssh libdnet is RECOMMENDED to be used built in:

-with-libdnet=DIR Use an existing (compiled) dnet lib from DIR/include
and DIR/lib. This is NOT RECOMMENDED because we hav
made many important fixes to our included libdnet,
as described at
./libdnet-stripped/NMAP_MODIFICATIONS

Is that still true and valid, I have no idea.
It also doesn't seem to be the same as the libdnet built from src:dnprogs
So in this case is it no duplication, but for libssh2 it is.

# back to ssh2

I was checking what ssh2 support actually means for nmap (feature wise).
There are two major changes depending if it is configured.

The obvious one is in the makefile that adds:
  nse_libssh2.cc

The other loads potential scripts that need ssh2 support:
550 #ifdef HAVE_LIBSSH2
551 {LIBSSH2LIBNAME, luaopen_libssh2},
552 #endif

The problem even on a potential conversion is that these bindings are exposed to the scripts.
And that means potentially out-of-package scripts that would break on the change.
This makes it even more complex to consider asking for a switch to libssh.

I guess we have to consider between
a) MIR and own libssh2 after all
b) disable the ssh2 features in nmap, but keep it in main

We might want to:
build without ssh2 support and check if
a) ssh scripts won't work anymore (expected)
b) we still can e.g. probe for ssh port and how much we loose (e.g. server identification)

I'll talk to the Team and get back to you on this Seth.