Est-ce qu’il serait envisageable de permettre à l’utilisateur de choisir la dérivation à utiliser lors d’une migration v1 → v2 (tout en gardant la //2 par défaut) ?
Sur ce type de manip ça permettrait de gagner 1 semaine 
Oui c’est déjà le cas, il faut juste créer la dérivation que tu veux avant, sur l’écran de migtation tu as un dropdown pour choisir le portefeuille de destination.
1 Like
Ah ben j’avais pas vu ça. Je le saurai pour la prochaine fois ! Merci.
1 Like
Il faudrait qu’on repense la toile forgeron parce qu’il y a plein de choses pas intuitives et pas forcément utiles. Mais pour l’instant je pense que ça peut rester comme ça si on veut migrer la Ğ1 un de ces jours, donc il faut tolérer ces effets de bord au genesis.
Avec Ğcli c’est assez facile en ligne de commande :
gcli smith revoke
gcli identity change-owner-key
gcli smith request
gcli smith claim
Mais il faudrait publier automatiquement un binaire de Ğcli parce que pour l’instant il faut compiler soi même.
Je ne suis pas certain que ce soit si simple. Il faut d’abord accéder à son identité v1 pour pouvoir révoquer le smithMembership. Je n’ai pu faire ça que via le polkafork de @poka.
J’ai un peu de mal à comprendre pourquoi on part smith par défaut sur la gdev, alors que le premier geste à faire pour récupérer son identité est de révoquer le smithMembership. Cette logique m’échappe
Ah oui, pardon, avec des identités v1 sur gcli il faut faire :
gcli -S cesium smith revoke
(Ğcli est maintenant compatible avec les identifiants Cesium.)
2 Likes
Parceque techniquement ce n’est pas une obligation de migrer son compte ailleurs, c’est juste que côté client on estime mieux de se passer des id/pwd cesium pour des raison de sécu et d’ux.
Comme les clients affiches et manipules des adresses ss58 sur la v2 au lieux des pubkey sur la v1, ça fait un changement de “rib” pour les utilisateurs quoi qu’il en soit, donc autant en profiter pour inciter à changer ses clés au passage à ce moment là.
Le jour de la vrai migration, le plus simple serait que tous les smiths indique leur changement de clé au genesis comme l’a fait cgeek ici: resources/gdev.yaml · master · nodes / rust / Duniter v2S · GitLab
(action qui se faisait auparavant côté py-g1-migrator)
Enfin sauf ceux qui veulent garder leurs id/pwd cesium avec des clients qui le permettent…
En fait c’est surtout pour Polkadotjs qui contraignait l’utilisation de sr25519 que l’on avait besoin de migrer au Genesis. Mais grâce à ton fork, le besoin n’existe plus il me semble. @HugoTrentesaux tu confirmes ?
Je serai plutôt d’avis de retirer la migration au Genesis pour les prochains reboots.
1 Like
Il y a un monde où les choix de design côté clients peuvent impacter les choix de certaines fonctionnalités côté serveur.
Si les clients grand publics incitent à migrer vers des mnemonics pour certaines raisons (choix que nous avions fait avec elois bien avant la migration substrate, dès le début de gecko sur GVA), alors les smiths ne pourront pas utiliser leur compte membre sur ces clients.
Ce n’est pas forcements grave, les smiths pouvants utiliser des outils avancés, mais il convient de le noter tout de même.
Si Cesium² ne fait pas le choix d’inciter les gens à passer vers du mnemonic, il risque d’y avoir un soucis d’homogénéité entre les clients.
Je suis tout à fait ouvert à rediscuter de cela, et à changer la façon de faire dans gecko mobile si on décide de finalement revenir en arrière sur cette décision, mais je pense qu’il faut qu’on soit tous au claire sur ce sujet pour savoir comment orienter les clients, comment communiquer au publique, et trancher certains design côté serveur.
1 Like
J’ai l’impression qu’on a du mal à se détacher de l’idée 1 identité = 1 paire de clés. Il y a plein de manières de faire autrement :
- lier plusieurs paires de clés à une identité
- déléguer certains calls avec la pallet proxy
Ce que suggère la sous-toile forgeron telle que formulée actuellement est que les clés avec lesquelles les calls forgeron sont appelés doivent être les clés actuelles déclarées par l’identité (“owner_key”). Sauf que vu comme c’est implémenté actuellement, ça interdit de changer les clés d’un forgeron.
Petite prise de recul : les “session_keys” sont les clés du noeud, on recommande que ça ne soit pas aussi les clés de l’identité, mais la pallet authority_members permet de faire le lien entre l’identité forgeron (et donc ses clés) et les session_keys. On pourrait faire pareil pour l’adhésion forgeron.
L’analogie des clés est d’ailleurs bonne : on peut en faire un double. Si j’ai chez moi :
- un garage à vélo
- une maison
- un coffre fort
je peux distribuer un double des clés du garage à vélo à tous mes voisins, un double des clés de ma maison à quelques amis, et être le seul à avoir les clés de mon coffre fort. Ce n’est pas parce que ma maison est ouverte que j’y suis.
Tout ce qu’on demande aux gens c’est de faire attention aux clés qui ont les droits d’accès sur leur identité et leur appartenance forgeron pour éviter que quelqu’un de mal intentionné s’en empare et nuise au réseau en usurpant leur trousseau de clé. Et c’est le sens de la toile de confiance : on s’engage à être le seul à avoir accès à ses clés.
Donc si on s’aperçoit que c’est pratique d’avoir :
- les clés d’un portefeuille sur son téléphone sans mot de passe
- les clés de son identité sur son téléphone, protégées par un mot de passe
- les clés forgeron dans son keepass ou sur un support matériel “hardware wallet”
- les clés de session de son nœud validateur dans un conteneur sécurisé sur son serveur et nulle part ailleurs
alors il faut qu’on fasse en sorte que ces clés soient différentes.
Concrètement, voici à quoi pourrait ressembler un nouveau comportement :
- quand une identité fait une demande d’adhésion forgeron, elle déclare des clés forgeron
- à partir de ce moment, les clés de l’identité ne peuvent plus être utilisées pour les actions forgeron
- seules les clés forgeron permettent d’effectuer des actions forgeron
En fait, l’intuition de elois d’avoir des métadonnées d’adhésion était bonne, mais c’était les clés forgeron qu’il fallait donner, pas les session_keys.
Autre proposition d’implémentation plus simple :
- à l’adhésion forgeron, les clés de l’identité sont utilisées
- à tout moment un forgeron peut changer ses clés
- seules les nouvelles clés pourront effectuer des actions forgeron
2 Likes
J’essaie à nouveau de changer mon identité via polkadot mais je ne m’en sors pas
Comment obtenir le paramètre newKeySig de l’extrinsic indentity.changeOwnerKey() ?
Ca me rappel quelque chose…
Donc je vais dans Développeur / Signer et vérifier, puis je saisis :
0x69636F6B<GENESIS_HASH><IDTY_INDEX><OLD_OWNER_KEY>
Je signe et je copie-colle la signature obtenue comme paramètre pour l’extrinsic ?
Si j’ai correctement compris, IDTY_INDEX = 95320000 (12949 en décimal).
Comment je retrouve le GENESIS_HASH et et OLD_OWNER_KEY en hexa ?
EDIT: J’arrête les noeuds dans la tête. Je suis passé par gcli et ça a marché.
1 Like
Ne me reste plus qu’à gérer les session keys avant de passer online. J’ai fait ça :
$ ./bin/gcli -u ws://localhost:9944 --no-indexer smith update-keys
Mnemonic:
transaction submitted to the network, waiting 6 seconds...
Il n’y a aucun message en sortie confirmant ou non que ça s’est bien passé. Comment puis-je contrôler que l’opération rotate keys + set session keys a bien réussi ?
Avec Polkadot.js dans Données de la chaîne, session, nextKeys()
1 Like
