Voici un faux compte pour Ğ1-Test, pour réaliser un essai de révocation vu que @eliadem n’a pas pu révoquer son compte. S’il y a un problème, j’aimerais bien l’identifier.
UID: cgeek-test-revocation
PUB: 4Ec3yqwfCxJM2pB3jCGrbUSvxqDGxasQcBCxCyA81Nwh
arf, oui, je le sentais bien ce problème de révocation !
Effectivement du coup ca urge de tester ca.
j’espère que le doc généré par Cesium fonctionne
Je crois qu’eliadem utilisait Cesium. Du coup, je prévois le protocole suivant :
Je m’arrête dès qu’une étape > 2 réussit. Ainsi, j’aurais probablement identifié l’étape problématique, ou a minima cerné un intervalle d’erreur.
Mince une attaque sybil sur la monnaie de test 
Non plus sérieusement c’est chouette je vais enfin pouvoir coder la prise en compte des révocations dans g1-monit (hé oui ce n’est pas le cas pour le moment car l’idée d’écrire un code que je ne pouvais pas tester ne m’enchantais pas !).
Certifié !
Hésitez pas, surtout ceux qui ont pas de certif en attente, ça peut accélérer le test !
Mon identité à révoquer est passée cet après-midi. Voici les résultats :
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 
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 :
Si je regarde la réponse technique, cela se confirme :
Jusque là, aucun soucis à déplorer.
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.
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
Ouhaou ! Cgeek Holmes a brillé 
Bien joué
Version 1.3.12 déployée sur Ğ1 et Ğ1-Test.
J’ai pu révoquer avec succès le compte cgeek-test-revocation :
Je vous invite à vérifier par vous-même.
Je confirme l’identité a bien été révoquée : http://g1-test.elois.org:10900/blockchain/block/8495
Nous voila tranquille, il n’y a plus de faux compte sur ğ1-test
Question idiote @cgeek (et peut être qui enfonce une porte ouverte) C’est possible de faire attendre le passage d’un bloc dans le test de cette fonctionnalité ? Pour assurer la non régression sur le fix ?
Je n’ai pas compris, que veux-tu dire ?
Tu as dit que la fonctionnalité était testée.
Est-il possible dans le test, de simuler le contexte ici (un nouveau bloc arrive) pour pouvoir valider automatiquement que les prochaines évolutions ne casseront pas à nouveau la révocation pour une raison similaire ?
Ah oui, bien sûr, j’ai un ticket pour me rappeler d’inclure le test.
Le test est déjà écrit, seulement il nécessite une mise à jour de duniter-prover pour être exécuté correctement, donc celui-ci ne fait pas partie du commit (ça m’évite des changements plus lourds pour faire une version mineure).
Tu le verras passer cet après-midi 
Bravo @cgeek pour cette analyse. Franchement ce truc me faisait peur J’imaginais déjà la panique : “tout le monde doit regénérer son fichier de revocation ! …oui mais moi je sais plus quel fichier est le bon, etc.”)
Bref, on s’en sort pas trop mal.
(et bravo pour ta narration : tu pourrais te reconvertir ! ^^ )
