Signing key on 6125E2A8C77F2818FB7BD15B93C4A3FD7BB9C367 is not bound: No binding signature at time Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure
Feb 1st 2026 is when SHA1 is considered insecure. Hitting this issue when trying to install Ansible on Debian 13. The installation guide is now out of date.
This blog post explains a work around that you could use prior to the GPG key(s) being updated:
CC @deric.crago
Thanks for flagging this. I am looking into it and hope to resolve it before Monday.
Hi!
Has the key already been rotated?
Thank you!
Chris
Hey 
@deric.crago any success fixing the issue? The error has been there for more than 2 weeks and still isn’t fixed. Atm it’s not possible to install Ansible via apt on Debian 13 following the official documentation 
Same problem here.
OpenPGP signing keys for Launchpad PPAs are managed entirely by Launchpad and as owners, we cannot override them. Since this PPA is designed for Ubuntu, Debian’s stricter sqv verification is rejecting signatures that work fine on Ubuntu.
To resolve this compatibility issue on Debian, the only workaround I’m aware of is adding trusted=yes. I’ve opened a PR to update the documentation with this fix. Reviews and testing are welcome.
Rather than adding trusted=yes wouldn’t it be better to follow the suggestion here?
I think you’d be better off looking at the unfortunately lightly-documented /usr/share/apt/default-sequoia.config. You can copy that file to /etc/crypto-policies/back-ends/apt-sequoia.config as it suggests, and then tweak the dates as needed.
The /usr/share/apt/default-sequoia.config file contains:
# Default APT Sequoia configuration. To overwrite, consider copying this
# to /etc/crypto-policies/back-ends/apt-sequoia.config and modify the
# desired values.
[asymmetric_algorithms]
dsa2048 = 2024-02-01
dsa3072 = 2024-02-01
dsa4096 = 2024-02-01
brainpoolp256 = 2028-02-01
brainpoolp384 = 2028-02-01
brainpoolp512 = 2028-02-01
rsa2048 = 2030-02-01
[hash_algorithms]
sha1.second_preimage_resistance = 2026-02-01 # Extend the expiry for legacy repositories
sha224 = 2026-02-01
[packets]
signature.v3 = 2026-02-01 # Extend the expiry
Also shouldn’t we be suggesting that people use deb822 .sources files rather than .list files?
Thanks for the ongoing discussion, everyone.
While I don’t really like suggesting trusted=yes in the installation guide, that seems like a better suggestion to me than having people modify their global system configuration just for this one PPA. Changing the system config weakens security checks for every repository on the machine, whereas trusted=yes keeps the exception isolated to just this PPA. I’m open to other thoughts on this and perhaps we should make a note in the docs about how we came to whatever conclusion we decide.
Also, as a quick update on the installation instructions themselves, I am going to update my PR to use the deb822 .sources format instead of traditional .list files. I originally held off on doing this because I tried using embedded keys, which failed on older versions of Debian like Bullseye. It didn’t occur to me at the time to just use an external key reference as before.
Just making a note and checking for an update to this. Ran into the issue this morning