NetBSD Problem Report #58281

From martin@aprisoft.de  Sat May 25 12:06:14 2024
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 498FC1A923C
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 25 May 2024 12:06:14 +0000 (UTC)
Message-Id: <20240525120604.DEB4A5CC79B@emmas.aprisoft.de>
Date: Sat, 25 May 2024 14:06:04 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: ftp(1) should have a strict failure exit code option
X-Send-Pr-Version: 3.95

>Number:         58281
>Category:       bin
>Synopsis:       ftp(1) should have a strict failure exit code option
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat May 25 12:10:01 +0000 2024
>Last-Modified:  Fri Jul 19 04:35:01 +0000 2024
>Originator:     Martin Husemann
>Release:        NetBSD 10.0_STABLE
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD emmas.aprisoft.de 10.0_STABLE NetBSD 10.0_STABLE (EMMAS) #7: Sun Apr 28 16:05:18 CEST 2024 martin@seven-days-to-the-wolves.aprisoft.de:/work/src-10/sys/arch/amd64/compile/EMMAS amd64
Architecture: x86_64
Machine: amd64
>Description:

It is possible to use ftp(1) in scripts to auto-download e.g. software
updates. But if the connection fails midway (due to network issues)
a sucess error code is returned to the shell. This makes auto-update
scripts prone to silent failure.

Example:

Requesting https://.....
  4% |*                                  |  6779 KiB    9.78 KiB/s  4:30:23 ETA
6941845 bytes retrieved in 11:32 (9.78 KiB/s)

and exit status is zero. As you can see from the transfer rate the connection
was ... challenged, and something timed out and droped the whole connection
midway. The client does not report this in any way that I can find, and
the announced size of the file is not easily available to the script
unless the whole application transfers a manifest first.

>How-To-Repeat:
s/a

>Fix:
Add a command line option to force the exit status to indicate failure
if less than the original announced number of bytes have been received?

>Audit-Trail:
From: Luke Mewburn <luke@mewburn.net>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/58281: ftp(1) should have a strict failure exit code option
Date: Fri, 19 Jul 2024 12:39:02 +1000

 On 24-05-25 12:10, martin@NetBSD.org wrote:
   | >Number:         58281
   | >Category:       bin
   | >Synopsis:       ftp(1) should have a strict failure exit code option
   | >Description:
   | 
   | It is possible to use ftp(1) in scripts to auto-download e.g. software
   | updates. But if the connection fails midway (due to network issues)
   | a sucess error code is returned to the shell. This makes auto-update
   | scripts prone to silent failure.

 That's a sensible request.

 If the file size is known, and the transferred bytes is short (taking
 into account any restart point), then that could be considered a fetch
 failure.


   | Example:
   | 
   | Requesting https://.....
   |   4% |*                                  |  6779 KiB    9.78 KiB/s  4:30:23 ETA
   | 6941845 bytes retrieved in 11:32 (9.78 KiB/s)
   | 
   | and exit status is zero. As you can see from the transfer rate the connection
   | was ... challenged, and something timed out and droped the whole connection
   | midway. The client does not report this in any way that I can find, and
   | the announced size of the file is not easily available to the script
   | unless the whole application transfers a manifest first.
   | 
   | >Fix:
   | Add a command line option to force the exit status to indicate failure
   | if less than the original announced number of bytes have been received?

 I think that failing could be the default behaviour, instead of adding a
 new option.

 If you can (relatively) easily reproduce the issue, can you test if this
 patch does what you want?

 I've only fixed it for fetch_url(), because I /think/ that fetch_ftp
 should already detect the error.


 diff --git i/usr.bin/ftp/fetch.c w/usr.bin/ftp/fetch.c
 index a2ccd8c3897a..83c9ec15df08 100644
 --- i/usr.bin/ftp/fetch.c
 +++ w/usr.bin/ftp/fetch.c
 @@ -1856,6 +1856,11 @@ chunkerror:
  	}
  	if (bytes > 0)
  		ptransfer(0);
 +
 +		/* fail if short transfer when filesize is known */
 +	if (filesize >= 0 && (bytes + restart_point < filesize))
 +		goto cleanup_fetch_url;
 +
  	bytes = 0;

  	rval = 0;

Home	PR Database Search