rakoo a écrit 934 commentaires

C'est vrai, Go n'est pas adapté aux plateformes limitées en mémoire. C'est pourquoi j'ai prévu de garder le protocole simple pour qu'il puisse être ré-implémenté par d'autres si nécessaire (et puis ça me donnera une excuse pour essayer de nouveaux langages, comme ça).

Non, une religion, c'est une secte dont le gourou est mort sans laisser de note rappelant que c'était des bobards.

Comme Couchdb.

Chaque fois qu'une modification est enregistrée, je lui associe une révision de la forme

    <counter>-<hash>

où counter est un compteur incrémental, et hash est un hash sha1.

Le compteur permet d'avoir un ordre dans les mises à jour; si j'en suis à la version 6 et qu'un changement sur le disque est enregistré, je passe à la révision 7 et j'update le hash (on verra après comment).

Maintenant on passe du côté du receveur: je reçois un message qui me dit Nouvelle version: 7. Si j'en suis déjà plus loin, je rejette. Sinon je prends la nouvelle version après avoir vérifié la signature.

Là où ça se gâte c'est si je suis déjà à la version 7. Dans ce cas je vérifie le hash.
Celui-ci est calculé à chaque révision à partir de la révision précédente et de l'infohash de la version courante. L'idée est que ce hash identifie de manière unique l'historique de l'échange. Du coup, si le hash que je reçois est le même que celui que j'ai, je suis totalement sûr qu'il n'y a pas eu de conflits puisque l'historique est le même; si les hash diffèrent alors j'ai un conflit. Dans ce cas-là ce qui est prévu (et pas encore présent) est de stocker les différentes versions en parallèle, avoir un indice suffisamment compréhensible pour que l'utilisateur voie qu'il y a un conflit:

    $ ls

    fichier1
    fichier1.conflict.123xyz
    fichier1.conflict.456abc

le résolve (ça ne devrait pas être plus compliqué que ça):

    $ mv fichier1.conflict.123xyz fichier1
    $ rm fichier1.conflict.456abc

après quoi rakoshare devra considérer la version gagnante pour ses futurs échanges.

Note que si j'en reçois 2 messages comportant le même compteur mais deux hash différents en même temps, il y en a un que je traiterai avant l'autre puisque je ne traite pas les choses en parallèle, donc on retombe dans le cas précédent.

Pour faire court, rakoshare ne résoud pas les conflits, mais délègue ça à l'utilisateur pour qu'il s'en occupe, tout en éliminant les cas où on a l'assurance qu'il n'y a en fait pas de conflits.

A faire taire ou a mettre en avant ?

J'arrive plus a suivre, ça va trop vite.

stunnel c'est pour piper du flux réseau dans du TLS. J'ai pas envie d'avoir plusieurs dépendances et d'essayer tant bien que mal de piper l'un dans l'autre, avec tous les problèmes que ça a pour le déploiement, la portabilité…

Oh non, je m'imagine pas que les gens la maîtriseront. Ils seront juste un peu plus conscients de qu'est-ce que c'est, de comment ça marche et de qu'est-ce qu'il est normal que je puisse faire en l'utilisant. Il ne sera plus possible de les berner.

Par exemple, personne dans la génération "je sais ce qu'est Internet" n'accepterait de payer pour un internet de base puis payer site web par site web, protocole par protocole, pour un accès fixe; si une majorité de gens pense comme ça on peut exclure cette possibilité immonde. Par contre, ce genre de propositions pourrait arriver aujourd'hui, parce que les lois sont faites en majorité par des gens qui ne savent pas ce qu'est Internet, et l'associent encore à une bonne vieille télévision sur laquelle on a un bouquet de chaines.

Et il est déféni où le protocole

Dans ma tête :)

Si les commentaires m'ont bien montré une chose (merci à la communauté d'ailleurs) c'est que la documentation est vitale. Elle manque très clairement, je la remplirai au fur et à mesure de mes avancements.

Pour avoir une première idée, voilà comment ça marche:

• un data-plane qui se charge d'échanger les données elle-mêmes. C'est une bête session torrent tout ce qu'il y a de plus standard, à la différence que tous les pairs potentiels lui sont signalés de l'extérieur: pas de trackers, pas de DHT, pas de PEX, pas de LPD. Elle ne fait que transporter les octets
• un control-plane qui se charge d'échanger les messages indiquant la version courante du contenu: on en est à la version 7, l'infohash est 123xyz. Signé avec la bonne clé, que seuls ceux qui ont l'id kivabien ont (les autres peuvent envoyer ce qu'ils veulent, ça ne sera pas accepté). Une fois ce message reçu, on détruit la session courante dans le controle-plane et on en crée une nouvelle avec le nouveau torrent, si on n'est pas déjà dessus et que c'est une version plus récente que la nôtre, et on diffuse le message aux autres. Techniquement c'est également une session bittorrent, sauf que l'infohash est virtuel (il ne correspond à aucun contenu), elle ne transmet aucun contenu et introduit un nouveau type de message, merci la flexibilité de bittorrent!
• pour rentrer dans un partage, il faut connaitre un des bons ids. Ces ids permettent non seulement de connaitre les ips susceptibles d'être dans le partage, mais également la clé qui permet d'initier la connexion (il ne suffit pas de connaitre les ips pour accéder au contenu, même chiffré!).
• en parallèle on a une routine qui surveille le dossier partagé, et dès que le contenu change, le torrent est calculé et envoyé au control-plane pour partage et au data-plane pour dissémination.

Voilà en gros les choses. Mais une documentation reste nécessaire (et viendra!)

Pas d'inquiétude, il n'est nullement question de passer les échanges dans un pipe, je pensais plutôt réutiliser une bibliothèque existante.

En fait je me demandais si tout ce qui vient avec TLS était réellement nécessaire dans mon cas: gestion des authentifications, certificats avec tout le tintouin, négociation des algorithmes, renégociations de sessions, heartbeat, …

Du coup, plutôt qu'utiliser un système qui fait tout jusqu'au café, j'ai envisagé un protocole simple, robuste, écrit par quelqu'un qui s'y connait, mais qui malheureusement a vu beaucoup moins de recherche et d'implémentations.

Après, si mon choix se porte sur tls, je prendrai certainement la librairie standard

Je parle de ce dossier, que j'aurais certainement dû appeler répertoire si c'est le message derrière ton commentaire :)

Pas directement.

L'ID est fixe et généré aléatoirement. Il permet de garder une identité tout au long des échanges. Le hash du torrent est tout à fait standard. Il n'y a aucun moyen de dériver l'un à partir de l'autre, il faut nécessairement faire partie des échanges pour pouvoir faire le lien.

