Maybe if I translate what wasn’t yet fully in English would help?
Err: 9 http://maven.xwiki.org stable/ Release.gpg
Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on E5A298A7AF53948CC6CFD633F716794B93CC9C13 is not bound: No binding signature at time 2026-03-23T23:28:31Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
1,798 B received in 0s (8,199 B/s)
All packages are up to date.
Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://maven.xwiki.org stable/ Release: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on E5A298A7AF53948CC6CFD633F716794B93CC9C13 is not bound: No binding signature at time 2026-03-23T23:28:31Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Warning: Unable to fetch http://maven.xwiki.org/stable/Release.gpg Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on E5A298A7AF53948CC6CFD633F716794B93CC9C13 is not bound: No binding signature at time 2026-03-23T23:28:31Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
SHA1 is not considered secure since 2026-02-01T00:00:00Z Looking forward to know if a fix is planned? (Running the server in Debian Trixie, btw).
I did some further investigation. The Release.gpg signature itself uses SHA512 (digest algo 10), so it isn’t the issue. The problem seems to be with the certification binding of the public key, E5A298A7AF53948CC6CFD633F716794B93CC9C13, which uses SHA1 : it is what Sequoia/sqv rejects (since 2026-02-01). It seems the fix would require re-certifying the key with a stronger algorithm.
Additional investigation on public.gpg confirms the issue: the key carries two
self-certifications. The original one (2020-11-04) uses digest algo 2 (SHA1),
which Sequoia rejects. A newer certification (2025-09-09) uses digest algo 8
(SHA256), but the old SHA1 one is still present. The fix would be to remove
the old SHA1 self-certification from the published key.
As I am not much of a developer, I have asked the answer to that question to one of my favorite AI’s and this is what came out of my discussion with her:
Redhat met with the exact same issue: to get rid of the SHA1 auto-signature,
recreating these signatures is the way. The simplest method with GnuPG is to
modify the key expiration date, which forces GnuPG to create new auto-signatures.
Be careful though: these new signatures should be back-dated to avoid Sequoia
rejecting older package signatures.
Alternatively, Sequoia provides a built-in tool that may handle this more cleanly:
sq cert lint --fix
References:
- https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel
- https://book.sequoia-pgp.org/lint.html
This answer seems reasonable enough to me so I provide it as is. And for the second link, the page starts with this title Upgrading a certification signature from SHA1 to SHA256 which also seems appropriate to me.
I hope it will be the way!
I’ll keep following, as when you will have solved it, I’ll still have to figure if a simple “apt upgrade” will do the trick in the server.
$ sq cert lint --cert E5A298A7AF53948CC6CFD633F716794B93CC9C13
Examined 1 certificate.
0 certificates are invalid and were not linted. (GOOD)
1 certificate was linted.
0 of the 1 certificates (0%) have at least one issue. (GOOD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User ID:
0 have at least one User ID protected by SHA-1. (GOOD)
0 have all User IDs protected by SHA-1. (GOOD)
1 of the non-revoked linted certificates has at least one non-revoked, live subkey:
0 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (GOOD)
0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
The issue was actually with the local xwiki-keyring.gpg file on my server,
which had been downloaded before the September 2025 key update and still
contained the old SHA1 certifications (digest algo 2) only.
After that, gpg --list-packets (gpg --list-packets /usr/share/keyrings/xwiki-keyring.gpg | grep "digest algo") only shows digest algo 8 and 10 : no more SHA1! apt update is now clean.
@tmortagne
For the record, maven.xwiki.org/public.gpg online still contains the old SHA1
certification (digest algo 2, created 2020-11-04) alongside the newer SHA256 one
(digest algo 8, created 2025-09-09). However, maven.xwiki.org/xwiki-keyring.gpg
only contains the clean ones (algo 8 and 10), which is why re-downloading it fixes
the issue. The old SHA1 certification could still be removed from public.gpg for
completeness, I guess?
public.gpg and xwiki-keyring.gpg are indeed not equals while having the same fingerprint. But sq does not really complain about public.gpg either. Anyway, I replaced it with a link targeting xwiki-keyring.gpg as there was no point maintaining 2 variations of the same key file.
