Identity revocation

[poka]

J’implémente la révocation d’identité dans Gecko.

Je reproduis le même schéma que pour la migration d’identité:

   final prefix = 'revo'.codeUnits;
   final genesisHashString = await getGenesisHash();
   final genesisHash = HEX.decode(genesisHashString.substring(2)) as Uint8List;
   final idtyIndexBytes = _int32bytes(idtyIndex);
   final messageToSign =
       Uint8List.fromList(prefix + idtyIndexBytes + genesisHash);
   final revocationSig = await _signMessage(messageToSign, address, password);

   final txInfo = TxInfoData(
     'identity',
     'revokeIdentity',
     sender,
   );

   final txOptions = [idtyIndex, address, revocationSig];

@HugoTrentesaux m’a aidé à trouver le prefix dans le code de Duniter, ainsi que la composition du message à signer (payload).

Lorsque j’exécute cela, quelque soit le compte et le réseau, l’extrinsic finit en timeout 12s, pas d’erreur.

---

Sur la GD, en voulant révoquer test1 qui a pour adresse 5FeggKqw2AbnGZF9Y9WPM2QTgzENS3Hit94Ewgmzdg5a3LNa , voici le message à signer que j’obtiens:

[114, 101, 118, 111, 24, 0, 0, 0, 7, 193, 18, 255, 106, 185, 215, 208, 213, 49, 235, 229, 159, 152, 179, 83, 24, 178, 129, 59, 22, 85, 87, 115, 128, 129, 157, 56, 214, 24, 45, 153]

Est-ce que quelqu’un peut me confirmer que c’est bien le bon message ?
Une idée de ce qui peut provoquer ce timeout ? L’extrinsic est bien identity.revokeIdentity(idtyIndex, revocationKey, revocationSig) ?

Un test d’intégration spécifique qui échoue a été écrit: integration_test/identity_revocation.dart · revocation-mechanisme · clients / Ğecko · GitLab

[mildred]

