Salut Doug,
Salut Julien,
:~$ pgpverify -test < /var/spool/news/articles/control/newgroup/5>
[GNUPG:] NEWSIG control@tetalab.org
gpg: Signature faite le mar. 23 déc. 2025 07:01:45 +11
gpg: avec la clef RSA 8E8203A119D89A30E31600954C9469A22D1F3CA0
gpg: issuer "control@tetalab.org"
[GNUPG:] KEY_CONSIDERED 8E8203A119D89A30E31600954C9469A22D1F3CA0 0
[GNUPG:] KEY_CONSIDERED 8E8203A119D89A30E31600954C9469A22D1F3CA0 0
[GNUPG:] BADSIG 4C9469A22D1F3CA0 control-tetalab <control@tetalab.org>
gpg: MAUVAISE signature de << control-tetalab <control@tetalab.org> >> [inconnu]
C'est étonnant.
La vérification directe du fichier généré par signcontrol (en .sig)
échoue-t-elle aussi ?
Oui et à la lecture de la sortie de strace, le coupable serait l'absence
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 qui
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
Ça pourrait également expliquer pourquoi gpg identifie bien la clef utilisée
pour signer le message et identifie également la clef à utiliser pour
vérifier la signature
[GNUPG:] NEWSIG control@tetalab.org
gpg: Signature faite le mer. 24 déc. 2025 12:44:10 +11
gpg: avec la clef RSA C3153AE6A2CE3C5EE764FD3114B0F5890578DE5D
gpg: issuer "control@tetalab.org"
[GNUPG:] KEY_CONSIDERED C3153AE6A2CE3C5EE764FD3114B0F5890578DE5D 0
[GNUPG:] KEY_CONSIDERED C3153AE6A2CE3C5EE764FD3114B0F5890578DE5D 0
[GNUPG:] BADSIG 14B0F5890578DE5D control-tetalab <control@tetalab.org>
gpg: MAUVAISE signature de << control-tetalab <control@tetalab.org> >> [inconnu]
J'ai l'impression que c'est finalement pgpverify qui se prend les pied
dans le tapis.
J'ai testé:
- tous les combinaisons algo/fonctionnalité (signature/signateure plus chiffrement)
lors de la génération de la clef
- exporter la clef avec ou sans --armor
- importer la clef à partir d'un fichier copié directement avec ssh ou
un un copié/coller dans vi
Le résultat est toujours le même.
Si le problème ne vient pas d'une erreur dans l'identification du
keyring alors le problème vient du signcontrol.py mais je n'y crois pas
trop puisque la signature est clairement et correctement identifiée par
son emprunte.
--
Doug
Envoyé depuis mon Jacob Delafon 3000 Turbo
Les messages affichés proviennent d'usenet.