Note that I'm confused myself between my wip packages and real, and the
distfiles
I create for wip.
I got a checksum mismatch for 2.8.4, and on downloading I see a mod date
-rw-r--r-- 1 gdt users 6522704 Sep 10 14:17
/links/distfiles/nut-2.8.4.tar.gz
but the tag v2.8.4 is from August 8:
commit 541c2ecf0b2ec33dadb9f40b16acbe39042bd103 (HEAD, tag: v2.8.4-rc4, tag:
v2.8.4)
Author: Jim Klimov <jimklimov+nut at gmail.com>
Date: Fri Aug 8 12:48:39 2025 +0200
configure.ac: for now do not require (pre-)release tagged commits to build
changelog by default - keep doing it on systems where we can though
Signed-off-by: Jim Klimov <jimklimov+nut at gmail.com>
I had an older distfile, but it is missing commits that are in the tag,
so I think it was somehow from my wip tarballs.
So my questions are:
Was the 2.8.4 tag ever moved, or has it (while it existed) always
pointed to 541c2ecf0b2ec33dadb9f40b16acbe39042bd103?
Was a 2.8.4 distfile created on August 8?
are the current bits:
$ digest sha1 /links/distfiles/nut-2.8.4.tar.gz
SHA1 (/links/distfiles/nut-2.8.4.tar.gz) =
a75056bf2ed4b4144fe14e40cea0dbd7e5a2582a
$ ls -l /links/distfiles/nut-2.8.4.tar.gz
-rw-r--r-- 1 gdt users 6522704 Sep 10 14:17
/links/distfiles/nut-2.8.4.tar.gz
the same bits as were downloadable on August 8?
Why is the mod date September 10?
(And opinion, not clearly relevant to this situation at the moment, but
relevant to many situations surprisingly often:
Once a version tag is created, it must never be moved.
Once a distfile is posted, it must never be changed, for any reason,
no matter how much anyone thinks is a good idea.
The same distfile name having different contents appears to be a
supply chain attack.
If there's a problem with a distfile, then only approach to fix that
is to release a new distfile with a higher version. Integers are
cheap and we don't run out of them.
)
Thanks,
Greg
Greg Troxel
2025-Sep-16 12:37 UTC
[Nut-upsdev] was the 2.8.4 distfile re-rolled? (no, it's fine!)
Following up after more digging:
pkgsrc is configured to use the nut website as the distfile location:
https://networkupstools.org/source/2.8/nut-2.8.4.tar.gz
There is also github:
https://github.com/networkupstools/nut/releases/download/v2.8.4/nut-2.8.4.tar.gz
These files are byte-for-byte identical, but have different mod dates:
$ ls -l NUT-*/*
-rw-r--r-- 1 gdt wheel 6522704 Aug 8 08:31 NUT-git/nut-2.8.4.tar.gz
-rw-r--r-- 1 gdt wheel 6522704 Sep 10 14:17 NUT-org/nut-2.8.4.tar.gz
$ cmp NUT-*/*
$
So other than the nicety of the mod time matching, all is ok.
Following up again, after looking even harder. ftp.netbsd.org caches distfiles for packages, so people can fetch them if upstream goes away, and to meet GPL source obligations (a formality in the nut case). In the cache was: -rw-rw-r-- 1 gdt wheel 6522262 Aug 14 08:09 nut-2.8.4.tar.gz SHA1 (ftp.netbsd.org/nut-2.8.4.tar.gz) = aed1db6ffcdbbc42259a0fcb5ababfd45b5d2c7a SHA512 (ftp.netbsd.org/nut-2.8.4.tar.gz) = 0d87c0006608f92ae54f8a500f93d9a81eac1d9abf57f32e7718dd72f265b8293a0b6cdba04c802b81eaf8907b52669c36b47b6875a4377f9752845ac6c5e8fa and fetched on my machine after removal -rw-r--r-- 1 gdt users 6522704 Sep 10 14:17 gdtlocal/nut-2.8.4.tar.gz SHA1 (gdtlocal/nut-2.8.4.tar.gz) = a75056bf2ed4b4144fe14e40cea0dbd7e5a2582a SHA512 (gdtlocal/nut-2.8.4.tar.gz) = ddaca1d0cba17817fd27d036442395d11d64541b0782cd3c33d7b93712a15587dbad54fd7ed8a3ff14b89d75211560f76c30f5b9559e963adb4df7b05b66ec26 Diffing them, they were both produced on a machine with autoconf 1.16.5 (vs one produced for pkgsrc-wip testing on my machine which is 1.18). The file "scripts/Windows/Makefile" encodes paths to the dir used to generate the tarball via "missing" scripts so I can tell from a distfile whether it was produced by 'jim' or 'gdt' :-) Between the two signs, I am confident that neither of the above was produced by me. This basically rules out "gdt/netbsd got confused by a distfile generated for wip by gdt". Diffing the cached tarball and a tarball fetched recently, I see --- ftp.netbsd.org/nut-2.8.4/ChangeLog 2025-08-08 04:42:34.000000000 -0400 +++ gdtlocal/nut-2.8.4/ChangeLog 2025-08-08 07:06:22.000000000 -0400 @@ -1,7 +1,27 @@ -NOTE: This change log section represents git commits in range 'v2.6.0..HEAD' (commits '8103b4e5c..434cb36a3'). +NOTE: This change log section represents git commits in range 'v2.6.0..HEAD' (commits '8103b4e5c..541c2ecf0'). 434cb36a3 is v2.8.4rc1 541c2ecf0 is v2.8.4rc4 So I wonder, was the rc1 tarball present -- with the name nut-2.8.4.tar.gz -- on the download server? On the NetBSD ftp server, the rc1-flavored copy of nut-2.8.4.tar.gz has mod time Aug 14 12:09 nut-2.8.4.tar.gz ctime Aug 17 12:16 nut-2.8.4.tar.gz so August 17 is when it would have been fetched. I just committed to pkgsrc a change to the checksums, thinking it was my confusion about the old one: -BLAKE2s (nut-2.8.4.tar.gz) = ece7b19f55771472f113a712d047ff324199d28ea0f2f5cfa13a781ff8947e78 -SHA512 (nut-2.8.4.tar.gz) = 0d87c0006608f92ae54f8a500f93d9a81eac1d9abf57f32e7718dd72f265b8293a0b6cdba04c802b81eaf8907b52669c36b47b6875a4377f9752845ac6c5e8fa -Size (nut-2.8.4.tar.gz) = 6522262 bytes +BLAKE2s (nut-2.8.4.tar.gz) = 2225617ef46a46cc0b6e08b93877ad0391b44a349efa2c8ea82fb3ef5ca8f7d2 +SHA512 (nut-2.8.4.tar.gz) = ddaca1d0cba17817fd27d036442395d11d64541b0782cd3c33d7b93712a15587dbad54fd7ed8a3ff14b89d75211560f76c30f5b9559e963adb4df7b05b66ec26 +Size (nut-2.8.4.tar.gz) = 6522704 bytes and the SHA512s in that diff match the cached distfile fetched on August 17, and the one I re-fetched on Sep 16 11:39. If the rc1 distfile was present under the name nut-2.8.4.tar.gz, and was replaced, it would be good to understand, since otherwise there is perhaps some mysterious bug in the fetching/etc. infrastructure. Could people with downloaded nut-2.8.4.tar.gz files check the SHA1/512 values and see which one they have? Was there some plan to have rc tarballs on the ftp server but under the name nut-2.8.4.tar.gz? I am guessing no, but I am having trouble guessing what happened.