En dehors de l'implémentation (dont je parlerai dans la deuxième partie du commentaire), le système d'entités me fait grandement penser au duck typing que l'on retrouve dans d'autres langages (notamment python):
Si une entité a des ailes alors c'est une entité volante.
Si un objet a des plumes et fait "coin coin" alors c'est un canard.
C'est très similaire comme approche.
Et sans aller jusqu'au système d'entité ou le duck typing (on en est même loin), il y a déjà des "avancés" dans ce sens dans les langages objet "classiques" avec les interfaces et les templates.
Tu parles d'optimisation en "linéarisant" les composants dans un tableau et ainsi en améliorer l'accès en utilisant les systèmes de cache. Je suis d'accord avec toi sur le principe mais, désolé, je ne le vois pas dans ton implémentation.
(je me base sur ton implémentation de la lib et du tutoriel des balles rebondissantes)
Dans la lib, le Store stocke les Component dans une map (std::map).
- Je ne sais pas ce qu'il en est avec la norme du C++11 mais à ma connaissance rien ne garantie que les données d'une map soient stockées de manière linaire.
- Si c'était le cas, te ne stockes pas un Component mais un pointeur. Et comme dans ton tuto tu alloues les composants à coup de new en alternant les différents types de composant, il y a très peu de chance que les composants d'un même type soit alignés.
- Si c'était le cas, le système ne parcoure pas dans l'ordre des composants mais dans celui des entités. Pour un exemple simple, il se peut que le parcours des composants se fasse dans l'ordre, mais dans un cas concret avec surpression/ajout d'entités, il y a de fortes chances que ça soit pas le cas. Qui plus est, ça casse quand même le cache vu que tu recharges ton conteneur des entités pour passer à la suivante.
La critique est facile, l'art est difficile. Alors je vais tenter de te proposer des axes d'améliorations :
Stocker les composants directement dans le Store dans un vecteur. Avoir un autre vecteur au lieu d'une map pour faire le lien entre les entités et les composants (un tableau pouvant être vu comme une map dont les clés sont des entier). Le principe est simple, tu continues d'avoir des accès en O(1) et tu gardes tes composants alignés. Dans la pratique ça se complexifie avec l'ajout/suppression d'élément dans le Store puisque qu'il faut tracer les index libérés & co (donc avoir d'autres vecteurs internes à maintenir). Du temps où je bossais dans le jeu vidéo, il était coutume de penser qu'il ne fallait pas utiliser les conteneurs de la std mais de refaire les siens. Ça fait un peu "réinventer la roue", mais la std est assez générique. Même si elle est bien implémentée, il y a beaucoup de choses qui servent à rien dans un contexte "restreint", si en plus il y a de forts besoins particuliers (performance, organisation mémoire) ça vaut souvent le cout de dev des conteneurs adaptés
Tu parles de Boost.Pool dans ton tuto, c'est une bonne solution pour éviter les allocations dynamiques mais je pense que c'est à la bibliothèque de gérer ce problème de mémoire et de garantir que la mémoire est alignée. (Ce point là est discutable, je l'accorde)
Dans ton exemples tu pourrais réunir les composants Coords et Look en un seul. À ce moment, le système Render peut parcourir directement les composants "GraphicalInfo" de manière linéaire sans passer par les entités. Par contre je n'ai pas de solution évidente pour ce qui est des systèmes "transverses" du type Graphics et Physics: vu que tu travailles sur deux composants en même temps, tu es obligé de passer par les entités. (Peut être que la littérature sur le sujet apporte une solution)
Juste une réflexion (je sais pas où ça mène ou si c'est utile mais j'ai envie de le dire :-) ) :
On peut voir le système d'entités/composants comme un système qui associe à un même nom (l'entité) différentes valeurs (les composants) selon "l'espace" dans lequel on regarde (les types des composants). La map dans ton Store (ou le deuxième vecteur dans ma proposition d'implémentation) étant le traducteur entre l'espace commun et les espaces spécifiques.
Enfin, je critique mais c'est quand même une petite lib sympa que fait le boulot qui lui est demandée. Qui plus est le code est propre et il y a de la doc. (Et vu le code de merde que je suis obligé de lire en ce moment, ça fait vraiment du bien :-) ) J'attends la suite avec impatience.
Oui, sauf que c'est plus de l'ergonomie. La conception d'interface utilisateur, c'est faire des trucs utilisables. Si l'utilisateur se perd dans tes menus ou se pose des questions sur le but d'un bouton, c'est que ton interface est à revoir. Point (pour ce qui est de l'ergonomie).
Ce commentaire ne porte pas particulièrement sur l'interface de Firefox. Mais j'aime bien rappeler au vieux barbus que nous sommes ce qu' est l'ergonomie.
RTFM et "si tu c'est pas ce que c'est n'y touche pas" ce n'est pas de l'ergonomie. Ça peut être une bonne chose selon le context, mais ce n'est pas le l'ergo.
L'ergonomie c'est : "Si c'est pas utilisé : vire le", "Si c'est utilisé par 1% des gens, ne le met pas avec les options utilisées par 99% des gens". Ça nous fait peut-être chier quand on fait parti des 1%, mais c'est comme ça qu'il faut faire.
Je ne connaissait pas le texte "For a truly acentric Internet". Il est totalement dans la même idée que PGPID.
Je pense qu'il y a un gros travail d'étude de l'existant à faire et contacter tout les projets qui pourraient être intéressés par PGPID. Si on arrive à fédérer suffisamment de projet, on peut arriver à quelque chose. Ça doit même être nécessaire si on veut que ça marche.
Les points qui me posent problème avec les noms parlants:
Lequel choisir ? Est-ce que je prend PrénomNom, Nom ou PNom ? Avec quel tld (.org, .com, .fr) ?
Comment gérer les conflits ? Premier arrivé premier servi ? Comment tu fais pour ceux qui ont le même nom ?
Si ta clé PGP est publiée, n'importe quel outils qui veut afficher des clés peut aussi afficher le nom associé.
La plupart du temps on clique, copie/colle les adresses mail ou web. Peu de gens les tapes au clavier. Ça serait pareil avec PGPID.
Bon, je viens de me pencher sur OpenUDC. C'est très intéressant, surtout avec la présentation audio (faites où?). Ça aurait été mieux avec la vidéo pour voir ce que tu affiches mais ça aide pas mal à avoir une idée globale.
C'est clair que vous êtes pas mal en avance sur moi. C'est pas compliqué en même temps :)
Je mets de coté les création sheet et le transaction, vu que c'est grandement orienté "monnaie" alors que ce n'est pas le sujet de PGPID.
Par contre, soit j'ai loupé un truc dans OpenUDC soit c'est vous qui avez mal compris l'idée de PGPID, mais en tous cas il y a une incompréhension. Je ne vois absolument pas en quoi OpenUDC fait déjà PGPID (comme le laisse sous-entendre Galuel).
PGPID cherche à répondre à la question suivante :
"J'ai une clé publique appartenant à un utilisateur, j'aimerai accéder au service ****(mail, chat, blog, microblogging, serveur de fichiers) associé a cet utilisateur. Où est la machine qui fournie ce service ?"
Pour OpenUDC, la question pourrait être (bon c'est pas très adapté à OpenUDC vu comment la communauté se crée mais c'est pour l'idée) :
"J'ai une clé publique appartenant à un utilisateur, j'aimerai savoir à quelles communautés OpenUDC il appartient et quel serveur gère cette communauté"
Dans OpenUDC, je vois pas où cette information serait présente (je vois même pas pourquoi elle serait présente vu pourquoi OpenUDC est prévu).
Vous avez des idées très intéressantes (typiquement les deux liens que tu pointes) et on pourrait les récupérer pour ce qui est des spécifications et sécurisations des échanges dans PGPID. Mais après, d'un point de vue fonctionnel, j'ai l'impression que OpenUDC et PGPID n'ont pas grand chose en commun.
Je vois même pas comment OpenUDC pourrait se baser sur PGPID.
En tout cas je continuerai de vous suivre et si je trouve un peu de temps vous risquez de me voir débarquer :)
Pour complexifié un mot de passe, on peut ajouter un fichier "mot de passe". En gros, le fichier qui peut être n'importe quoi générer par l'utilisateur, et donc plus discret qu'une clef privé, est hashé avec la passe phrase. Cela rajoute un paquet d'entropie au mot de passe.
Je suis d'accord, mais il faut faire attention à pas trop complexifier la chose. Si un utilisateur doit stocker sa clé privée et en plus un passfile ça commence à faire beaucoup (voir trop)
Concernant le vol d'identité, il suffit que la clef secondaire soit planqué ailleurs, et signé par la 1er clef. Mais il faut une date de cette signature pour éviter que la clef volée permette de générer une autre clé secondaire.
C'est pour ça que j’émettais l'idée de ne pas pouvoir changer la clé secondaire associée à la primaire.
Le problème du découpage en morceau est dans le protocole pour récupérer les morceaux: comment les gens de confiance peuvent vérifier que celui qui fait la demande est légitime ?
Par gens de confiance, je pensais à parents, amis, collègues. Des gens qui nous connaissent personnellement et physiquement. Des gens à qui on file une clé usb en leur demandant de la garder précieusement au fond d'un tiroir.
Pour répondre à ton autre commentaire, c'est le but d'avoir N morceaux avec seulement K (K<N) qui soient nécessaires pour refaire la clé.
Si tes amis sont partis en vacances ou que tu t'es fâchés avec eux, tant que t'en a encore K tu t'en sort.
(en écrivant ces lignes, je me rend compte que c'est peut être un peu trop complexe. Je vois mal madame Michu acheter N clés usb, y copier N fichiers dedans après les avoir chiffré avec la clé publique des destinataires pour enfin les filer à ses amis du club de bridge)
Attention à la révocation, les protocoles sont très lourd à mettre en œuvre.
Bien d'accord, mais je pense que ça peut être simplifier avec de bon outils. Si l'outil te génère automatiquement t'as clé secondaire et le certificat de révocation quand tu génères ta clé primaire, révoquer une clé peut se résumer à cliquer sur un bouton. (la plomberie derrière restant complexe)
Je suis d'accord que la sécurité de la clé privé est la clé (sans mauvais jeu de mots). Mais en quoi ce serait plus "dangereux" que maintenant ?
En quoi mettre ta clé dans ton téléphone la rend plus vulnérable que la mettre sur ton pc ?
Qui plus est, c'est toujours plus sure que le mode actuel où tu n'as qu'un mdp pour accéder à ton compte. Pour accéder à ta clé privée et ta passphrase, un attaquant doit rentrer dans ton système. Si il y arrive, les mdp classiques sont morts eux aussi. Et avec les mdp classiques tu as plus de vecteur d'attaque: le serveur, men in the middle, …
Quelles solutions envisager ? un mot de passe est il suffisant ?
La possibilité de révoquer une clé puis de lier une nouvelle paire de clés à une identité existante offre une solution en cas de clé compromise.
Il y a deux cas:
Soit tu t'es fait voler ta clé privée et la passphrase.
Soit tu as perdu ta clé ou ta passphrase, mais il n'y a pas de compromission.
Dans le premier cas, tu n'as pas le choix, il faut révoquer ta clé. Le mieux serait que tu puisses avoir une deuxième clé qui prenne le relais.
Dans le deuxième cas, il faut soit pouvoir la régénérer (sans qu'un attaquant puisse le faire) soit revenir au premier cas (révoquation+seconde clé)
Conclusion: je suis d'accord avec ta dernière phrase :) On pourrai imaginer un système de ce genre:
Lors de la création de la clé (primaire), une seconde clé de secours (secondaire) est générée.
Cette clé secondaire est signée avec la clé primaire.
La clé secondaire est "ajoutée" dans la clé primaire comme clé de secours.
La clé secondaire est découpée en N morceaux. On garde les morceaux, la clé secondaire en elle même est supprimée
L'utilisateur file les morceaux à des gens de confiance, éventuellement en les chiffrant avec leurs clés (pas avec la primaire)
Une fois les morceaux distribués, il les supprime de son pc.
En cas de perte de la clé, il suffit de récupérer K morceaux pour générer la clé secondaire et révoquer la clé primaire. À ce moment on repart pour un cycle (la clé secondaire passe primaire et on recrée un secondaire)
En cas de vol, c'est pareil, on révoque la clé primaire et on passe à la secondaire. Si on interdit la modification de l'association primaire->secondaire, même si un attaquant récupère les infos sur la clé primaire, il ne peut pas avoir la clé secondaire.
C'est un peu la contrepartie à vouloir se passer d'un fournisseur d'identité. Si tu pers ton identité, il y a personne pour te la redonner.
Une solution serait la reconstruction de clé (http://download.pgp.com/pdfs/PGPKeyRecon.pdf). L'idée est de «couper» ta clé privée en N morceaux (chacun protégés par un mdp) de façon que K (K<=N) morceaux soit suffisant pour reconstruire ta clé.
Tu files les morceaux à N gens de confiance. Le jour où tu perds ta clé, t'en contacte K et tu recrée ta clé (si tu te souviens des K mdp)
Par contre l'idée de Bitmessage me plait moyen…(en tout cas comme tu le présentes). Si il suffit d'une passphrase pour recréer une clé, toute ta sécurité ne tient qu'a cette passphrase. Si qqun la trouve il prend ton identité. Pire que ça tu n'as plus aucun moyen de l'en empêcher sauf à révoquer la clé (et ainsi perdre ton identité).
Après je suis d'accord il faut encore retrouver la passphrase. Mais quand on connait la tête de la plupart des mdp, je ne parierais pas sur un système de ce genre à grand échelle.
Oui, c'est sur, il y a des trucs à récupérer, mais pas tout, loin de là.
libretroshare est très complète et orientée Retroshare. Elle comprend notamment toutes leurs fonctionnalités d'échange de fichiers, turtle, cache et compagnie. L'idée de PGPID est justement de reprendre une toute petite partie de RetroShare et de la sortir du projet pour la rendre «application agnostique»
(ne vous inquiétez pas, j'en parlerait avec eux avant de leur piquer du code :) . Par respect et aussi parce qu'ils peuvent être plein de bonnes idées)
La RFC6091 et MonkeyShere sont des projets qui ont pour but d'utiliser PGP pour établir des connections sécurisé (TLS et SSH respectivement)
Il n'ont pas grand chose à voir avec le concept de PGPID à part qu'ils sont tout les trois basé sur PGP.
Par contre, il sont extrêmement complémentaires dans le sens où une même clé PGP serait utilisée comme base pour identification et la sécurisation des échanges.
En même temps, comment veux tu nommer et différencier des composants différents ?
Et puis bon, dans l'informatique, il y a quand même vachement d'acronymes, on en mange pas mal à toute les sauces sans que ça ait l'air de déranger beaucoup de monde.
Ensuite, évidemment que je doit ignorer pas mal de truc, c'est un peu pour ça que je fait un journal :)
Je vois pas pourquoi tu parle de DNS, justement PGPID ne l'utilise pas, il le remplace.
Je suis d'accord. C'est en fait le noeud de problème qui m'a fait penser à PGPID. Il y a énormément de projets "applicatifs" mais aucun ne se situant "que" au niveau identification/authentification/localisation. Il y a beaucoup de bonnes idées de partout mais il y a quasiment de rien de compatible. Le plus proche d'une solution globale, c'est xmpp. Mais comme dit précédemment, c'est dépendant d'un nom de domaine, donc d'un fournisseur d'identité.
Faire une spec
Clairement !! Le mieux serait carrément une RFC.
Pour ce qui est du python, je ne peut qu'être d'accord. C'est un proto et python est bien pour ça. À terme, c'est une norme qu'il faut. J'envisage aussi une lib bas niveau en C. Après, chaque langage se fait son wrapping comme il a envie.
Tester/Déployer et Structurer
Bien d'accord.
T'es calé en DHT, c'est bien. Car moi, si je devais me donner une étiquette, ça serait plutôt expert en performance graphique dans l'embarqué. J'ai lu pas mal de chose sur le net et les DHT. Je suis loin d'être idiot et je comprend bien ce qu'il y a derrière mais je manque clairement de background sur comment procéder et gérer un projet de ce genre.
Tu loupes quand même dans ton résumé une grosse partie du sujet qui est la localisation des machines (à coup de requêtes sur les NDN/SPN).
Et puis tout les points que tu as retenu sont dans mon introduction, ça me ferait mal d'admettre que j'aurai pu m'arrêter à l'introduction (même si c'est peut être vrai…)
Et effectivement, c'est bien un clé de chiffrement asymétrique. J'ai corrigé beaucoup de fautes avant de publier mais celle-ci est passée au travers.
J'ai lu ton papier sur pepr. C'est intéressant. Mais d'un point de vue technique ça se place au dessus de PGPID. Pepr pourrait utiliser PGPID pour identifier les utilisateurs et adresser les machines associées (d'ailleurs, ta section "address" se résume à un gros TODO).
Pourquoi ne pas passer sur GnuNet ? Parce que d'après GnuNet eux-mêmes c'est : "A first service implemented on top of the networking layer allows anonymous censorship-resistant file-sharing".
À première vue :
"anonymous" : ça va pas trop avec "tout est signé par des clés PGP"
"censorship-resistant file-sharing" : C'est pas vraiment le sujet de PGPID. Le file-sharing c'est les applications/services qui se base au dessus de PGPID.
Pour maidsafe, je connaissais pas, ça a l'air intéressant. Il à fallut que je cherche un peu pour savoir ce qu'il y avait derrière (https://github.com/maidsafe/MaidSafe/wiki "maidSafe parers" sur la gauche) mais ça semble relativement proche de PGPID. Je vais regarder.
Si je suis d'accord avec le principe de "mesurer avant d'optimiser", il ne faut pas le suivre bêtement au point de ne pas réfléchir sous prétexte qu'on verra plus tard.
Ce principe s'applique très bien (et quasiment sans exception) lorsque tu es sur un projet «terminé». Si, à ce moment, tu changes une fonction parce que ton pif te dit que c'est là, effectivement, tu as tord.
Par contre au moment où tu écris ton code, si tu ne te pose pas de question sur la structure de donnée à utiliser, tu va vite voir que pour optimiser derrière, ben t'en sera quasiment à tout réécrire par ta structure est pas adaptée, que c'est elle qui faut changer (et donc tous les algo qui vont avec).
Alors qui si te pose la question des perfs en amont, tu choisie la bonne structure de donnée, la bonne organisation "globale" de ton code. (genre pas faire trois fois le même tri). Lorsque tu vas faire tes mesures, tu verras que les changements à faire seront probablement plus chirurgicales et tu t'éviteras de longue nuit de rush parce que "les perfs c'est à la fin quand tout marche qu'on y pense".
Comme quoi la vie ne tient pas à grand chose. Pour suivre le projet Fedora je peux vous dire que Seth Vidal était un contributeur actif. La communauté perd quelqu'un et pas un petit… :/
Mettre / sur la clé c'est probablement pas une bonne idée. Par contre, y mettre /usr ça doit le faire vu que c'est censé être majoritairement du read only.
Mettre du code dans les outils de compilation qui :
- Si il compile un compilateur => insère ce même code (alors que le source est clean).
- Si il compile un outil d'analyse de code (gdb) => insère du code qui cache les modifs à l’exécution de cet outil.
- Si il compile un programme particulier => insère un backdoor.
Parce que l'euthanasie, c'est quand même tuer des innocents. Donc est-ce que tu compares ceux qui sont pour à des psychopathes ?
Après je suis d'accord, l'euthanasie et le meurtre sont difficilement comparable. Je m'en servais juste à titre d'exemple.
De manière plus générale, il y a probablement de nombreux cas (à travers les régions et les âges) où tuer des innocents n'est pas forcement contre "la morale" (des gens, du coin et du moment). Sont ils des psychopathes ?
# Duck typing et implementation
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 5.
En dehors de l'implémentation (dont je parlerai dans la deuxième partie du commentaire), le système d'entités me fait grandement penser au duck typing que l'on retrouve dans d'autres langages (notamment python):
Si une entité a des ailes alors c'est une entité volante.
Si un objet a des plumes et fait "coin coin" alors c'est un canard.
C'est très similaire comme approche.
Et sans aller jusqu'au système d'entité ou le duck typing (on en est même loin), il y a déjà des "avancés" dans ce sens dans les langages objet "classiques" avec les interfaces et les templates.
Tu parles d'optimisation en "linéarisant" les composants dans un tableau et ainsi en améliorer l'accès en utilisant les systèmes de cache. Je suis d'accord avec toi sur le principe mais, désolé, je ne le vois pas dans ton implémentation.
(je me base sur ton implémentation de la lib et du tutoriel des balles rebondissantes)
Dans la lib, le Store stocke les Component dans une map (std::map).
- Je ne sais pas ce qu'il en est avec la norme du C++11 mais à ma connaissance rien ne garantie que les données d'une map soient stockées de manière linaire.
- Si c'était le cas, te ne stockes pas un Component mais un pointeur. Et comme dans ton tuto tu alloues les composants à coup de new en alternant les différents types de composant, il y a très peu de chance que les composants d'un même type soit alignés.
- Si c'était le cas, le système ne parcoure pas dans l'ordre des composants mais dans celui des entités. Pour un exemple simple, il se peut que le parcours des composants se fasse dans l'ordre, mais dans un cas concret avec surpression/ajout d'entités, il y a de fortes chances que ça soit pas le cas. Qui plus est, ça casse quand même le cache vu que tu recharges ton conteneur des entités pour passer à la suivante.
La critique est facile, l'art est difficile. Alors je vais tenter de te proposer des axes d'améliorations :
Juste une réflexion (je sais pas où ça mène ou si c'est utile mais j'ai envie de le dire :-) ) :
On peut voir le système d'entités/composants comme un système qui associe à un même nom (l'entité) différentes valeurs (les composants) selon "l'espace" dans lequel on regarde (les types des composants). La map dans ton Store (ou le deuxième vecteur dans ma proposition d'implémentation) étant le traducteur entre l'espace commun et les espaces spécifiques.
Enfin, je critique mais c'est quand même une petite lib sympa que fait le boulot qui lui est demandée. Qui plus est le code est propre et il y a de la doc. (Et vu le code de merde que je suis obligé de lire en ce moment, ça fait vraiment du bien :-) ) J'attends la suite avec impatience.
Matthieu Gautier|irc:starmad
[^] # Re: Le manque de pertinence est du a duckduckgo ou aux mots clefs ?
Posté par GaMa (site web personnel) . En réponse au journal DuckDuckSux?. Évalué à 1.
En mettant Terjan entre double guillemets ("Terjan"), je n'ai plus de résultat pour tarzan.
Matthieu Gautier|irc:starmad
[^] # Re: Lightworks
Posté par GaMa (site web personnel) . En réponse à la dépêche Kino, c'est fini. Vive Kino ?. Évalué à 4.
Tu veux dire GNU D ?
Matthieu Gautier|irc:starmad
[^] # Re: Déception
Posté par GaMa (site web personnel) . En réponse à la dépêche 23 de Firefox. Évalué à 4.
Oui, sauf que c'est plus de l'ergonomie. La conception d'interface utilisateur, c'est faire des trucs utilisables. Si l'utilisateur se perd dans tes menus ou se pose des questions sur le but d'un bouton, c'est que ton interface est à revoir. Point (pour ce qui est de l'ergonomie).
Ce commentaire ne porte pas particulièrement sur l'interface de Firefox. Mais j'aime bien rappeler au vieux barbus que nous sommes ce qu' est l'ergonomie.
RTFM et "si tu c'est pas ce que c'est n'y touche pas" ce n'est pas de l'ergonomie. Ça peut être une bonne chose selon le context, mais ce n'est pas le l'ergo.
L'ergonomie c'est : "Si c'est pas utilisé : vire le", "Si c'est utilisé par 1% des gens, ne le met pas avec les options utilisées par 99% des gens". Ça nous fait peut-être chier quand on fait parti des 1%, mais c'est comme ça qu'il faut faire.
Matthieu Gautier|irc:starmad
[^] # Re: Déception
Posté par GaMa (site web personnel) . En réponse à la dépêche 23 de Firefox. Évalué à 10.
T'es en train de dire que tu actives/désactive javascript plusieurs fois par ??? lorsque tu navigues d'une page à l'autre en fonction de tes besoins ?
Genre:
Ce genre d'option c'est sensé être du "configure once" et c'est grandement orienté utilisateur avancé. Elle a totalement sa place dans about:config
Si tu actives/désactives régulièrement javascript, about:config ou menu, même combat : c'est une plait à utiliser…
Matthieu Gautier|irc:starmad
[^] # Re: No free lunch
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 1.
Je ne connaissait pas le texte "For a truly acentric Internet". Il est totalement dans la même idée que PGPID.
Je pense qu'il y a un gros travail d'étude de l'existant à faire et contacter tout les projets qui pourraient être intéressés par PGPID. Si on arrive à fédérer suffisamment de projet, on peut arriver à quelque chose. Ça doit même être nécessaire si on veut que ça marche.
Les points qui me posent problème avec les noms parlants:
Si ta clé PGP est publiée, n'importe quel outils qui veut afficher des clés peut aussi afficher le nom associé.
La plupart du temps on clique, copie/colle les adresses mail ou web. Peu de gens les tapes au clavier. Ça serait pareil avec PGPID.
Matthieu Gautier|irc:starmad
[^] # Re: Il existe déjà quelque chose de beaucoup plus simple pour le même besoin
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 1.
Bon, je viens de me pencher sur OpenUDC. C'est très intéressant, surtout avec la présentation audio (faites où?). Ça aurait été mieux avec la vidéo pour voir ce que tu affiches mais ça aide pas mal à avoir une idée globale.
C'est clair que vous êtes pas mal en avance sur moi. C'est pas compliqué en même temps :)
Je mets de coté les création sheet et le transaction, vu que c'est grandement orienté "monnaie" alors que ce n'est pas le sujet de PGPID.
Par contre, soit j'ai loupé un truc dans OpenUDC soit c'est vous qui avez mal compris l'idée de PGPID, mais en tous cas il y a une incompréhension. Je ne vois absolument pas en quoi OpenUDC fait déjà PGPID (comme le laisse sous-entendre Galuel).
PGPID cherche à répondre à la question suivante :
"J'ai une clé publique appartenant à un utilisateur, j'aimerai accéder au service ****(mail, chat, blog, microblogging, serveur de fichiers) associé a cet utilisateur. Où est la machine qui fournie ce service ?"
Pour OpenUDC, la question pourrait être (bon c'est pas très adapté à OpenUDC vu comment la communauté se crée mais c'est pour l'idée) :
"J'ai une clé publique appartenant à un utilisateur, j'aimerai savoir à quelles communautés OpenUDC il appartient et quel serveur gère cette communauté"
Dans OpenUDC, je vois pas où cette information serait présente (je vois même pas pourquoi elle serait présente vu pourquoi OpenUDC est prévu).
Vous avez des idées très intéressantes (typiquement les deux liens que tu pointes) et on pourrait les récupérer pour ce qui est des spécifications et sécurisations des échanges dans PGPID. Mais après, d'un point de vue fonctionnel, j'ai l'impression que OpenUDC et PGPID n'ont pas grand chose en commun.
Je vois même pas comment OpenUDC pourrait se baser sur PGPID.
En tout cas je continuerai de vous suivre et si je trouve un peu de temps vous risquez de me voir débarquer :)
Matthieu Gautier|irc:starmad
[^] # Re: Une fois la clé perdue ?
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 1.
Je suis d'accord, mais il faut faire attention à pas trop complexifier la chose. Si un utilisateur doit stocker sa clé privée et en plus un passfile ça commence à faire beaucoup (voir trop)
C'est pour ça que j’émettais l'idée de ne pas pouvoir changer la clé secondaire associée à la primaire.
Par gens de confiance, je pensais à parents, amis, collègues. Des gens qui nous connaissent personnellement et physiquement. Des gens à qui on file une clé usb en leur demandant de la garder précieusement au fond d'un tiroir.
Pour répondre à ton autre commentaire, c'est le but d'avoir N morceaux avec seulement K (K<N) qui soient nécessaires pour refaire la clé.
Si tes amis sont partis en vacances ou que tu t'es fâchés avec eux, tant que t'en a encore K tu t'en sort.
(en écrivant ces lignes, je me rend compte que c'est peut être un peu trop complexe. Je vois mal madame Michu acheter N clés usb, y copier N fichiers dedans après les avoir chiffré avec la clé publique des destinataires pour enfin les filer à ses amis du club de bridge)
Bien d'accord, mais je pense que ça peut être simplifier avec de bon outils. Si l'outil te génère automatiquement t'as clé secondaire et le certificat de révocation quand tu génères ta clé primaire, révoquer une clé peut se résumer à cliquer sur un bouton. (la plomberie derrière restant complexe)
Matthieu Gautier|irc:starmad
[^] # Re: Une fois la clé perdue ?
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 1.
Rhaa, c'est tellement gros que j'y ai même pas pensé…
Dans ce cas, une solution comme celle décrite dans mon commentaire devrait être suffisante.
Matthieu Gautier|irc:starmad
[^] # Re: Une fois la clé perdue ?
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 3. Dernière modification le 23 juillet 2013 à 22:40.
Je suis d'accord que la sécurité de la clé privé est la clé (sans mauvais jeu de mots). Mais en quoi ce serait plus "dangereux" que maintenant ?
En quoi mettre ta clé dans ton téléphone la rend plus vulnérable que la mettre sur ton pc ?
Qui plus est, c'est toujours plus sure que le mode actuel où tu n'as qu'un mdp pour accéder à ton compte. Pour accéder à ta clé privée et ta passphrase, un attaquant doit rentrer dans ton système. Si il y arrive, les mdp classiques sont morts eux aussi. Et avec les mdp classiques tu as plus de vecteur d'attaque: le serveur, men in the middle, …
Il y a deux cas:
Dans le premier cas, tu n'as pas le choix, il faut révoquer ta clé. Le mieux serait que tu puisses avoir une deuxième clé qui prenne le relais.
Dans le deuxième cas, il faut soit pouvoir la régénérer (sans qu'un attaquant puisse le faire) soit revenir au premier cas (révoquation+seconde clé)
Conclusion: je suis d'accord avec ta dernière phrase :) On pourrai imaginer un système de ce genre:
En cas de perte de la clé, il suffit de récupérer K morceaux pour générer la clé secondaire et révoquer la clé primaire. À ce moment on repart pour un cycle (la clé secondaire passe primaire et on recrée un secondaire)
En cas de vol, c'est pareil, on révoque la clé primaire et on passe à la secondaire. Si on interdit la modification de l'association primaire->secondaire, même si un attaquant récupère les infos sur la clé primaire, il ne peut pas avoir la clé secondaire.
Matthieu Gautier|irc:starmad
[^] # Re: Une fois la clé perdue ?
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 1.
Tu soulèves un point intéressant.
C'est un peu la contrepartie à vouloir se passer d'un fournisseur d'identité. Si tu pers ton identité, il y a personne pour te la redonner.
Une solution serait la reconstruction de clé (http://download.pgp.com/pdfs/PGPKeyRecon.pdf). L'idée est de «couper» ta clé privée en N morceaux (chacun protégés par un mdp) de façon que K (K<=N) morceaux soit suffisant pour reconstruire ta clé.
Tu files les morceaux à N gens de confiance. Le jour où tu perds ta clé, t'en contacte K et tu recrée ta clé (si tu te souviens des K mdp)
Par contre l'idée de Bitmessage me plait moyen…(en tout cas comme tu le présentes). Si il suffit d'une passphrase pour recréer une clé, toute ta sécurité ne tient qu'a cette passphrase. Si qqun la trouve il prend ton identité. Pire que ça tu n'as plus aucun moyen de l'en empêcher sauf à révoquer la clé (et ainsi perdre ton identité).
Après je suis d'accord il faut encore retrouver la passphrase. Mais quand on connait la tête de la plupart des mdp, je ne parierais pas sur un système de ce genre à grand échelle.
Matthieu Gautier|irc:starmad
[^] # Re: Retroshare?
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 2.
Oui, c'est sur, il y a des trucs à récupérer, mais pas tout, loin de là.
libretroshare est très complète et orientée Retroshare. Elle comprend notamment toutes leurs fonctionnalités d'échange de fichiers, turtle, cache et compagnie. L'idée de PGPID est justement de reprendre une toute petite partie de RetroShare et de la sortir du projet pour la rendre «application agnostique»
(ne vous inquiétez pas, j'en parlerait avec eux avant de leur piquer du code :) . Par respect et aussi parce qu'ils peuvent être plein de bonnes idées)
Matthieu Gautier|irc:starmad
[^] # Re: Il existe déjà quelque chose de beaucoup plus simple pour le même besoin
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 3.
J'aurai du lire les liens avant de répondre:
La RFC6091 et MonkeyShere sont des projets qui ont pour but d'utiliser PGP pour établir des connections sécurisé (TLS et SSH respectivement)
Il n'ont pas grand chose à voir avec le concept de PGPID à part qu'ils sont tout les trois basé sur PGP.
Par contre, il sont extrêmement complémentaires dans le sens où une même clé PGP serait utilisée comme base pour identification et la sécurisation des échanges.
Matthieu Gautier|irc:starmad
[^] # Re: Il existe déjà quelque chose de beaucoup plus simple pour le même besoin
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 2.
En même temps, comment veux tu nommer et différencier des composants différents ?
Et puis bon, dans l'informatique, il y a quand même vachement d'acronymes, on en mange pas mal à toute les sauces sans que ça ait l'air de déranger beaucoup de monde.
Ensuite, évidemment que je doit ignorer pas mal de truc, c'est un peu pour ça que je fait un journal :)
Je vois pas pourquoi tu parle de DNS, justement PGPID ne l'utilise pas, il le remplace.
Matthieu Gautier|irc:starmad
[^] # Re: Parlons projet alors !
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 1.
Faire un état de l'art (collaboratif ?)
Je suis d'accord. C'est en fait le noeud de problème qui m'a fait penser à PGPID. Il y a énormément de projets "applicatifs" mais aucun ne se situant "que" au niveau identification/authentification/localisation. Il y a beaucoup de bonnes idées de partout mais il y a quasiment de rien de compatible. Le plus proche d'une solution globale, c'est xmpp. Mais comme dit précédemment, c'est dépendant d'un nom de domaine, donc d'un fournisseur d'identité.
Faire une spec
Clairement !! Le mieux serait carrément une RFC.
Pour ce qui est du python, je ne peut qu'être d'accord. C'est un proto et python est bien pour ça. À terme, c'est une norme qu'il faut. J'envisage aussi une lib bas niveau en C. Après, chaque langage se fait son wrapping comme il a envie.
Tester/Déployer et Structurer
Bien d'accord.
T'es calé en DHT, c'est bien. Car moi, si je devais me donner une étiquette, ça serait plutôt expert en performance graphique dans l'embarqué. J'ai lu pas mal de chose sur le net et les DHT. Je suis loin d'être idiot et je comprend bien ce qu'il y a derrière mais je manque clairement de background sur comment procéder et gérer un projet de ce genre.
Matthieu Gautier|irc:starmad
[^] # Re: En résumé & en image
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 3.
Ouai, je sais c'est long :) Merci pour le résumé.
Tu loupes quand même dans ton résumé une grosse partie du sujet qui est la localisation des machines (à coup de requêtes sur les NDN/SPN).
Et puis tout les points que tu as retenu sont dans mon introduction, ça me ferait mal d'admettre que j'aurai pu m'arrêter à l'introduction (même si c'est peut être vrai…)
Et effectivement, c'est bien un clé de chiffrement asymétrique. J'ai corrigé beaucoup de fautes avant de publier mais celle-ci est passée au travers.
Matthieu Gautier|irc:starmad
[^] # Re: marrant...
Posté par GaMa (site web personnel) . En réponse au journal Présentation d'idée : PGPID. Évalué à 5.
J'ai lu ton papier sur pepr. C'est intéressant. Mais d'un point de vue technique ça se place au dessus de PGPID. Pepr pourrait utiliser PGPID pour identifier les utilisateurs et adresser les machines associées (d'ailleurs, ta section "address" se résume à un gros TODO).
Pourquoi ne pas passer sur GnuNet ? Parce que d'après GnuNet eux-mêmes c'est : "A first service implemented on top of the networking layer allows anonymous censorship-resistant file-sharing".
À première vue :
Pour maidsafe, je connaissais pas, ça a l'air intéressant. Il à fallut que je cherche un peu pour savoir ce qu'il y avait derrière (https://github.com/maidsafe/MaidSafe/wiki "maidSafe parers" sur la gauche) mais ça semble relativement proche de PGPID. Je vais regarder.
Matthieu Gautier|irc:starmad
# Constructeur sans argument
Posté par GaMa (site web personnel) . En réponse au message [RESOLU] Constructeur par défaut et méthodes de classe. Évalué à 9.
Il y a une ambigüité dans la syntaxe du C++.
"Pouf chien();" peut être analysé comme:
La norme définie donc que l’ambigüité soit toujours résolue en prenant la deuxième solution.
Ne pas utiliser de parenthèse dans ce contexte (pas d'argument) permet de lever l’ambigüité.
Il faut donc mettre
Matthieu Gautier|irc:starmad
[^] # Re: quelques points
Posté par GaMa (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Si je suis d'accord avec le principe de "mesurer avant d'optimiser", il ne faut pas le suivre bêtement au point de ne pas réfléchir sous prétexte qu'on verra plus tard.
Ce principe s'applique très bien (et quasiment sans exception) lorsque tu es sur un projet «terminé». Si, à ce moment, tu changes une fonction parce que ton pif te dit que c'est là, effectivement, tu as tord.
Par contre au moment où tu écris ton code, si tu ne te pose pas de question sur la structure de donnée à utiliser, tu va vite voir que pour optimiser derrière, ben t'en sera quasiment à tout réécrire par ta structure est pas adaptée, que c'est elle qui faut changer (et donc tous les algo qui vont avec).
Alors qui si te pose la question des perfs en amont, tu choisie la bonne structure de donnée, la bonne organisation "globale" de ton code. (genre pas faire trois fois le même tri). Lorsque tu vas faire tes mesures, tu verras que les changements à faire seront probablement plus chirurgicales et tu t'éviteras de longue nuit de rush parce que "les perfs c'est à la fin quand tout marche qu'on y pense".
Matthieu Gautier|irc:starmad
[^] # Re: C'est vendredi, c'est permis, je saute dedans à pieds joints.
Posté par GaMa (site web personnel) . En réponse au journal Yum est orphelin. Évalué à 10.
D'autant plus que Fedora est en train de transiter sur DNF (http://fedoraproject.org/wiki/Features/DNF) en remplacement de YUM.
Comme quoi la vie ne tient pas à grand chose. Pour suivre le projet Fedora je peux vous dire que Seth Vidal était un contributeur actif. La communauté perd quelqu'un et pas un petit… :/
Matthieu Gautier|irc:starmad
[^] # Re: Facile
Posté par GaMa (site web personnel) . En réponse au message Question théorique sur les clefs USB. Évalué à 4.
Mettre / sur la clé c'est probablement pas une bonne idée. Par contre, y mettre /usr ça doit le faire vu que c'est censé être majoritairement du read only.
Matthieu Gautier|irc:starmad
[^] # Re: Bof
Posté par GaMa (site web personnel) . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Tu parles du hack de Ken Thompson ? http://c2.com/cgi/wiki?TheKenThompsonHack
Mettre du code dans les outils de compilation qui :
- Si il compile un compilateur => insère ce même code (alors que le source est clean).
- Si il compile un outil d'analyse de code (gdb) => insère du code qui cache les modifs à l’exécution de cet outil.
- Si il compile un programme particulier => insère un backdoor.
Matthieu Gautier|irc:starmad
# Le lien qui fait du bien
Posté par GaMa (site web personnel) . En réponse au journal Les murguettes en deuil. Évalué à 9. Dernière modification le 08 juillet 2013 à 10:33.
En 1968, Douglas Engelbart fit une démo qui est communément appelée : "Mother of all demos".
Il y présente beaucoup de choses (la souris, l'éditeur de text, l'hyperlien, le mail, le travail colaboratif, …)
http://sloan.stanford.edu/MouseSite/1968Demo.html
edit: grillé :)
Matthieu Gautier|irc:starmad
[^] # Re: ONUiser google ?
Posté par GaMa (site web personnel) . En réponse au journal Google veut réduire la latence sur Internet avec QUIC. Évalué à 1.
Parce que l'euthanasie, c'est quand même tuer des innocents. Donc est-ce que tu compares ceux qui sont pour à des psychopathes ?
Après je suis d'accord, l'euthanasie et le meurtre sont difficilement comparable. Je m'en servais juste à titre d'exemple.
De manière plus générale, il y a probablement de nombreux cas (à travers les régions et les âges) où tuer des innocents n'est pas forcement contre "la morale" (des gens, du coin et du moment). Sont ils des psychopathes ?
Matthieu Gautier|irc:starmad
[^] # Re: ONUiser google ?
Posté par GaMa (site web personnel) . En réponse au journal Google veut réduire la latence sur Internet avec QUIC. Évalué à 1.
Que penses tu de l’euthanasie ? Que penses tu de ceux qui considèrent l'euthanasie comme une bonne chose ?
Matthieu Gautier|irc:starmad