Migrate smith identity

Tu peux déjà tester Gecko, pour Cesium², c’est au point mort pour encore quelque temps (mois, années ?)

1 Like

Oui, Gecko installé sur smartphone mais pas possible de migrer mon portefeuille parce que je suis forgeron. Je vais tenter différemment.

1 Like

@HugoTrentesaux @elois @cgeek ce ne serait pas possible de lever cette restriction ?

1 Like

Je ne suis pas sûr que ce soit une bonne idée de lever cette restriction.
Il me semble plus sûr, que le forgeron révoque son status forgeron avant de migrer, et le redemande après. Question de sécurité avancée…

Je ne suis pas sûr que cela ajoute une sécurité particulière.
L’ancienne clé est censé pouvoir révoquer sont status forgerons même après migration, tout comme pour la toile de confiance principale.

La différence de traitement entre membre toile principale et toile forgerons me semble un peu étrange.

A la limite, je comprendrais mieux la restrictions en ce qui concerne les membres sur comité technique, bien plus sensible, mais je ne suis même sûr qu’il y en ait pour le coup là dessus (j’espère).


Auquel cas si on reste ainsi (ce qui je pense va être le cas), en terme de communication il faut penser à informer les gens que ceux qui veulent devenir forgerons doivent migrer leur identité en coffre avant si il veulent pouvoir utiliser les outils sécurisés avec leur compte membre.

3 Likes

Est-il simple de révoquer son statut forgeron puis de le redemander ?

Oui

(à propos du changeOwnerKey interdit aux forgerons) Je crois que c’était à cause de authorityMembers. Mais si c’est ça il suffirait d’obliger à passer offline avant de migrer. Sinon je ne vois pas de raison, si c’est une raison de sécurité il faut trouver un exemple d’attaque.

3 Likes

C’est un check préventif côté Gecko car à l’époque c’était une restriction, si ça se trouve ça a changé depuis, je n’ai pas essayé, mais je ne pense pas.

1 Like

Tu penses que si je passe mon noeud offline et tente à nouveau de migrer, ça fonctionnera ?
Ensuite, je le remets online.
Si ok, je teste demain matin ou aujourd’hui si je trouve le temps

Je viens de vérifier, le critère est d’être hors-ligne depuis 168 époques (soit 28 jours), mais on peut rester forgeron.

Apparemment c’est la durée pendant laquelle un forgeron peut être puni pour avoir triché.

Je ne savais pas ce que c’était en lisant la liste des paramètres, et comme la durée d’une époque est passée de 1h à 4h, cette durée a aussi été multipliée par 4. Je suppose que ce n’est pas voulu, et propose de repasser à 42 époques soit 1 semaine, si c’est encore possible de changer.

4 Likes

Je vous laisse trancher ça.


smithMembers.smiths(34) semble indiquer lastOnline toujours null même pour les smiths actuellement en ligne.
lastOnline: null

Comment check côté wallets le blocknumber de la dernière fois qu’il était en ligne ?

Il y en a qui ont un lastOnline non null. Je suppose que c’est défini lors du goOffline (volontaire ou automatique). Je ne sais pas si le fait qu’il soit null alors qu’on est forgeron implique qu’on est online, mais si tu implémentes le même test que dans Duniter ça devrait marcher.

Non car un smith n’ayant jamais forgé est aussi à null.


Ok je temporise ce sujet pour le moment le temps qu’on éclaircisse que faire de ça.

1 Like

J’ai voulu tester de migrer mon identité g1v1 vers gtest avant d’accepter l’invitation smith; ce n’est pas passé non plus:

(je suis bien sur gtest - mais gcli affiche toujours le format substrate par défaut pour les address)

gcli gcli identity show
Identity index: 12242
Username:       Nicolas80
Address:        5GhAZBagx87sTGfMppfPPcWhxCKGWE8zDi1oHp7YiKosD9KZ
Status:         Member
Certifications: received 11, issued 14
Smith status:   Invited
Smith certs:    received 0, issued 0
gcli identity change-owner-key -v Nicolas80
Trying to retrieve key pair for address:'5DaT2YVTDxBG1mdWsiyeEd9isHPizUZNbg7vbgcm53DgPqfP'
(Vault: Base[address:5DaT2YVTDxBG1mdWsiyeEd9isHPizUZNbg7vbgcm53DgPqfP, g1v1_pub_key:5WELhBcoLxqTjxNZsoxb89Uqyxis6YR6DCqVe1gDw43Y, name:Some("Nicolas80"), crypto_scheme:Some(Ed25519)])
> Password ********
Trying to change owner key
(Vault: Base[address:5GhAZBagx87sTGfMppfPPcWhxCKGWE8zDi1oHp7YiKosD9KZ, g1v1_pub_key:EnFfLNWnonXwxmzipLbbqa1fybSs7xdPoYhmbkMYzR3G, name:Some("Nicolas80-G1V1"), crypto_scheme:Some(Ed25519)])
> Password ********
transaction submitted to the network, waiting 6 seconds...

Pallet error: Identity::OwnerKeyUsedAsValidator

Du coup, je suppose qu’il n’y a pas moyen de migrer dés le moment on reçoit une invitation smith…

2 Likes

En effet ça a l’air d’être un bug. Duniter teste si smith.last_online == None. Je n’avais pas tilté, mais puisque

il croit que tu es online si tu ne l’as jamais été.

4 Likes

Il me semble que le check est celui-ci :

[edit sur branche network/gdev-800]

/// Runtime handler OwnerKeyChangePermission.
pub struct OwnerKeyChangePermissionHandler<Runtime>(core::marker::PhantomData<Runtime>);
impl<
        Runtime: frame_system::Config
            + pallet_identity::Config<IdtyIndex = IdtyIndex>
            + pallet_authority_members::Config<MemberId = IdtyIndex>,
    > pallet_identity::traits::CheckKeyChangeAllowed<Runtime>
    for OwnerKeyChangePermissionHandler<Runtime>
{
    fn check_allowed(idty_index: &IdtyIndex) -> bool {
        !pallet_authority_members::Pallet::<Runtime>::online().contains(idty_index)
    }
}

Je ne vois pas où apparaît last_online dans le code :thinking:

[edit sur master ou network/gtest-1000]

Je ne trouve pas ce code, il est dans quel fichier, quel branche ?

Le test dont je parlais est dans ma MR : Fix #320 New smith cannot change owner key (!336) · Merge requests · nodes / rust / Duniter v2S · GitLab

Edit: d’ailleurs j’ai mis Élois en reviewer car je ne savais pas qui mettre et qu’il semblait avoir plus de temps dernièrement, mais si tu veux reviewer vas-y.

Je faisais référence à runtime/common/src/handlers.rs · network/gdev-800 · nodes / rust / Duniter v2S · GitLab, je me suis planté. On dirait que ce n’est pas dans master. J’espère que c’est normal et qu’il ne va pas falloir faire la chasse aux commits, je n’aime pas ça. C’est pour ça que je voulais que tout aille sur master et que l’on merge master dans network/* quand on en a besoin, et que n’aille sur network/* que les changements spécifiques à un réseau (chainspecs…) et que network/* ne soit jamais mergé sur master. Je me note à regarder quand j’ai le temps, mais ça n’arrive pas souvent en ce moment :frowning:

3 Likes