Il est possible de scraper les hashs publiés dans la DHT (ou sur les trackers, c'est possible aussi). Déjà, ces hashs sont dérivés des IDs de manière à être le plus stable possible. Mais ces hashs sont dérivés de l'ID, donc il est impossible de savoir de quoi on parle quand on récupère un de ces hashs (il ne sera même pas possible de stocker la version chiffrée du contenu; impossible de remonter). La seule information éventuellement disponible sera l'ensemble des ips qui font partie du swarm.

… c'est que ces conseils n'ont rien à voir avec Internet; ils ont à voir avec l'éducation, tout simplement. Internet permet juste de faire passer les messages plus facilement. Messages qui ont toujours existé et qui ne sont pas nés en même temps que les Ipés. Et pourtant, on dirait qu'Internet a créé tous les malheurs sur terre.

Je pense de plus en plus sérieusement qu'il va falloir éduquer les parents en plus des enfants, en tout cas jusqu'à ce que la génération de ceux qui ont grandi avec Internet soit la génération majoritaire.

Je suis désolé, la terminologie est un peu confuse, les détails ne sont pas encore là, mais voilà comment je vois les choses:

Le système est calqué sur les capabilities de Tahoe-LAFS: les utilisateurs ne se soucient que de ça. C'est une chaine de caractères, opaque pour l'utilisateur (ie il copie-colle sans se poser de questions), qui contient toutes les informations nécessaires; voici en gros ce qu'il y a pour Tahoe-LAFS:

• Est-ce que c'est un fichier ou un dossier
• Est-ce que c'est mutable ou pas
• Est-ce que j'ai le droit de modifier
• Où est-ce que c'est stocké
• Quelle est la somme de contrôle, de manière à ce que je puisse vérifier si le contenu est le bon

Du coup, pour qu'un utilisateur donne accès à une ressource à quelqu'un d'autre, il lui suffit de copier-coller cet id. C'est d'ailleurs pour ça qu'on l'appelle également capability: ça indique les autorisations de celui qui connait cet id.

Là où ça devient intéressant, c'est que tu peux dériver les capabilities: à partir d'une capability qui a les droits d'écrire, tu peux dériver une capability qui n'a que le droit de lire. Du coup si tu ne donnes que cette dernière, tu seras le seul à pouvoir modifier le contenu.

Encore une fois, ce qu'il faut retenir, c'est que l'utilisateur n'a pas à comprendre le contenu de cet id; il doit juste copier-coller le bon (celui qui donne le droit d'écrire, celui qui ne donne que le droit de lire, celui qui ne permet que de stocker la version chiffrée mais pas de lire le contenu en clair).

Après, ça veut dire que si tu colles cet id dans un email en clair qui passe chez Google, oui, Google aura les mêmes droits. Mais ça sera la même chose avec un login/mot de passe, et comme personne parmi les personnes visées n'utilise (voire connait) PGP, la sécurité n'est pas amoindrie. Disons que le point faible est dans la transmission de cette information de base, et ça sort du cadre de rakoshare. Je pars du principe que les utilisateurs sont un minimum conscients des personnes qui ont accès à ce qu'ils copient-collent dans une fenêtre de discussion ou un email.

Note: pour plus de détails sur comment marche Tahoe-LAFS, voir cette présentation. Tahoe-LAFS est vraiment bon, j'espère que des fournisseurs de stockage auront une offre compatible.

Tu veux certainement parler du tit-for-tat, qui est effectivement inutile dans notre cas: ça tombe bien, je ne l'implémente pas !

Mon calcul était plutôt de dire qu'il est plus facile d'adapter les innombrables bibliothèques bittorrent plutôt qu'inventer un protocole from scratch, et ainsi pouvoir réutiliser les infrastructures et surtout le travail existants.

Tout pareil: le concept de Bittorrent Sync est génial, dommage qu'il ne soit pas libre.

Est ce que ca fonctionne si les 2 ordis sont derrière un NAT?

Pas testé, mais si le NAT-PMP marche "ça devrait".

La solution que je vois est d'avoir une troisième machine qui fait tourner rakoshare et est accessible de l'extérieur. Techniquement cette troisième machine est un nœud tout à fait standard, mais en pratique elle va agir comme passerelle. Le but est qu'il n'y ait aucune configuration supplémentaire à faire, et qu'on ne s'embête pas avec ces bêtises de NAT.

Est ce qu'un chiffrement des données transitées (données, ID et clé d'accès au dossier partagée) est prévue à terme?

Il n'y aura pas de clé au sens où tu l'entends; je compte réutiliser ce qui a été fait pour tahoe-lafs, à savoir avoir une suite de caractères qui contient toutes les informations nécessaires (autorisations, clé de chiffrement/déchiffrement, …) et qui ne doit avoir aucune signification pour l'utilisateur: ça doit être totalement opaque.

Le chiffrement est prévu à 2 niveaux:

• Les échanges devront bien entendu être chiffrés. Les récentes nouvelles sur OpenSSL m'ont un peu refroidi sur l'utilisation de TLS, d'autant plus qu'il n'y aura pas besoin de toute sa complexité. Je pense utiliser spiped qui a l'avantage d'être compréhensible dans son intégralité sans y passer des années

• Les données elle-même devront être chiffrées indépendamment de l'échange. L'intérêt est de pouvoir envoyer les données à une machine tierce qui n'a pas les éléments nécessaires pour déchiffrer; cette machine tierce pourra agir comme passerelle (voir juste au-dessus) ou comme stockage longue durée (NAS, Dropbox, …). Bien sûr, encore une fois, rien de spécial à faire pour l'utilisateur si ce n'est choisir le bon id qui donne les bonnes capacités.

Comment penses tu faire pour rendre cela multiplateforme ?

Par 2 moyens:

• rakoshare est écrit en Go, et toutes les plateformes où rakoshare compile peuvent le faire tourner. Aujourd'hui, ça inclut DragonFly BSD, FreeBSD, Linux, NetBSD, OpenBSD, OS X (Darwin), Plan 9, Solaris et Windows; de quoi voir venir.

• Plus important encore, je compte garder le protocole simple et le documenter, pour que des implémentations alternatives puissent voir le jour.

tout le reste (branches, tags, etc.) est complètement superflu

J'ai dit reprendre les idées, pas réutiliser :)

Notamment, reprendre le modèle de donnés, qui permet de stocker des blobs de n'importe quel type (comme par exemple un torrent) et de les ordonner dans le temps. Tout le reste est du bricolage rendu possible parce que les fondations sont solides.

Tu utilises un torrent par dossier? Est-ce que ça va marcher sur une arborescence avec des milliers de dossiers?

Un torrent par dossier racine partagé; les sous-dossiers ne font pas pas partie d'un autre torrent (à moins que l'utilisateur ait explicitement choisi de le partager… ce qui n'est même pas encore possible). La hiérarchie exacte n'a à peu près aucune influence sur le partage ("à peu près" parce que si c'est plus profond, le dictionnaire qui décrit le torrent sera plus gros, mais c'est le seul impact)

Merci pour les encouragements !

Ce n'est pas prévu pour le moment, mais tout est fait pour que ce soit simple: en pratique chaque version du dossier a un seul et unique identifiant, le hash du torrent qui le décrit. On pourrait imaginer stocker ces versions et leur contenu dans un dossier spécial, éventuellement compressé, et fournir une GUI qui permette de naviguer dedans… Il y a beaucoup d'idées à reprendre de git et bup dans ce domaine, mais ça n'est pas encore la priorité :)

Le modèle B consomme 3.5W, ce qui fait grosso-modo 3.5 euros si tu le laisses allumé pendant un an.

Ah, voilà: Availability in Bittorrent systems, section VI B:

The conclusion of this experiment is that trackers in general provide more information and faster, but the DHT can significantly increase the availability of the whole system.

Bah, un fichier acquis illégalement…

Bah, je croyais que le P2P était pas illégal ?

Je pense que tu voulais plutôt dire: une œuvre dont tu peux techniquement profiter, mais pour laquelle tu n'as pas la licence qui t'autorise a en profiter.

Contrairement a ce qu'on aimerait croire, le point qui fâche est bien sur l'autorisation d'en profiter, pas sur l’échange du contenu lui-même. Si tout le monde utilisait bittorrent pour s’échanger du contenu mais ne pouvait pas en profiter sans acheter la licence a qui de droit, je suis sur que les "méchants majors" n'y verraient rien a redire. D'ailleurs, c'est exactement pour ça que les DRM dans les navigateurs sont poussés par un peu tout les distributeurs.

avec la DHT, je me demande s'il est vraiment utile de maintenir un traqueur.

Il y avait un papier de recherche qui trainait sur le web (j'arrive pas a le retrouver) et qui montrait clairement que la DHT ne remplace pas le traqueur mais le complète: le traqueur permet de renvoyer rapidement une liste incomplète de pairs, et la DHT permet d'avoir le contact de tout le monde, mais ça peut prendre du temps. Beaucoup de temps.

Typiquement, pour les fichiers peu partagés, un traqueur sera plus intéressant, même si c'est centralise. PEX permet en plus de ça d'avoir les contacts de tout le monde très rapidement et de compléter les manques.

Ça ne veut pas dire que DHT est inutile, bien au contraire. Ça veut juste dire que les traqueur ont encore un intérêt.

Et tu envoies le mot de passe comment ?

DANE permet de ne pas avoir a s'occuper du renouvellement toi-même: ton solveur DNS va récupérer le nouveau certificat (modulo le cache DNS) et ton application pourra se servir de cette nouvelle information pour vérifier le certificat renvoyé par le serveur. L'utilisateur n'a pas besoin d'intervenir pour valider le changement.

Une alternative: déménager dans un pays qui n'a pas ces lois. Le service continuerait d'exister (merci Internet d’être aussi flexible). Ça ne se fait pas d'un coup, et ça a un million d'impacts qui n'ont rien a voir avec la choucroute, mais c'est faux de dire que la seule alternative est de fermer.

Ne pas confondre. Ce que tu paies, c'est le coup de tampon du système global d’Autorités de Certifications pour que personne n'ait besoin de réfléchir et prenne peur en voyant le message "Ce site n'est peut-être pas de confiance".

Ton certificat SSL TLS, tu n'as pas besoin de payer pour le générer (ou alors t'as demandé a quelqu'un d'autre, auquel cas il a la clé privée, auquel cas ton certificat ne sert a rien). Tout l’intérêt de DANE, par exemple, est justement de distribuer ton certificat sans avoir besoin du coup de tampon du système; mais ça utilise toujours les certificats TLS (qui ne posent aucun problème).

Pour résumer:

• Il y a 2 choses: les certificats TLS et les Autorités de Certification
• Les certificats sont clean, pas besoin d'y toucher
• Le système d'Autorités de Certification globales est cassée, il faut changer ça

Je trouve que ça manque de précisions, en particulier en ce qui concerne la prise en charge de la toile de confiance.

Ne leur jetons pas la pierre tout de suite, le projet vient d’être annoncé. Peut-être (j’espère) qu'ils feront ça dans une version future.

Enfin, vu la documentation les clefs doivent être exportées et importées manuellement, ce qui incite fortement à s'échanger les clefs dans des messages en clair et non signés, bref, à faire de la sécurité de clown.

A mon avis End-to-End n'invente rien de ce coté, et ne prend donc pas en charge l’échange de clefs, comme a peu près tous les logiciels qui font du PGP en fait (a l'exception notable de keybase)