Re: install/59195: Hashes missing in gzimg directories in FTP tree

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR install/59195; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: install/59195: Hashes missing in gzimg directories in FTP tree
Date: Wed, 02 Apr 2025 22:16:17 -0400

 I've noticed a couple of issues with this. First, if there's more than
 one file to generate a checksum for, the final one is basically missing
 in the output. That is, all but two characters of the line are lost.
 E.g., from
 https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202504020520Z/evbarm-aarch64=
 /binary/gzimg/SHA512
 where there are the files arm64.img.gz and arm64mbr.img.gz we have:
 
 SHA512 (arm64.img) =3D
 5b1a2ce7ce6a5401f8fc2563953d12351143e24a3f7706f09bb1ef084b2ec50338f1f455
 bbf43dea7c069de92960e7e4d86e1dbb8a8fcad2e67230ac1127fe97
 f3
 
 (The "f3" is the last two characters of the SHA512 checksum for
 arm64mbr.img.)
 
 Since the latter file is missing, if one runs cksum on MD5 or SHA512,
 it isn't actually checked at all. (Leading to a false sense of success,
 potentially, if one doesn't use -w with cksum.)
 
 Separately, the current output kind of violates the POLA, since the
 files themselves are gzipped, but the checksums are generated on the
 raw images. This is confusing, since it's not the practice used for
 similar checksum files provided by TNF, which are calculated against
 the gzipped content.
 
 Dave