On 2023/06/25 18:22:31 -0700, a dog <open...@anthropomorphic.dog> wrote:
> >Synopsis: ftp(1) will never attempt to set the modification date of any
> >file retrieved by http[s]
> >Category: user
> >Environment:
> System : OpenBSD 7.3
> Details : OpenBSD 7.3-current (GENERIC.MP) #1259: Fri Jun 23
> 09:13:33 MDT 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> ftp(1) will always act as if the Last-Modified header returned
> by the server is invalid, and set server_timestamps to 0 on line
> 989 of usr.bin/ftp/fetch.c. This is because the space following
> the colon is not stripped, and therefore strptime(3) will see
> something resembling " Sun, 25 Jun 2023 21:38:42 GMT" -
> otherwise valid but beginning with a space. The end result is
> that file modification stamps will never be set, as if -u had
> been specified.
> >How-To-Repeat:
> 1) Pick any URL that returns a Last-Modified which is valid and
> not equal to the time of retrieval,
> 2) Now retrieve the same URL using ftp(1). The modification
> date is supposed to be set to the value returned by the
> server, but will instead be equal to the time the file was
> closed by ftp(1).
> >Fix:
> Thankfully simple. Please see proposed patch below.
Good catch. It's the only header where we forget to skip leading
blanks.
I can reproduce and confirm that this does indeed fix the parsing and
make ftp set the mtime accordingly to Last-Modified.
> diff --git i/usr.bin/ftp/fetch.c w/usr.bin/ftp/fetch.c
> index 0ba7ad4d099..b6d6f4d775a 100644
> --- i/usr.bin/ftp/fetch.c
> +++ w/usr.bin/ftp/fetch.c
> @@ -984,6 +984,7 @@ noslash:
> } else if (strncasecmp(cp, LAST_MODIFIED,
> sizeof(LAST_MODIFIED) - 1) == 0) {
> cp += sizeof(LAST_MODIFIED) - 1;
> + cp += strspn(cp, " \t");
> cp[strcspn(cp, "\t")] = '\0';
> if (strptime(cp, "%a, %d %h %Y %T %Z", &lmt) == NULL)
> server_timestamps = 0;
