[Demande de certification] cgeek-test-revocation

Networks Ğ1-Test
6

Mon identité à révoquer est passée cet après-midi. Voici les résultats :

Générer le document de révocation

J’ai pu générer mon document aussi bien depuis Cesium que Sakia, quoi que pour ce dernier cela n’a fonctionné que sous Windows. En tout cas, le contenu du document généré par les 2 logiciels est strictement identique :

Version: 10
Type: Revocation
Currency: g1-test
Issuer: 4Ec3yqwfCxJM2pB3jCGrbUSvxqDGxasQcBCxCyA81Nwh
IdtyUniqueID: cgeek-test-revocation
IdtyTimestamp: 7372-00008776316C84C2C3981F856F0567A930FD3FDFFB2A4231E0ABCD92F177352E
IdtySignature: dPuqMqjJAszmujv6WQnXnIPIwgb/w2bXk+o/2JYAxElFwxv1j0If5bWp+skyzUESQSVOh++gg3pmGATIG2NeAw==
EVlHVyCn73o2GCAQPp3ADXufaeo0ND8wOyJp8Cr4xyHQEyqVXqaSgUwfPjerGiEFamtohkcqjTjtN8TylvCvCQ==

La seule différence se situe dans le format : Sakia semble générer un retour chariot supplémentaire à la fin (le fichier termine par 2 retours chariot), que Cesium ne réalise pas. Mais je suspecte les outils Windows de le rajouter. Bref, je ne sais pas :slight_smile:

Publication

J’ai d’abord tenté via Cesium https://g1-test.duniter.org. Je me suis dit que, peut-être, la révocation n’avait pas été correctement envoyée au nœud pour eliadem à cause d’envoi HTTPS → HTTP.

Néanmoins, vu que j’accède au compte, Cesium fait déjà des requêtes sans problème. J’ai donc réussi a publier la révocation selon Cesium :

image.png928×858 53.3 KB

Si je regarde la réponse technique, cela se confirme :

image.png557×515 53.1 KB

Jusque là, aucun soucis à déplorer.

Attente de validation

J’attends donc patiemment depuis 20 minutes, mais toujours rien en blockchain, alors que la fréquence sur Ğ1-Test est de 1 bloc / 2’30". Je décide de jeter un coup d’œil à /wot/lookup-cgeek-test-revocation :

{
  "partial": false,
  "results": [
    {
      "pubkey": "4Ec3yqwfCxJM2pB3jCGrbUSvxqDGxasQcBCxCyA81Nwh",
      "uids": [
        {
          "uid": "cgeek-test-revocation",
          "meta": {
            "timestamp": "7372-00008776316C84C2C3981F856F0567A930FD3FDFFB2A4231E0ABCD92F177352E"
          },
          "revoked": false,
          "revoked_on": null,
          "revocation_sig": null,
          "self": "dPuqMqjJAszmujv6WQnXnIPIwgb/w2bXk+o/2JYAxElFwxv1j0If5bWp+skyzUESQSVOh++gg3pmGATIG2NeAw==",
          "others": [...]
        }
      ],
      "signed": []
    }
  ]
}

1er constat : "revoked": false, ce qui vient confirmer que la révocation n’est pas encore effective.
2ème constat : "revocation_sig": null, ce qui signifie que la révocation n’est même pas reçue par le nœud. Pourtant celui-ci a répondu “HTTP 200 OK”, la révocation est censée être enregistrée.

Alors je ne vais pas plus loin dans un 1er temps : manifestement il y a un soucis avec le nœud.

Plongeon dans le code Duniter

Pourtant, cette partie est totalement couverte par des tests, je sais que la révocation fonctionne de bout en bout. Donc qu’est-ce qui peut bien se passer ?

J’utilise mon poste de développement local pour recréer un nœud authentique sur le réseau. Je branche Cesium dessus et publie la révocation. Je regarde l’URL /wot/lookup de mon nœud local. Résultat :

{
  "partial": false,
  "results": [
    {
      "pubkey": "4Ec3yqwfCxJM2pB3jCGrbUSvxqDGxasQcBCxCyA81Nwh",
      "uids": [
        {
          "uid": "cgeek-test-revocation",
          "meta": {
            "timestamp": "7372-00008776316C84C2C3981F856F0567A930FD3FDFFB2A4231E0ABCD92F177352E"
          },
          "revoked": false,
          "revoked_on": null,
          "revocation_sig": "EVlHVyCn73o2GCAQPp3ADXufaeo0ND8wOyJp8Cr4xyHQEyqVXqaSgUwfPjerGiEFamtohkcqjTjtN8TylvCvCQ==",
          "self": "dPuqMqjJAszmujv6WQnXnIPIwgb/w2bXk+o/2JYAxElFwxv1j0If5bWp+skyzUESQSVOh++gg3pmGATIG2NeAw==",
          "others": [...]
        }
      ],
      "signed": []
    }
  ]
}

Voilà qui est fort ! La révocation est bien présente, comme les tests unitaires me l’indiquent. Je ne m’étais donc pas trompé sur ce point. Je revérifie du même coup sur mon nœud officiel g1-test.cgeek.fr. Bingo ! La révocation est bien présente, par rebond réseau. J’attends donc qu’elle passe.

10 minutes, toujours rien. Je revérfie les URL /wot/lookup: et là “pouf” ! Plus de révocation. Celle-ci a disparu, sans s’inscrire en blockchain.

Je décide de réitérer l’opération, cette fois-ci en éteignant mon nœud immédiatement après avoir reçu la révocation, pour voir s’il tentait bien de générer un bloc avec celle-ci dedans. Impeccable. Tout fonctionne. Alors pourquoi celle-ci disparaît sans s’inscrire ?

Voilà ce qui me vient à l’esprit : la révocation se publie parfaitement, pas de soucis là-dessus. Oui mais, à la réception d’un nouveau bloc, un nettoyage des piscines est effectué en fonction de divers critères. Il n’est pas du tout impossible que, dès que la révocation est publiée, déjà le prochain bloc qui arrive ne l’inclue pas (puisque aucun nœud ne la connaissait quand il a commencé à calculer) mais en plus provoque son effacement !

Je vérifie … et en effet en modifiant légèrement le test pour inclure un bloc « vide » avant de créer le bloc avec la révocation, celui-ci supprime la révocation en piscine.

Ligne fautive ? Celle qui nettoie la piscine d’identité :

https://github.com/duniter/duniter/blob/master/app/lib/dal/sqliteDAL/IdentityDAL.js#L118

En effet, pour une révocation le champ expires_on vaut null. La révocation était donc supprimée au 1er bloc qui arrivait.

Bon, du coup je vais publier une version corrective demain :slight_smile:

9 Likes