On Tue, 23 Dec 2025 14:34:07 +0100 David Kalnischkies <[email protected]> wrote: > Am Mon, Dec 22, 2025 at 05:31:04PM -0400, schrieb Stefano Rivera: > > In Debusine we have achieved pretty fast APT repository publishing to > > the point that we're seeing races between signing the repository and > > workers consuming the new InRelease data. [0] > > > > [0]: https://salsa.debian.org/freexian-team/debusine/-/issues/1230 > > > > > Err:3 http://deb.debusine.debian.net/debian/r-stefanor-dh-python > > > sid-dh-python InRelease > > > Sub-process /usr/bin/sqv returned an error code (1), error message is: > > > Signature by D966DAFFBD4394D369CFB892DE78184209E0E98A was created after > > > the --not-after date. > > > > Obviously some NTP action can help out there, but time synchronization > > is one of those things that's hard to get perfect in distributed > > systems. > > mmmh. APT does not use the --not-after option of sqv, but the man page > tells me it has `now` as default. Maybe you want to talk to them to > use a different default…
I don't think the default in sqv is wrong (for manual invocations) but for servers that re-sign the Release file frequently and apt fetches that run as frequently, small deviations in time matter a lot more. Despite having every machine set up to use ntp (well, timesync), we frequently run into the above issue. Note that gpgv (in apt 2.9 and 3.1.13 if you would use it) gets `--ignore-time-conflict` passed in which completely disables the time check (not just the check for the signature being newer than the key), if I understand correctly. IMHO, it would make sense for apt to pass a value to the --not-after option of sqv that is derived from the `Acquire::Max-FutureTime` configuration. If we ask APT to allow Release files (aka Metaindex files) to come from the future (and the default for the option is 10 seconds already), it doesn't make sense to restrict the signature from being in the future at all. Kind regards, Sven
