« invalid or corrupted package (PGP signature) »

Chaque paquet que fournit Ditana est signé, et pacman refuse d’installer un paquet dont il ne peut pas vérifier la signature. C’est le mécanisme qui fait son travail. Mais cela signifie aussi qu’un trousseau obsolète vous empêche d’accéder aux mises à jour mêmes qui le répareraient.

Vous verrez l’un de ces messages, selon que la clé de signature est absente de votre trousseau, ou présente mais pas reconnue comme de confiance :

error: ditana-mirrorlist: key "3EC223A811077C09" is unknown
:: Import PGP key 3EC223A811077C09? [Y/n]
error: 'ditana-mirrorlist-1.12-1-any.pkg.tar.zst': invalid or corrupted package (PGP signature)

error: ditana-mirrorlist: signature from "Stefan Zipproth <[email protected]>" is unknown trust
error: failed to commit transaction (invalid or corrupted package (PGP signature))

La réparation

Pour un paquet Ditana :

sudo pacman -Sy ditana-keyring

Pour un paquet Arch (même problème, même forme – celui-ci est fréquent sur les systèmes restés hors ligne pendant des mois) :

sudo pacman -Sy archlinux-keyring

C’est l’exception à la règle « ne jamais faire -Sy sur un seul paquet » de La mise à jour n’est pas facultative, et il vaut la peine de comprendre pourquoi elle est sûre plutôt que de la traiter comme une incantation magique. La transaction ne contient qu’un seul paquet, il n’y a donc pas de mise à jour partielle d’un graphe de dépendances. Ce paquet est petit et ne contient aucun exécutable. Et sa signature peut être vérifiée avec une clé que votre installation possède déjà, si bien qu’aucune confiance n’est accordée à ce qui n’en bénéficiait pas auparavant – son installation exécute pacman-key --populate, qui ajoute l’ensemble actuel des clés Ditana à votre trousseau. Ensuite, effectuez comme d’habitude une mise à jour complète.

Si vous préférez le faire à la main, voici exactement ce qu’exécute le script d’installation du paquet :

sudo pacman-key --populate ditana

Vérifier soi-même les clés

Les paquets Ditana sont signés par cette clé :

pub   rsa4096  3F80 54C3 FF75 5E55 44E6  8516 BC33 3E9A E877 D45A
uid   Stefan Zipproth <[email protected]>
uid   Stefan Zipproth <[email protected]>

Elle comporte une sous-clé de signature dédiée, et c’est cette sous-clé qui signe la base de données du dépôt et chaque paquet compilé depuis août 2026 :

sub   rsa4096  068E EA2A 490B 0C63 AEAA  3BCD 3EC2 23A8 1107 7C09

L’empreinte par rapport à laquelle vous vérifiez reste celle indiquée ci-dessus : une sous-clé peut être remplacée sans que l’empreinte change. Un trousseau antérieur à ditana-keyring 20260809 ne connaît pas du tout la sous-clé, et c’est précisément la situation que résout la réparation décrite plus haut.

Vérifiez ce à quoi votre propre système fait confiance avec :

pacman-key --list-sigs ditana
gpg --show-keys --with-subkey-fingerprint /usr/share/pacman/keyrings/ditana.gpg

Nous ne proposons délibérément pas ici de script de réparation à télécharger et à exécuter. Votre situation est « ma vérification de signature échoue » ; y répondre par « téléchargez ceci et exécutez-le en tant que root » est formellement la même opération que celle que les signatures ont pour raison d’être d’empêcher, et le script ne pourrait pas non plus être signé de manière utile – c’est la vérification de signature qui est défaillante. Une commande que vous pouvez lire vaut mieux qu’une boîte noire.

Autres causes du même message

• L’horloge est fausse. Une signature n’est pas valide avant d’avoir été créée. Si l’horloge système est loin dans le passé – pile CMOS épuisée, machine virtuelle fraîchement créée, double démarrage avec Windows qui écrit l’heure locale dans l’horloge temps réel (RTC) – chaque signature semble provenir du futur. Vérifiez avec timedatectl et activez NTP avec sudo timedatectl set-ntp true.
• Un miroir a fourni un fichier tronqué. Dans ce cas, le message mentionne une somme de contrôle plutôt qu’une signature PGP. sudo pacman -Scc vide le cache de téléchargement, et la prochaine mise à jour télécharge à nouveau le fichier.