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
Attachment:
signature.asc
Description: PGP signature