This happens if you have some third-party repositories that are still using SHA-1 signatures. A similar error happens with RPM-using distros too. Ideally, the repo owners would fix their repos, but until they do, if you want to accept the risk of them using SHA-1, you can set your own policy about when you’ll accept SHA-1 until.

Both apt and rpm use a library that validates using Sequoia, a GnuPG compatible tool & library. It comes with a default policy to start rejecting SHA-1 as a hash from 2026-02-01, but it reads /etc/crypto-policies/back-ends/sequoia.config and accepts that.

So the solution is sudo mkdir -p /etc/crypto-policies/back-ends, and then sudo nano /etc/crypto-policies/back-ends/sequoia.config and pasting in:

[hash_algorithms]
sha1 = 2030-01-01 

That will give the repo owners until 2030 to fix the problem.

A note on security risk: SHA-1 in this case is used for revocation checks, and poses a very minor risk. If the repository’s key is compromised, and they revoke it, but before it was revoked the attacker was able to manipulate a request in the right way, they might be able to get a signature that the key is not revoked that is also valid for a certain other time, and then extend how long they can keep using the leaked key.

On the other hand, I’ve seen tutorials on the Internet on how to solve this problem that amount to telling apt to always pass the validation check (i.e. don’t actually validate) using APT::Key::GPGVCommand. For your own benefit, please don’t do this, as that just requires using a dodgy mirror to compromise your system.