| Message ID | 20171004154313.25762-1-casantos@datacom.ind.br |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] nmap: add option to build/install "ncat" | expand |
Hi Carlos, Sorry to iterate yet another time on this patch... On 04-10-17 17:43, Carlos Santos wrote: > Ncat is a much-improved reimplementation of the venerable Netcat and is > compatible with uClibc. > > So far the "nc" options available to build with uClibc were the ancient uClibc and musl. > GNU netcat and its Busybox double (the openbsd-netcat package cannot be The package is called netcat-openbsd. > used because it requires GLIBC). Both lack features available in modern > netcats like IPv6, proxies, and Unix sockets. > > Signed-off-by: Carlos Santos <casantos@datacom.ind.br> [snip] > diff --git a/package/nmap/Config.in b/package/nmap/Config.in > index 79f587afd1..a2e330dacd 100644 > --- a/package/nmap/Config.in > +++ b/package/nmap/Config.in > @@ -11,6 +11,19 @@ config BR2_PACKAGE_NMAP > > http://nmap.org > > +if BR2_PACKAGE_NMAP > + > +config BR2_PACKAGE_NMAP_NCAT > + bool "nmap-ncat" ncat itself is very small (+- 150K) compared to the rest of nmap (+- 2.5M), so it's not really worth making a config option for it. Conversely, it *could* be worthwhile to have an option BR2_PACKAGE_NMAP_NCAT_ONLY that just installs the ncat tool (+symlink) from the package. So my idea would be: - always build with ncat and install the symlink; - if BR2_PACKAGE_NMAP_NCAT_ONLY is selected, override the install commands to just install ncat + symlink. Perhaps to be sure you can do it as two patches, first one that always enables ncat and installs symlink, second one that adds the BR2_PACKAGE_NMAP_NCAT_ONLY option. That kind of option is a bit controversial (it's a "negative" option because it removes stuff from the nmap package; we generally prefer additive options instead, but that would be a bit complicated here). One more thing though: are the ncat options compatible with those for netcat-openbsd? And I'm talking about the options that are not in busybox or GNU netcat now. If they are not compatible (and a quick look at the man pages tells me that only the -6 and -U options are the same), I feel awkward about creating the symlink: since you need to know which netcat type you're using, you could just as well call ncat directly. And for scripts that don't rely on any of these, the busybox or GNU nc is enough. Regards, Arnout > + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS > + help > + Ncat is a feature-packed networking utility which reads and > + writes data across networks from the command line. Ncat was > + written for the Nmap Project as a much-improved > + reimplementation of the venerable Netcat. > + > +endif > + > comment "nmap needs a toolchain w/ C++, threads" > depends on BR2_USE_MMU > depends on !(BR2_INSTALL_LIBSTDCPP && BR2_TOOLCHAIN_HAS_THREADS) > diff --git a/package/nmap/nmap.mk b/package/nmap/nmap.mk > index 9db06d1455..fb16c2887d 100644 > --- a/package/nmap/nmap.mk > +++ b/package/nmap/nmap.mk > @@ -10,7 +10,7 @@ NMAP_SOURCE = nmap-$(NMAP_VERSION).tar.bz2 > NMAP_DEPENDENCIES = libpcap pcre > NMAP_CONF_OPTS = --without-liblua --without-zenmap \ > --with-libdnet=included --with-liblinear=included \ > - --with-libpcre="$(STAGING_DIR)/usr" --without-ncat > + --with-libpcre="$(STAGING_DIR)/usr" > NMAP_LICENSE = GPL-2.0 > NMAP_LICENSE_FILES = COPYING > > @@ -50,4 +50,17 @@ else > NMAP_CONF_OPTS += --without-ndiff > endif > > +ifeq ($(BR2_PACKAGE_NMAP_NCAT),y) > + > +define NMAP_INSTALL_NCAT_SYMLINK > + ln -fs ncat $(TARGET_DIR)/usr/bin/nc > +endef > +NMAP_POST_INSTALL_TARGET_HOOKS += NMAP_INSTALL_NCAT_SYMLINK > + > +else > + > +NMAP_CONF_OPTS += --without-ncat > + > +endif > + > $(eval $(autotools-package)) >
> From: "Arnout Vandecappelle" <arnout@mind.be> > To: "Carlos Santos" <casantos@datacom.ind.br>, buildroot@buildroot.org > Cc: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, "Maxime Hadjinlian" <maxime.hadjinlian@gmail.com> > Sent: Friday, October 6, 2017 4:58:19 PM > Subject: Re: [Buildroot] [PATCH v2] nmap: add option to build/install "ncat" > Hi Carlos, > > Sorry to iterate yet another time on this patch... > > On 04-10-17 17:43, Carlos Santos wrote: >> Ncat is a much-improved reimplementation of the venerable Netcat and is >> compatible with uClibc. >> >> So far the "nc" options available to build with uClibc were the ancient > > uClibc and musl. OK >> GNU netcat and its Busybox double (the openbsd-netcat package cannot be > > The package is called netcat-openbsd. OK >> used because it requires GLIBC). Both lack features available in modern >> netcats like IPv6, proxies, and Unix sockets. >> >> Signed-off-by: Carlos Santos <casantos@datacom.ind.br> > [snip] >> diff --git a/package/nmap/Config.in b/package/nmap/Config.in >> index 79f587afd1..a2e330dacd 100644 >> --- a/package/nmap/Config.in >> +++ b/package/nmap/Config.in >> @@ -11,6 +11,19 @@ config BR2_PACKAGE_NMAP >> >> http://nmap.org >> >> +if BR2_PACKAGE_NMAP >> + >> +config BR2_PACKAGE_NMAP_NCAT >> + bool "nmap-ncat" > > ncat itself is very small (+- 150K) compared to the rest of nmap (+- 2.5M), so > it's not really worth making a config option for it. > > Conversely, it *could* be worthwhile to have an option > BR2_PACKAGE_NMAP_NCAT_ONLY that just installs the ncat tool (+symlink) from the > package. So my idea would be: > > - always build with ncat and install the symlink; > - if BR2_PACKAGE_NMAP_NCAT_ONLY is selected, override the install commands to > just install ncat + symlink. > > Perhaps to be sure you can do it as two patches, first one that always enables > ncat and installs symlink, second one that adds the BR2_PACKAGE_NMAP_NCAT_ONLY > option. That kind of option is a bit controversial (it's a "negative" option > because it removes stuff from the nmap package; we generally prefer additive > options instead, but that would be a bit complicated here). That's what I did in https://patchwork.ozlabs.org/patch/820503/. I can give it a another try but I hope you guys reach an agreement about what you want. :-) > One more thing though: are the ncat options compatible with those for > netcat-openbsd? And I'm talking about the options that are not in busybox or GNU > netcat now. If they are not compatible (and a quick look at the man pages tells > me that only the -6 and -U options are the same), I feel awkward about creating > the symlink: since you need to know which netcat type you're using, you could > just as well call ncat directly. And for scripts that don't rely on any of > these, the busybox or GNU nc is enough. This diversity is already known. Debian/Ubuntu uses netcat-openbsd as its nc command while Fedora/RHEL uses nmap-ncat. The user of "nc" that I have in mind is virt-manager, which is used to manage libvirtd (check https://patchwork.ozlabs.org/patch/814396/). virt-manager accesses the target machine via ssh and there it runs nc connect to the unix socket on which libvirtd listens. The connection script tests what syntax the nc command recognizes. Obviously the same restrictions would apply to any software depending on nc but already happens, since buildroot provides three different nc commands, so I do not consider the diversity a regression.
On 09-10-17 18:13, Carlos Santos wrote: [snip] >> ncat itself is very small (+- 150K) compared to the rest of nmap (+- 2.5M), so >> it's not really worth making a config option for it. >> >> Conversely, it *could* be worthwhile to have an option >> BR2_PACKAGE_NMAP_NCAT_ONLY that just installs the ncat tool (+symlink) from the >> package. So my idea would be: >> >> - always build with ncat and install the symlink; >> - if BR2_PACKAGE_NMAP_NCAT_ONLY is selected, override the install commands to >> just install ncat + symlink. >> >> Perhaps to be sure you can do it as two patches, first one that always enables >> ncat and installs symlink, second one that adds the BR2_PACKAGE_NMAP_NCAT_ONLY >> option. That kind of option is a bit controversial (it's a "negative" option >> because it removes stuff from the nmap package; we generally prefer additive >> options instead, but that would be a bit complicated here). > > That's what I did in https://patchwork.ozlabs.org/patch/820503/. > I can give it a another try but I hope you guys reach an agreement > about what you want. :-) Well, that patch (and its v1 and v2) introduced a virtual package for nc and AFAICS you only got comments on the virtual package aspect. I don't think anybody commented on having a BR2_PACKAGE_NMAP_NCAT_ONLY option. You anyway didn't have that, you had a BR2_PACKAGE_NMAP_NMAP option, but I don't think you got any direct comments on that choice. That said, it's indeed a good idea to converge on the right approach upfront. Thomas, Peter, what do you think? I'm also adding Yann in Cc, he usually has bright ideas about this kind of thing. The options (that I see): 1. Current patch, i.e. BR2_PACKAGE_NMAP builds just nmap and BR2_PACKAGE_NMAP_NCAT builds nmap + ncat. 2. No specific option, always install nmap + ncat if BR2_PACKAGE_NMAP is selected. Note that this might create a problem if both nmap and netcat-openbsd are selected, so there should probably be a dependency introduced and a check that nc doesn't exist yet before creating the symlink. 3. BR2_PACKAGE_NMAP_NCAT_ONLY *disables* nmap. 4. New option BR2_PACKAGE_NMAP_NMAP to build nmap (this option should default y for backward compatibility). ncat is always built if BR2_PACKAGE_NMAP is selected. So BR2_PACKAGE_NMAP means ncat, and BR2_PACKAGE_NMAP_NMAP means nmap + ncat. 5. BR2_PACKAGE_NMAP builds nothing, two new options BR2_PACKAGE_NMAP_NMAP and BR2_PACKAGE_NMAP_NCAT build nmap resp. ncat. To avoid building nothing, you could try something like config BR2_PACKAGE_NMAP select BR2_PACKAGE_NMAP_NCAT if !BR2_PACKAGE_NMAP_NMAP if BR2_PACKAGE_NMAP config BR2_PACKAGE_NMAP_NMAP default y config BR2_PACKAGE_NMAP_NCAT endif but that might give a circular dependency. >> One more thing though: are the ncat options compatible with those for >> netcat-openbsd? And I'm talking about the options that are not in busybox or GNU >> netcat now. If they are not compatible (and a quick look at the man pages tells >> me that only the -6 and -U options are the same), I feel awkward about creating >> the symlink: since you need to know which netcat type you're using, you could >> just as well call ncat directly. And for scripts that don't rely on any of >> these, the busybox or GNU nc is enough. > > This diversity is already known. Debian/Ubuntu uses netcat-openbsd > as its nc command while Fedora/RHEL uses nmap-ncat. The user of "nc" > that I have in mind is virt-manager, which is used to manage libvirtd > (check https://patchwork.ozlabs.org/patch/814396/). > > virt-manager accesses the target machine via ssh and there it runs nc > connect to the unix socket on which libvirtd listens. The connection > script tests what syntax the nc command recognizes. > > Obviously the same restrictions would apply to any software depending > on nc but already happens, since buildroot provides three different nc > commands, so I do not consider the diversity a regression. OK, makes sense. Perhaps you can add something like this to the commit log. We symlink 'nc' to ncat, even though ncat does not have the same interface as netcat-openbsd. However, since Fedora/RHEL install nmap-ncat as 'nc', it can be assumed that packages that depend on 'nc' know how to deal with this diversity. For example, the virt-manager package does that. Also user-supplied scripts can be assumed to do the right thing, since the user also selects whether nmap-ncat or netcat-openbsd is installed. Regards, Arnout
On 10-10-17 00:08, Arnout Vandecappelle wrote: > 2. No specific option, always install nmap + ncat if BR2_PACKAGE_NMAP is > selected. Note that this might create a problem if both nmap and netcat-openbsd > are selected, so there should probably be a dependency introduced and a check > that nc doesn't exist yet before creating the symlink. Let me clarify that bit: in all the other options, the user makes a conscious decision to enable ncat (and therefore the nc symlink). With this option, however, the nc symlink will be created without the user being aware of it, so it could be that it is not what the user intended. This is only a problem if netcat-openbsd is also installed (since ncat is a strict superset of GNU and busybox nc). Regards, Arnout
> From: "Arnout Vandecappelle" <arnout@mind.be> > To: "Carlos Santos" <casantos@datacom.ind.br> > Cc: buildroot@buildroot.org, "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, "Maxime Hadjinlian" > <maxime.hadjinlian@gmail.com>, "Peter Korsgaard" <peter@korsgaard.com>, "Yann E. MORIN" <yann.morin.1998@free.fr> > Sent: Monday, October 9, 2017 7:10:55 PM > Subject: Re: [Buildroot] [PATCH v2] nmap: add option to build/install "ncat" > On 10-10-17 00:08, Arnout Vandecappelle wrote: >> 2. No specific option, always install nmap + ncat if BR2_PACKAGE_NMAP is >> selected. Note that this might create a problem if both nmap and netcat-openbsd >> are selected, so there should probably be a dependency introduced and a check >> that nc doesn't exist yet before creating the symlink. > > Let me clarify that bit: in all the other options, the user makes a conscious > decision to enable ncat (and therefore the nc symlink). With this option, > however, the nc symlink will be created without the user being aware of it, so > it could be that it is not what the user intended. This is only a problem if > netcat-openbsd is also installed (since ncat is a strict superset of GNU and > busybox nc). That was one of the advantages of the virtual package "nc": it would require the user to choose only one netcat variant at a time. Anyway, I can make the link creation optional or create it only if none of the competing netcat variants is selected.
On 10-10-17 01:55, Carlos Santos wrote: >> From: "Arnout Vandecappelle" <arnout@mind.be> >> To: "Carlos Santos" <casantos@datacom.ind.br> >> Cc: buildroot@buildroot.org, "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, "Maxime Hadjinlian" >> <maxime.hadjinlian@gmail.com>, "Peter Korsgaard" <peter@korsgaard.com>, "Yann E. MORIN" <yann.morin.1998@free.fr> >> Sent: Monday, October 9, 2017 7:10:55 PM >> Subject: Re: [Buildroot] [PATCH v2] nmap: add option to build/install "ncat" > >> On 10-10-17 00:08, Arnout Vandecappelle wrote: >>> 2. No specific option, always install nmap + ncat if BR2_PACKAGE_NMAP is >>> selected. Note that this might create a problem if both nmap and netcat-openbsd >>> are selected, so there should probably be a dependency introduced and a check >>> that nc doesn't exist yet before creating the symlink. >> >> Let me clarify that bit: in all the other options, the user makes a conscious >> decision to enable ncat (and therefore the nc symlink). With this option, >> however, the nc symlink will be created without the user being aware of it, so >> it could be that it is not what the user intended. This is only a problem if >> netcat-openbsd is also installed (since ncat is a strict superset of GNU and >> busybox nc). > > That was one of the advantages of the virtual package "nc": it > would require the user to choose only one netcat variant at a time. > > Anyway, I can make the link creation optional or create it only if > none of the competing netcat variants is selected. Good plan indeed. Regards, Arnout
Hello, On Tue, 10 Oct 2017 00:08:38 +0200, Arnout Vandecappelle wrote: > 5. BR2_PACKAGE_NMAP builds nothing, two new options BR2_PACKAGE_NMAP_NMAP and > BR2_PACKAGE_NMAP_NCAT build nmap resp. ncat. To avoid building nothing, you > could try something like > > config BR2_PACKAGE_NMAP > select BR2_PACKAGE_NMAP_NCAT if !BR2_PACKAGE_NMAP_NMAP > > if BR2_PACKAGE_NMAP > config BR2_PACKAGE_NMAP_NMAP > default y > > config BR2_PACKAGE_NMAP_NCAT > endif > > but that might give a circular dependency. This option has my preference. And it doesn't have a circular dependency, we use this construct in several places already. One example: config BR2_PACKAGE_ANDROID_TOOLS bool "android-tools" select BR2_PACKAGE_ANDROID_TOOLS_ADBD if \ !BR2_PACKAGE_ANDROID_TOOLS_FASTBOOT && \ !BR2_PACKAGE_ANDROID_TOOLS_ADB if BR2_PACKAGE_ANDROID_TOOLS config BR2_PACKAGE_ANDROID_TOOLS_FASTBOOT bool "fastboot" config BR2_PACKAGE_ANDROID_TOOLS_ADB bool "adb" config BR2_PACKAGE_ANDROID_TOOLS_ADBD bool "adbd" endif However, perhaps we should invert the select: select BR2_PACKAGE_NMAP_NMAP if !BR2_PACKAGE_NMAP_NCAT and drop the "default y" in BR2_PACKAGE_NMAP_NMAP. This way, we still have "nmap" enabled by default, and now allow the option to select ncat. Best regards, Thomas
Thomas, Carlos, Arnout, All, On 2017-10-10 10:12 +0200, Thomas Petazzoni spake thusly: > On Tue, 10 Oct 2017 00:08:38 +0200, Arnout Vandecappelle wrote: > > 5. BR2_PACKAGE_NMAP builds nothing, two new options BR2_PACKAGE_NMAP_NMAP and > > BR2_PACKAGE_NMAP_NCAT build nmap resp. ncat. To avoid building nothing, you > > could try something like > > > > config BR2_PACKAGE_NMAP > > select BR2_PACKAGE_NMAP_NCAT if !BR2_PACKAGE_NMAP_NMAP > > > > if BR2_PACKAGE_NMAP > > config BR2_PACKAGE_NMAP_NMAP > > default y > > > > config BR2_PACKAGE_NMAP_NCAT > > endif > > > > but that might give a circular dependency. > > This option has my preference. And it doesn't have a circular > dependency, we use this construct in several places already. > > One example: > > config BR2_PACKAGE_ANDROID_TOOLS > bool "android-tools" > select BR2_PACKAGE_ANDROID_TOOLS_ADBD if \ > !BR2_PACKAGE_ANDROID_TOOLS_FASTBOOT && \ > !BR2_PACKAGE_ANDROID_TOOLS_ADB > > if BR2_PACKAGE_ANDROID_TOOLS > > config BR2_PACKAGE_ANDROID_TOOLS_FASTBOOT > bool "fastboot" > > config BR2_PACKAGE_ANDROID_TOOLS_ADB > bool "adb" > > config BR2_PACKAGE_ANDROID_TOOLS_ADBD > bool "adbd" > > endif > > However, perhaps we should invert the select: > > select BR2_PACKAGE_NMAP_NMAP if !BR2_PACKAGE_NMAP_NCAT > > and drop the "default y" in BR2_PACKAGE_NMAP_NMAP. This way, we still > have "nmap" enabled by default, and now allow the option to select ncat. Since Arnout pulled me in the discussion, here is my stake at it: I second Thomas' position on this. ;-) Regards, Yann E. MORIN. > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
diff --git a/package/nmap/Config.in b/package/nmap/Config.in index 79f587afd1..a2e330dacd 100644 --- a/package/nmap/Config.in +++ b/package/nmap/Config.in @@ -11,6 +11,19 @@ config BR2_PACKAGE_NMAP http://nmap.org +if BR2_PACKAGE_NMAP + +config BR2_PACKAGE_NMAP_NCAT + bool "nmap-ncat" + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS + help + Ncat is a feature-packed networking utility which reads and + writes data across networks from the command line. Ncat was + written for the Nmap Project as a much-improved + reimplementation of the venerable Netcat. + +endif + comment "nmap needs a toolchain w/ C++, threads" depends on BR2_USE_MMU depends on !(BR2_INSTALL_LIBSTDCPP && BR2_TOOLCHAIN_HAS_THREADS) diff --git a/package/nmap/nmap.mk b/package/nmap/nmap.mk index 9db06d1455..fb16c2887d 100644 --- a/package/nmap/nmap.mk +++ b/package/nmap/nmap.mk @@ -10,7 +10,7 @@ NMAP_SOURCE = nmap-$(NMAP_VERSION).tar.bz2 NMAP_DEPENDENCIES = libpcap pcre NMAP_CONF_OPTS = --without-liblua --without-zenmap \ --with-libdnet=included --with-liblinear=included \ - --with-libpcre="$(STAGING_DIR)/usr" --without-ncat + --with-libpcre="$(STAGING_DIR)/usr" NMAP_LICENSE = GPL-2.0 NMAP_LICENSE_FILES = COPYING @@ -50,4 +50,17 @@ else NMAP_CONF_OPTS += --without-ndiff endif +ifeq ($(BR2_PACKAGE_NMAP_NCAT),y) + +define NMAP_INSTALL_NCAT_SYMLINK + ln -fs ncat $(TARGET_DIR)/usr/bin/nc +endef +NMAP_POST_INSTALL_TARGET_HOOKS += NMAP_INSTALL_NCAT_SYMLINK + +else + +NMAP_CONF_OPTS += --without-ncat + +endif + $(eval $(autotools-package))
Ncat is a much-improved reimplementation of the venerable Netcat and is compatible with uClibc. So far the "nc" options available to build with uClibc were the ancient GNU netcat and its Busybox double (the openbsd-netcat package cannot be used because it requires GLIBC). Both lack features available in modern netcats like IPv6, proxies, and Unix sockets. Signed-off-by: Carlos Santos <casantos@datacom.ind.br> --- Changes v1->v2: - Add dependens on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, like netcat does - Remove forced dependence on busybox, since its installation script does not override existing programs. --- package/nmap/Config.in | 13 +++++++++++++ package/nmap/nmap.mk | 15 ++++++++++++++- 2 files changed, 27 insertions(+), 1 deletion(-)