Simon McVittie writes ("Bug#1126793: dgit: autopkgtest regression: SHA1 is not
considered secure since 2026-02-01T00:00:00Z"):
> 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:
Thanks for the report.
You're right, and it does seem we need to regenerate our test keys.
I think time-based checks like this are quite a bad thing. We
normally do this kind of deprecation by new software versions. I'm
not sure what ought to be done now about apt, but this behaviour -
starting to break simply because the date has changed - is really
unhelpful. Do you agree?
> 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.
We might do this because we want the same code to work as far back as
we can. (But I guess even quite old gnupg in Debian supports SHA256
here.)
> 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.
Thanks for the tips.
Chris Hofstaedtler writes ("Bug#1126793: dgit: autopkgtest regression: SHA1 is
not considered secure since 2026-02-01T00:00:00Z"):
> If the keys are not actually relevant to the test (they probably
> can't be secure) maybe it'd be better if the test generates new
> keys, or just used `Trusted: yes` in the APT sources.
>
> Testing APT's signature verification doesn't seem particularly
> useful in src:dgit?
Thanks for the suggestion. However:
src:dgit's tests do include cases where signatures are important. It
might be possible to override the signatures on just the in-test
*apt repositories* but I would be concerned that that might disable
something else that we are actually trying to test, or change the
behaviour in some other way, reducing the faithfulness of the tests.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