Pour info, il n’y a plus de période de révocation… Remove RevocationPeriod rule (#55) · Issues · nodes / rust / Duniter v2S · GitLab

[poka]

Je viens pull le tag docker debug-latest, et mon test échoue toujours au même endroit sur une blockchain local.

[vit]

En Python, je trouve bien le même message à signer que Gecko.
Pour tester la signature et le call, il me faudrait le password…

[poka]

Il s’agit de la dérivation 2 du mnemonic:

pipe paddle ketchup filter life ice feel embody glide quantum ride usage

C’est le mnemonic de test utilisé dans les tests d’intégrations Gecko indiqué ici:

@poka

pipe paddle ketchup filter life ice feel embody glide quantum ride usage

---

Du coup si le message est bon, je pense que la signature aussi vue que OK pour les migration d’identité, et de toute façon j’ai pas d’erreur de signature côté Duniter, juste un timeout.

C’est que mon extrinsic doit être mal formaté.

[poka]

@poka

identity.revokeIdentity(idtyIndex, revocationKey, revocationSig)

@poka

final txInfo = TxInfoData(
     'identity',
     'revokeIdentity',
     sender,
   );

@poka

final txOptions = [idtyIndex, address, revocationSig];

revocationKey correspond bien à l’adresse ss58 de la clé à révoquer ?

De toute façon que j’essai avec address ss58, pubkey Uint8List ou hexa, c’est pareil.

[vit]

J’ai un problème avec le paramètre de la signature.
Il me dit que mon paramètre ne correspond pas à une entrée d’un ENUM (liste fermé d’arguments fixe).

Si je regarde ce qu’attend l’interface pour cet extrinsic, effectivement il attend le type

revocationSig: SpRuntimeMultiSignature (RevocationSignature)

Et dans l’UI il propose une énumération des types de cryptos, suivi du champ pour la signature…

Ce paramètre « revocationSig » attend donc 2 valeurs !

Maintenant il faut que je comprenne comment lui transmettre une double valeur en Python (sûrement un dict ou une liste…).

[poka]

Oui je ne comprends pas pourquoi il n’y a pas ce champ cryptotype pour l’extrinsic changeOwnerKey mais présent pour revokeIdentity.

Ta raison ça doit être le soucis, je vais essayer de lui fourrer ce qu’il attends …

[vit]

Je viens de lancer mon script sans erreur avec le dico :

params = {
    "idty_index": identity_index_int,
    "revocation_key": identity_address,
    "revocation_sig": {"Sr25519": "0x" + signature_bytes.hex()}
}

Mais rien dans l’explorateur… comment savoir si mon call est passé ?

On peut continuer sur le chat xmpp…

[poka]

C’est que tu finis en timeout comme moi, l’extrinsic ne s’exécute pas.
Oui on continue en mp

[tuxmain]

La RevocationPayload est au format b"revo" + genesis_hash + idty_index.

Edit: du coup je remarque que la doc et gcli ne sont pas à jour sur la révocation…

[poka]

@tuxmain

La RevocationPayload est au format b"revo" + genesis_hash + idty_index.

Bah dans ce test c’est: b"revo" + idty_index + genesis_hash

Alors que ici c’est b"revo" + genesis_hash + idty_index

Donc le test ne doit pas fonctionner je présume ?

@poka

final messageToSign =
       Uint8List.fromList(prefix + idtyIndexBytes + genesisHash);

Mais le soucis n’est pas la payload, c’est ce que attends l’extrinsic

---

C’est très curieux qu’on ai pas besoin de spécifier le type de crypto pour l’extrinsic changeOwnerKey mais qu’il le faille ici.

[elois]

@poka

je ne comprends pas pourquoi il n’y a pas ce champ cryptotype pour l’extrinsic changeOwnerKey mais présent pour revokeIdentity.

Car on profite du changement d’adresse de l’identité pour forcer le passage au crypto scheme le plus récent (sr25519).

@poka

Mais le soucis n’est pas la payload, c’est ce que attends l’extrinsic

Non c’est les deux, @tuxmain à raison.

@poka

C’est que tu finis en timeout comme moi, l’extrinsic ne s’exécute pas.

Si l’extrinsic est mal encodé le serveur vous renvoie une erreur RPC, si vous avez un timeout c’est que vous ne capturez pas les erreurs correctement quelque part.

[tuxmain]

@poka

Bah dans ce test c’est: b"revo" + idty_index + genesis_hash

Alors que ici c’est b"revo" + genesis_hash + idty_index

En Rust quand on crée une struct l’ordre des champs n’importe pas (et là comme les noms des champs sont les mêmes que les noms des variables à mettre dedans, on écrit juste toto plutôt que toto: toto). Ce qui compte pour l’ordre de l’encodage c’est la définition de la struct ici.

[poka]

Ok donc j’ai interchangé les 2 champs du payload comme indiqué.

Pour les erreurs, j’ai un try catch qui les écoutes bien, elles s’affichent lorsqu’il y en a, ainsi que mon callback onStatusChange qui met à jours l’ui avec le dernier status renvoyé par Duniter.

Donc je ne vois pas quoi faire de plus à ce niveau là.

L’extrinsic reste donc mal encodé, sans retour.

Indiquer CryptoType.sr25519.name ou CryptoType.sr25519.index avant ou après le champ revocationSig ne fonctionne pas, l’interface polkadotjs semble indiquer que c’est une Map ou kk chose comme ça sans être clair, et je n’arrive pas à comprendre en cherchant dans le code de Duniter.

Je demanderai à Hugo demain sinon qu’on regarde ensemble dans le code de Duniter.

[elois]

@poka

Pour les erreurs, j’ai un try catch qui les écoutes bien, elles s’affichent lorsqu’il y en a, ainsi que mon callback onStatusChange qui met à jours l’ui avec le dernier status renvoyé par Duniter.

Donc je ne vois pas quoi faire de plus à ce niveau là.

Peut-être que le problème se situe au niveau de polkawallet, mais je t’assure que le serveur renvoie bien une erreur RPC et que tu ne la capture pas.
Tu crois déjà capturer les erreurs, car tu confonds avec l’erreur d’exécution de l’extrinsic, qui est renvoyée par la souscription quand l’extrinsic est dans un bloc. Moi je te parle d’une erreur RPC renvoyée par le serveur au moment de l’envoi de la requête, donc sans devoir attendre un nouveau bloc.

@poka

Indiquer CryptoType.sr25519.name ou CryptoType.sr25519.index avant ou après le champ revocationSig ne fonctionne pas,

Les paramètres sont encodés en hexa, si t’es en sr25519 t’a juste à préfixer par 0x01 au lieu de 0x.

[poka]

@elois

Les paramètres sont encodés en hexa, si t’es en sr25519 t’a juste à préfixer par 0x01 au lieu de 0x.

Ah merci, c’est bon du coup ça passe maintenant !

Maintenant j’ai une erreur identity.NotAllowedToRemoveIdty dans mon test d’intégration, en voulant révoquer un compte membre genesis après 2 blocs dans ma blockchain local.

Mais par contre j’ai réussi à révoquer l’identité de test1 sur la GDev à l’instant avec gecko !

---

@elois

Moi je te parle d’une erreur RPC renvoyée par le serveur au moment de l’envoi de la requête, donc sans devoir attendre un nouveau bloc.

Ok j’ai compris, à creuser comment je peux catch ces erreurs.

[vit]

Pour info, j’ai fait le même test en Python que toi @poka et, après avoir corrigé les erreurs sur le type des paramètres, je n’ai pas eu de réponse de la requête RPC. Normalement j’ai un object Receipt, mais là rien…
A creuser aussi en Python donc…

[elois]

@poka

Maintenant j’ai une erreur identity.NotAllowedToRemoveIdty dans mon test d’intégration, en voulant révoquer un compte membre genesis après 2 blocs dans ma blockchain local.

C’est parce que sur master il ya un nouveau check qui interdit les membres forgerons de révoquer leur identité, ils doivent d’abord quitter la sous-toile forgeron avec le call smithsMembership.revokeMembership.

C’est nécessaire pour réduire le coût d’exécution de la révocation (4 à 5 fois plus élevé si le membre est forgeron et dans le set des autorités).
C’est aussi car révoquer une identité qui est dans le set des autorités peut causer des effets de bords dangereux.

[poka]

Je pense avoir finit d’implémenter la révocation direct dans Gecko.

J’ai quelques remarques:

• Comme un connard j’ai révoqué mon compte poka sur la GDev, je n’avais pas remarqué que le patch d’elois qui check smith n’était pas encore déployé sur la GDev…
• Cette même address anciennement poka n’a pas pu recréer d’identité poka, c’est très bien.
• Par contre j’ai pu créer l’identité salameche sur cette même address et redevenir membre 5 minutes plus tard sans problème.

Est-ce l’effet attendu ? Cela ne peut il pas poser de problèmes ?

• Ğecko informe en amont de l’impossibilité de révoquer son compte:

Y a il d’autres check que membre smith pour la révocation côté Duniter ?
Peut on migrer une identité faisant partie du groupe smith (je n’ai pas encore testé ce cas) ?

Tout le reste est écrit dans un test d’intégration.