Hi, After the last problem, I set up a cronjob to save all the InRelease files that apt- cacher-ng has at midnight, 4am and 9am UK time (UTC+1), which appears to cover the time that Debian mirrors update, and also the time that my local machines' unattended-upgrade scripts run.
Looking at just trixie-backports, I now have plenty of instances where the only change to the InRelease file is the Date: and Valid-Until: headers: -Date: Tue, 11 Aug 2026 14:07:09 UTC -Valid-Until: Tue, 18 Aug 2026 14:07:09 UTC +Date: Wed, 12 Aug 2026 02:27:32 UTC +Valid-Until: Wed, 19 Aug 2026 02:27:32 UTC -Date: Wed, 12 Aug 2026 14:09:08 UTC -Valid-Until: Wed, 19 Aug 2026 14:09:08 UTC +Date: Thu, 13 Aug 2026 02:07:29 UTC +Valid-Until: Thu, 20 Aug 2026 02:07:29 UTC -Date: Thu, 13 Aug 2026 20:08:31 UTC -Valid-Until: Thu, 20 Aug 2026 20:08:31 UTC +Date: Fri, 14 Aug 2026 02:08:37 UTC +Valid-Until: Fri, 21 Aug 2026 02:08:37 UTC -Date: Fri, 14 Aug 2026 14:12:42 UTC -Valid-Until: Fri, 21 Aug 2026 14:12:42 UTC +Date: Sat, 15 Aug 2026 02:09:14 UTC +Valid-Until: Sat, 22 Aug 2026 02:09:14 UTC -Date: Tue, 18 Aug 2026 14:07:10 UTC -Valid-Until: Tue, 25 Aug 2026 14:07:10 UTC +Date: Wed, 19 Aug 2026 02:40:34 UTC +Valid-Until: Wed, 26 Aug 2026 02:40:34 UTC I also have plenty of examples where these fields are also updated along with the SHA256 hashes for various files, again without the PGP signature having been updated. I now have a script that runs sqv on each that I have, reporting based on the sqv exit code whether sqv was successful or not. The results are not good (20 fail, 11 pass): InRelease-20260811-09 - ok InRelease-20260812-00 - ok InRelease-20260812-04 - ok InRelease-20260812-09 - failed sqv verification InRelease-20260813-00 - ok InRelease-20260813-04 - ok InRelease-20260813-09 - failed sqv verification InRelease-20260814-00 - ok InRelease-20260814-04 - ok InRelease-20260814-09 - failed sqv verification InRelease-20260815-00 - failed sqv verification InRelease-20260815-04 - failed sqv verification InRelease-20260815-09 - failed sqv verification InRelease-20260816-00 - failed sqv verification InRelease-20260816-04 - failed sqv verification InRelease-20260816-09 - failed sqv verification InRelease-20260817-00 - failed sqv verification InRelease-20260817-04 - failed sqv verification InRelease-20260817-09 - failed sqv verification InRelease-20260818-00 - ok InRelease-20260818-04 - ok InRelease-20260818-09 - failed sqv verification InRelease-20260819-00 - failed sqv verification InRelease-20260819-04 - failed sqv verification InRelease-20260819-09 - failed sqv verification InRelease-20260820-00 - ok InRelease-20260820-04 - ok InRelease-20260820-09 - failed sqv verification InRelease-20260821-00 - failed sqv verification InRelease-20260821-04 - failed sqv verification InRelease-20260821-09 - failed sqv verification It seems these InRelease files fail SQV more often than they pass. Checking trixie and trixie-updates, SQV passes for all that I have. For trixie-security, it's a similar story to trixie-backports, although it's just over 50% of captured InRelease files fail (16 fail, 15 pass): InRelease-20260811-09 - ok InRelease-20260812-00 - ok InRelease-20260812-04 - ok InRelease-20260812-09 - ok InRelease-20260813-00 - failed sqv verification InRelease-20260813-04 - failed sqv verification InRelease-20260813-09 - ok InRelease-20260814-00 - failed sqv verification InRelease-20260814-04 - ok InRelease-20260814-09 - ok
