bin/59587: ftp client bug

[bqt%softjar.se@localhost]

>Number:         59587
>Category:       bin
>Synopsis:       ftp client ascii transfers with progress report fail
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 11 12:30:00 +0000 2025
>Originator:     Johnny Billquist
>Release:        NetBSD 10.1
>Organization:
N/A
>Environment:
System: NetBSD GW.SoftJAR.SE 10.1 NetBSD 10.1 (GENERIC) #0: Wed Feb 5 23:06:02 CET 2025 root%GW.SoftJAR.SE@localhost:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
A couple of years ago, the ftp (client) was changed in how it handled
signals (version 1.171).

The problem is that the change made reads from the data channel
potentially cause EINTR or EAGAIN. The code was changed to properly
handle this in binary transfers, but it was not done for ascii
transfers. So if anyone tries to transfer a large enough ascii
file, with a progress bar, the transfer will fail after about 1s.

>How-To-Repeat:
ftp to some server, switch to ascii mode, make sure progress is enabled,
and try to fetch a file that is large enough that it will take more than
a couple of seconds to transfer the file, and observe the error aborting
the transfer.

>Fix:

Here is a patch to fix the problem:

Index: ftp.c
===================================================================
RCS file: /cvsroot/src/usr.bin/ftp/ftp.c,v
retrieving revision 1.174.2.3
diff -r1.174.2.3 ftp.c
1125c1125,1136
< 		while ((c = getc(din)) != EOF) {
---
> 		while (1) {
> 			c = getc(din);
> 			if (c == EOF) {
> 				if (feof(din)) {
> 					goto break2;
> 				}
> 				if ((errno == EINTR) || (errno == EAGAIN)) {
> 					clearerr(din);
> 					goto contin2;
> 				}
> 				goto break2;
> 			}