Bug#1123853: Allow repositories to be signed slightly in the future? Signature was created after the --not-after date.

David Kalnischkies <[email protected]> Tue, 23 Dec 2025 14:34:07 +0100

Newsgroups	gmane.linux.debian.apt.devel
Message-ID	<aUqOk8ZkBUqRyvCC__26470.912066155$1766498010$gmane$org@crossbow>

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…


We have a testcase (`test/integration/test-releasefile-date`) that
exercises the future, but only in terms of the Date inside the Release
file – as that is what we care about, not the date of the signature as
that is hard to extract.

APTs message would look like this:
| E: Release file for file:/tmp/tmp.e6wkVW450M/aptarchive/dists/wheezy/InRelease is not valid yet (invalid for another 23h 59min 55s). Updates for this repository will not be applied.

I suppose we could feed our max-future value to sqv as well to avoid
this kind of problem or at least have a supported way of working around
it.


> How about having APT accept repositories that are signed *slightly* in 
> the future. 30 seconds say? 5 minutes? I don't see any security risk 

According to our documentation the default value is currently 10 sec.
Not sure why Julian choose that specific value, but I suppose it could
be changed… then again, with too much time drift you run into all sorts
of problems (like https certificate validness).


> For Debusine's case, we obviously can't wait for APT to fix this in all 
> historical releases. So we'll have to do improve our NTP setup, and 

The releases that use gpgv are not affected, I assume, which should
reduce the scope to trixie and newer. I also note that we have used
`--ignore-time-conflict` for gpgv since basically ever further
reinforcing that this is a trixie and up issue only.

Sadly, the implementation of the sqv method neither allows configuring
additional options nor to override the used sqv binary, so my 'easy'
suggestions for a workaround are out the window.

It doesn't look like you could configure this via sqv crypto policy:
https://book.sequoia-pgp.org/configuration.html

So, yeah, maybe sign your files "in the past". If you run into the APT
message than you can configure that client-side easily if you have to.


Best regards

David Kalnischkies

signature.asc (application/pgp-signature, 833 B)