Bug#1123853: Allow repositories to be signed *slightly* in the future? Signature was created after the --not-after date.
On Thu, Jan 08, 2026 at 05:27:28PM +0100, Sven Mueller wrote:
> On Tue, 23 Dec 2025 14:34:07 +0100 David Kalnischkies
> <david@kalnischkies.de> 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.
We'll get to it soon, I'm sure
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: