Si on généralise ça, je dois à chaque démarrage de mon ordi perso, et à chaque redémarrage de mon serveur, entrer une commande et un mdp pour chaque logiciel ayant besoin d’un trousseau de clefs. C’est tout de même peu pratique, et l’apport en sécurité me semble faible dans le cas d’un serveur (l’hébergeur pouvant tout autant fouiller le DD que la mémoire).
2 Likes
La mémoire est censée être nettoyée par un mécanisme clear and drop (j’en ai parlé aux rml14), en tout cas se sera le cas dans Dunitrust. Dans les logiciels ou c’est fait correctement, il est alors impossible de récupérer les credentials depuis la mémoire après l’arrêt du logiciel.
De plus, récupérer des infos dans la mémoire vive est infiniment plus compliqué, l’attaquant ne sais pas ou chercher, alors que dans un système de fichier c’est immédiat.
1 Like
Comme l’a précisé tuxmain…
…et le redémarrage d’un serveur pour l’application d’une màj du kernel par exemple.
Dans ce cas l’administrateur remet sa clé, et c’est reparti.
Ça rend assez difficile la vie des nœuds temporaires (entendre, non serveur), mais ça ne me semble pas pertinent pour faire tourner une monnaie sur le long terme.
Oui c’est ce que je fais quand je maj un serveur ou j’ai Duniter dessus, je ne vois pas le problème, sauf peut-être avec le TPV 
Est-ce intéressant d’y inscrire un champ currency: contenant le nom de code de la monnaie ?
Ça permettrait au logiciel de dire que ce fichier d’authentification est fait pour une autre monnaie dans le cas d’usage sur une autre monnaie. Voire d’empêcher son usage sur la monnaie concernée (modifier le fichier ou le logiciel peu quand même contourner le blocage).
Ce champ pourrait être optionnel afin de permettre l’authentification sur plusieurs monnaies.
Mais, je pense que c’est une bonne pratique de forcer l’usage d’un fichier d’authentification/clé publique par monnaie.
3 Likes
Je me disais… En fait quel que soit ce que l’on fasse, il y a toujours cette clef membre qui doit se retrouver sur un noeud calculant… C’est parce que la création du DU est conditionné à ce statut membre « gravé » par un document dans la blockchain.
Mais, si plutôt que de dépendre de cet événement, le DU était fabriqué en fonction des liens établis dans la WOT… En effet, en remontant jusqu’au bloc 0, il est possible de vérifier tous les comptes qui ont des amis qui créent déjà le DU, et si on en a plus que 5 (et que les règles de distance sont bonnes), et bien on crée le DU… Dans ce cas le protocole devient autonome… Il auto découvre les membres… Vous voyez ce que je veux dire?
On pourrait même rendre le paramètre règle de distance et nombre d’amis dynamique.
NB: je n’ai toujours pas vraiment compris quelle machine ajoutait les DU dans la chaîne? L’algo tire au sort, tout le monde en écrit un peu? A l’heure du DU que se passe-t-il, une synchro réseau particulière a lieu?
Non pas du tout, a terme ce ne sera plus le cas, la solution technique est connue depuis longtemps, on manque juste de ressources pour l’implémentée, et on a d’autres priorités aussi : [Idée] Clé déléguée au calcul de blocs
Rien de tout cela. Ça se passe de la même façon que l’expiration d’un abonnement ou d’une certification.
Lorsqu’un nouveau bloc reçu est validé par un noeud Duniter, il l’ajoute a sa chaîne puis déclenche la génération du contenu du bloc suivant, c’est a ce moment la qu’il puise dans sa mempool pour event user a inscrire dans le bloc et qu’il calcule tous les événements automatiques qui doivent êtres générés en fonction de l’heure du bloc qu’il est en train de généré (déterminée donc a la création du bloc).
1 Like
OK @elois merci pour ces précisions.
Concernant cette idée de rendre le DU indépendant du statut « membre » mais plutôt de sa règle de distance dynamique aux sources du bloc 0, qu’en pensez-vous?
Que c’est incohérent. Car la règle de distance est défini sur la WOT qui elle même est définie sur les identités membres inscrites en blockchain et leurs certifications.
S’il n’y a plus d’identité membre “gravée” en blockchain, alors il n’y a plus de WOT, plus de DU et donc plus de monnaie.
Tous découle de se statut “membre” en blockchain, sans lui il n’y a plus rien, plus de règle de distance, plus de WOT, plus de DU, plus de monnaie.
Dans la mesure où des applications non-monétaires sont possibles (voir ssb), ce champs pourrait être nommé application :
Oui du coup je met a jours la spec en ce sens 
Non, c’est une mauvaise pratique que d’utiliser un même trousseau de clés pour plusieurs applications. C’est aussi grave que d’utiliser le même mot de passe sur tous les sites web ou l’on a un compte.
Ce que propose @Frederic_Renault d’utiliser sa clé G1 dans ssb est une très mauvaise pratique.
Pour lier son identité G1 avec son identité ssb, une bonne façon de faire est par exemple de signer sa clé publique ssb avec sa clé privée G1 et de publier la signature sur son feed ssb, cela permet de “prouver” le lien entre l’identité G1 et l’identité ssb
3 Likes
OK. dans ce cas c’est effectivement incohérent car impossible à implémenter… cette idée a du me venir en découvrant les propriétés des blockchain fabriqué par scuttlebutt. Dans leur protocole, l’identité et la wot sont la source…
tu as toujours de bonnes idées, merci
Ce genre de messages provocateurs me semble très inapproprié, en l’état je n’ai pas envie d’y répondre.
j’ai écris à @cgeek en privé pour qu’on en parle.
Tu prends un peu vite la mouche je trouve.
Cette histoire de Rust qui ne pourrait pas gérer de signature en lisant directement la clé privée, je n’y crois pas une seconde. Il va falloir être un peu plus convaincant.
En première lecture @elois ça paraît bizarre en effet. Mais tu veux sans doute signifier autre chose, pourrais-tu alors préciser ce point clairement ? C’est sans doute que tu ne voudrais pas ? Quelle que soit la raison il est préférable de l’expliciter, ça aidera
2 Likes
C’est exactement ce que je prétend : qu’il ne veut pas. Et je n’y verrai aucun problème, quelle qu’en soit la raison. Mais nous raconter que ce n’est pas possible en se cachant derrière l’écosystème Rust, c’est vraiment nous prendre pour des jambons.
Ça peut paraît anodin bien sûr. Mais considérant qu’Eloïs a été capable de s’approprier de gros sujets techniques, j’y vois une manipulation malsaine ici.
Et qu’on ne me dise pas que c’est une maladresse, vu l’insistance du « ne peux pas », d’un gros pavé d’explications et du pointage d’un bug Duniter (justifiant … son choix, précisément).
Quant à la provocation, @elois, là ce n’est que moi, et l’idée est bien de te faire réagir et, je l’espère, te permettre d’évoluer face à ce qui t’attend. Comment réagiras-tu quand les ennemis seront bien plus costauds et relèveront chacune de tes incohérences ?
2 Likes
Je suis globalement d’accord avec l’analyse de sécurité d’elois . Surtout avec son analyse ci-dessous :
Ceci dit :
Les OS savent stocker des données dans des espace sécurisés qui sont débloqués au boot. Pas de raison que Dunitrust ne puisse pas profiter de telles fonctionnalités. De plus, c’est assez facilement contournable avec un script de type expect. Une fonctionnalité de sécurité qui va agacer les utilisateurs pour finalement être contournées va générer encore plus de problèmes.
Pour gérer les seed de manière sécurisée, je te conseille plutôt de permettre de les récupérer via des variables d’environnement. Ca évite que l’utilisateur contourne ça via expect, et ça te permet de donner des conseils dans la doc de setup des variables sur comment bien sécuriser son système hébergeant le noeud dunitrust.
D’accord avec kimamila. Si elois veut stocker ses clés membre et network avec le même chiffrement… Ben il chiffre les 2 fichiers avec le même mot de passe. C’est plus KISS.
4 Likes
Ce mode de communication ne me conviens plus en fait. La provocation me donne juste envie de ne pas répondre.
Je sais que ce fût hélas régulièrement un moyen de communiquer entre nous par le passé, mais je le regrette. Les tord out souvent été partagés, de mon coté j’ai compris qu’il était nécessaire que je fasse un travail sur moi pour changer, ce que j’ai entrepris, j’ai encore du chemin a faire mais je souhaite que notre façon d’échangée devienne ce qu’elle aurait toujours du être : respectueuse, cordiale, chacun à l’écoute de l’autre
Cela m’aurais aidé a l’époque que l’on refuse de répondre a mes questions lorsque j’étais trop incisif. Le fait qu’on y répondais quand même me faisait comprendre “c’est ok d’être agressif”.
Je n’ai pas “d’ennemis” @cgeek, si une personne extérieure a l’équipe est agressive avec moi par écrit, ça m’est égal, je ne la connais pas, ça ne me touche pas, je signale a la modération et ne répond pas. Face à l’agressivité écrite la meilleure reste l’absence de réponse. Ceux qui cherchent sincèrement à comprendre poseront leur question avec respect, et ceux qui cherche a plomber le projet ce feront modérés, c’est tout. La seule “préparation” qui me semble nécessaire, c’est la modération
Sur le sujet de ce thread, si tu me relis bien, tu verra que je n’ai jamais écris nul part que le Rust ne pourra pas faire ceci ou cela, j’ai bien parlé de Dunitrust uniquement. Il est vrai que je n’ai pas précisé totalement pourquoi Dunitrust ne le peut pas, car l’explication est longue, et a l’époque ou j’ai posté je pensais que ça ferai trop long, et je manquais de temps aussi, j’avais déjà prévu d’attendre qu’on me pose la question. C’est ce qu’a fait @Galuel, je vais donc y répondre dans la soirée (dans un post séparé pour des questions de lisibilité).
Merci @Inso j’y avait en fait déjà pensé mais uniquement pour le use case docker. J’avais prévu de permettre la récupération de la passphrase via variable d’environnement uniquement pour le livrable docker. Je n’ai en effet pas pensé a l’incentive de contournement via expect que cela pourrai produire, il faudrait donc que j’élargisse cette feature a tous les livrables.
2 Likes
Pas tout a fait. Je t’avais déjà posé la question clairement, ne comprenant pas le soucis véritable :
J’ai relu ton argumentaire de départ, et tu sembles croire que laissé l’accès au seed (aux développeurs) est moins grave que l’accès a la clef privé. Quelle différence cela fait il ? L’un entraînant l’autre, d’un point de vue de la sécurité, ça me semble équivalent. Ou alors j’ai loupé quelque chose ?