Source: dgit
Version: 14.5
Severity: important
User: [email protected]
Usertags: regression
I noticed that the package tracker page for autopkgtest is reporting
autopkgtest regressions for src:dgit. Looking at the log (and the
architectures like i386 that report it as a non-regression), this seems
to be a time-based regression that will happen on any test run after
2026-02-01, rather than something broken by an autopkgtest change:
>331s + apt-get -c
>'/tmp/autopkgtest-lxc.l1llofk2/downtmp/autopkgtest_tmp/.cache/dgit/aptget/apt.conf#test-dummy'
> update
>331s Get:1 file:/tmp/autopkgtest-lxc.l1llofk2/downtmp/autopkgtest_tmp/mirror
>unstable InRelease [2073 B]
>331s Get:1 file:/tmp/autopkgtest-lxc.l1llofk2/downtmp/autopkgtest_tmp/mirror
>unstable InRelease [2073 B]
>331s Err:1 file:/tmp/autopkgtest-lxc.l1llofk2/downtmp/autopkgtest_tmp/mirror
>unstable InRelease
>331s Sub-process /usr/bin/sqv returned an error code (1), error message is:
>Signing key on 3B0F3FB8ADEFAEF81E0D0C5C14A868BFAC3BD039 is not bound:
> No binding signature at time 2026-02-01T05:20:16Z because: Policy rejected
>non-revocation signature (PositiveCertification) requiring second pre-image
>resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Perhaps the test keys in src/tests/tstunt/gpg, which seem to have been
generated in 2013/2014, need to be regenerated with a SHA256
self-signature or replaced with new keys so that apt will still consider
them to be sufficiently strong? Or perhaps the signing key is somewhere
else, I'm not familiar with this test suite.
See the apt (2.9.19) debian/NEWS entry for more details. It might be
possible to override this with a suitable value for
$APT_SEQUOIA_CRYPTO_POLICY, but regenerating the test keys (or at least
updating their self-signatures) is probably easier.
Based on my experiences with updating third-party apt repositories, the
easiest way to force a new self-signature seems to be to ask a
current-ish version of gpg to change the expiry date with --edit-key and
the "expire" command. I believe it's sufficient to set an infinitely
long expiry date (even if that matches the current expiry date) which
has the side-effect of issuing a new self-signature using the new
default signature algorithm, which should be SHA256 or possibly SHA512.
smcv
