Additional evidence for Debian bug #1143813: preserved apt-cacher-ng
cache header, filesystem timestamps, and upstream mirror information
This follows my October 13 report, which included
apt-cacher-ng-evidence-20261013.tar.xz with the failing and valid
trixie-updates InRelease files.
The issue affected both my Raspberry Pi 5 (Debian 13, arm64, running
apt-cacher-ng) and a Debian 13 amd64 desktop using it as a proxy. The
corrupted cached InRelease failed sqv verification on both clients.
Moving the cached InRelease and its .head file aside and allowing a
fresh retrieval resolved the issue.
I subsequently examined the original two files, preserved at:
/home/user/acng-bad-20261013-042256/InRelease
/home/user/acng-bad-20261013-042256/InRelease.head
The complete preserved InRelease.head contents were:
HTTP/1.1 200 OK
Content-Length: 47340
Last-Modified: Tue, 13 Oct 2026 08:13:05 GMT
X-Original-Source:
http://mirrors.xtom.com/debian/dists/trixie-updates/InRelease
The header records mirrors.xtom.com as the upstream source for this
cache entry. This does NOT establish that the mirror itself delivered
a bad file or caused the signature mismatch.
Relevant filesystem timestamps reported by stat (America/Boise,
UTC-06:00 on that date):
InRelease (47,340 bytes; owner apt-cacher-ng):
Birth: 2026-08-11 12:29:24.172711360 -0600
Modify: 2026-10-13 03:35:56.595302998 -0600
Change: 2026-10-13 04:23:11.462275208 -0600
InRelease.head (170 bytes; owner apt-cacher-ng):
Birth: 2026-06-26 22:37:53.206584491 -0600
Modify: 2026-10-13 04:16:33.042699234 -0600
Change: 2026-10-13 04:23:11.486275425 -0600
The 04:23 ctimes coincide with moving the files into the backup
directory. The old birth times reflect reused cache inodes, not
necessarily when these particular file contents were obtained.
Chronology (October 13, Boise local time):
- 02:13:05: Upstream Last-Modified timestamp (08:13:05 UTC). The
failed APT partial file also showed approximately 02:13 as mtime.
- 03:35:56: Cached InRelease last modified (09:35:56 UTC).
- Approximately 03:37: First observed signature verification error on the Pi.
- 04:16:33: Cached InRelease.head last modified (10:16:33 UTC), around
a failed desktop update.
- Approximately 04:23: I preserved both cached files by moving them aside.
Additional observation: I had taken the Pi to my mother's house on
another Internet connection for several days and ran apt update there
without signature errors. The failures began after I returned home. I
cannot determine whether the bad file was acquired on that other
network or after returning; the timestamps are suggestive of activity
at home but do not prove the download time or cause. In particular,
HTTP Last-Modified is not a client retrieval timestamp.
Previous attachment SHA-256 values:
- bad.InRelease:
706c13b5902fb74271db07319a366e929c58e9e3523edaae9ff48bf2a57079f5
- good.InRelease:
7348aa608c589b8d6421e8311f69deba685235a87681abe1879981f846f9122d
The repository metadata was byte-for-byte identical; the PGP signature
blocks differed, and independent sqv verification rejected the bad
copy.
I have kept the original 170-byte InRelease.head file and can provide
it if helpful. I hope this new source and timestamp evidence assists
the investigation without presuming the mirror or either network was
at fault.
