Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1280412 > unrolled thread

Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z Simon McVittie <smcv@debian.org> - 2026-02-01 16:10 +0100
    Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z Chris Hofstaedtler <zeha@debian.org> - 2026-02-01 16:20 +0100
    Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2026-02-01 17:50 +0100
      Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2026-02-01 17:50 +0100
        Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2026-02-02 20:30 +0100

#1280412 — Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z

Source: dgit
Version: 14.5
Severity: important
User: debian-ci@lists.debian.org
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

[toc] | [next] | [standalone]

#1280414

On Sun, Feb 01, 2026 at 02:55:31PM +0000, Simon McVittie wrote:
> 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.

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?

Chris

[toc] | [prev] | [next] | [standalone]

#1280428 — Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages]

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 <ijackson@chiark.greenend.org.uk>   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.

[toc] | [prev] | [next] | [standalone]

#1280430 — Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages]

Ian Jackson writes ("Re: Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages]"):
> Simon McVittie writes ("Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z"):
> > 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.)

In fact I am going to do this *right now* because this terrible
decision to have a time-based deprecation is suddenly blocking my
work.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   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.

[toc] | [prev] | [next] | [standalone]

#1280547 — Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages]

Ian Jackson writes ("Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z [and 1 more messages]"):
...
> > Simon McVittie writes ("Bug#1126793: dgit: autopkgtest regression: SHA1 is not considered secure since 2026-02-01T00:00:00Z"):
> > > 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.
...
> In fact I am going to do this *right now* because this terrible
> decision to have a time-based deprecation is suddenly blocking my
> work.

It turns out that the policy override mechanism is broken.

Attempting to use it like this

  +cat <<'END' >>$tmp/.sequoia-crypto-policy
  +[hash_algorithms]
  +sha1 = "always"
  +END
  +export SEQUOIA_CRYPTO_POLICY=$tmp/.sequoia-crypto-policy

results in this

  W: OpenPGP signature verification failed: 
  file:/tmp/autopkgtest.XEAQrW/autopkgtest_tmp/mirror unstable 
  InRelease: Sub-process /usr/bin/sqv returned an error code (1), 
  error message is: Error: Parsing 
  "/tmp/autopkgtest.XEAQrW/autopkgtest_tmp/.sequoia-crypto-policy" 
  Caused by:     redefinition of table `hash_algorithms` for key 
  `hash_algorithms` at line 3 column 1

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web