Oui et à la lecture de la sortie de strace, le coupable serait l'absenceLa documentation de pgpverify a besoin d'être mise à jour. Le fonctionnement de GnuPG a changé depuis le temps. Je viens d'envoyer un mail à Russ sur le sujet (car ce programme n'est pas maintenu dans INN).
de /var/spool/news/.gnupg/trustedkeys.gpg et /var/spool/news/.gnupg/pubring.gpg
newfstatat(AT_FDCWD, "/var/spool/news/.gnupg/trustedkeys.gpg", 0x55738e8094a8, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
newfstatat(AT_FDCWD, "/var/spool/news/.gnupg/pubring.gpg", 0x55738e8094a8, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
Corroboré par les commentaires dans pgpverify qui stipulent qu'au moins
l'un de ces fichiers est attendu:
INN, when using GnuPG, configures B<pgpverify> to use B<gpg> or B<gpgv>, which
by default expects keys to be in a keyring named F<trustedkeys.gpg>, since it
doesn't implement trust checking directly. B<pgpverify> uses that file if
present but falls back to F<pubring.gpg> if it's not found. This bypasses
the trust model for checking keys, but is compatible with the way that
B<pgpverify> used to behave.
Sauf que j'utilise gpg2 sur la machine qui signe et sur le serveur quiPareil pour moi : je n'ai ni trustedkeys.gpg ni pubring.gpg.
héberge INN. gpg2 dont le keyring ressemble plutôt à ça (coté serveur):
$ ls -ailh ~/.gnupg/
total 16K
402695225 drwx------ 3 news news 183 24 déc. 13:07 .
269735767 drwxrwxr-x 9 news news 4,0K 24 déc. 13:04 ..
128551 drwx------ 2 news news 6 22 déc. 20:37 private-keys-v1.d
404589869 -rw-rw-r-- 1 news news 1,5K 24 déc. 12:43 pubring.kbx
404589870 -rw------- 1 news news 655 24 déc. 12:39 pubring.kbx~
404590145 srwx------ 1 news news 0 22 déc. 20:37 S.gpg-agent
404590197 srwx------ 1 news news 0 22 déc. 20:37 S.gpg-agent.browser
404590147 srwx------ 1 news news 0 22 déc. 20:37 S.gpg-agent.extra
404605392 srwx------ 1 news news 0 22 déc. 20:37 S.gpg-agent.ssh
404589885 -rw------- 1 news news 1,2K 22 déc. 20:37 trustdb.gpg
Ces deux fichiers seront utilisés préférentiellement par pgpverify s'ils existent, mais dans le cas contraire, le trousseau par défaut de GnuPG est utilisé (en l'occurrence pubring.kbx).
% ls -l .gnupg
total 112K
drwx------ 2 news news 4,0K 17 avril 2022 crls.d/
-rw-r--r-- 1 news news 24 29 avril 2024 gpg-agent.conf
-rw-r--r-- 1 news news 33 29 avril 2024 gpg.conf
drwx------ 2 news news 4,0K 18 juil. 14:55 openpgp-revocs.d/
drwx------ 2 news news 4,0K 18 juil. 14:55 private-keys-v1.d/
-rw-r--r-- 1 news news 18K 18 juil. 14:55 pubring.kbx
-rw-r--r-- 1 news news 16K 17 juil. 20:17 pubring.kbx~
-rw------- 1 news news 600 24 déc. 15:20 random_seed
-rw-r--r-- 1 news news 48K 8 mars 2022 tofu.db
-rw------- 1 news news 1,5K 1 oct. 21:35 trustdb.gpg
J'ai l'impression que c'est finalement pgpverify qui se prend les piedsBizarre.
dans le tapis.
Serait-il possible d'avoir l'article de contrôle complet et la clef publique ?
Je peux faire le test sur mon serveur. (Et d'autres qui nous lisent aussi d'ailleurs s'ils le souhaitent.)
--
Julien ÉLIE
« Le meilleur moyen de faire tourner la tête à une femme, c'est de lui
dire qu'elle a un joli profil. » (Sacha Guitry)
Les messages affichés proviennent d'usenet.