Hi, 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 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. 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 with either of those options, and they would make APT more resiliant to failed time synchronisation. sqv accepts an explicit --not-after date instead of NOW. apt could specify one. 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 maybe do some hacks to sign our repositories a little in the past. Or intentionally delay publication by a few seconds. Stefano
Am Mon, Dec 22, 2025 at 05:31:04PM -0400, schrieb Stefano Rivera: 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. 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). 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
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
We'll get to it soon, I'm sure
Hi. I've attached a patch that should do what I would envision, but I'm not sure it matches what the APT maintainers (especially Julian) are planning, so I'm not adding the tag "patch", especially since I'm not super confident in my C++ skills :/ Cheers, Sven