rakoo a écrit 921 commentaires

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)

C'est aussi le nom d'un protocole qui se veut être le remplaçant de Bittorrent.

Et ben il a rien compris.

il n'a pas compris la révolution que préparait la discipline

Mouarf. Tout le monde (libristes inclus) se fout de sa gueule depuis 30 ans parce qu'il prétend que tout ce qui n'est pas libre est écouté par les méchants. 30 ans qu'il refuse d'utiliser des applications propriétaires parce qu'il ne veut pas être suivi, et qu'il prévient tout le monde que c'est ce qu'il se passe quand on utilise ces logiciels propriétaires.

30 ans plus tard, Edward Snowden révèle à tout le monde l'ampleur de l'écoute de la NSA au travers (entre autre) des plus grands éditeurs de logiciels propriétaires. L'auteur peut-il prétendre utiliser un service dans le cloud en restant anonyme ?

Non, c'est sûr, RMS n'a rien prévu.

Parce que ce qui nous intéresse dans l'informatique, ce n'est pas l'informatique en soi, c'est le service […] Mais franchement, avoir les plans du train d'atterrissage d'un avion en 'open source' ne me sert à rien. Je ne vais pas construire mon propre avion, je ne vais pas aller bidouiller les avions existants, je ne vais même pas refuser d'embarquer juste parce que le train d'atterrissage du modèle d'avion de mon vol est moins performant que celui d'autres avions. J'accepte la délégation et le risque qui va avec car ce qui m'intéresse en fin de comptes est le service.

Et ben voilà. L'auteur aurait du fouiller un peu plus les raisons d'être de la FSF et de RMS en particulier pour comprendre ce dont il parle. Leur combat n'est pas du tout dans la démocratisation ou la compréhension du logiciel par tous. Il n'est pas dans la maximisation du rapport service/coût.

Le combat de RMS est pour la liberté de l'utilisateur. L'utilisateur doit rester maitre de ce qu'il fait et de ce qui est fait de lui. Un avion, libre ou pas, n'a aucune influence sur la liberté de l'utilisateur (si ce n'est la liberté de ne pas être suivi). Malheureusement, la complexité des logiciels fait qu'il est impossible de savoir ce qu'il se passe dedans sans avoir à la fois le code source et les instructions de compilation pour utiliser sa propre version. Le Logiciel Libre est une conséquence du combat de RMS, et c'est déjà bien assez vaste (en plus d'être proche de ce qu'il connaît et sait faire) pour qu'il s'y consacre totalement. Mais la liberté des utilisateurs ne s'arrête pas aux logiciels, bien au contraire: la culture Libre ou les éoliennes Libres sont dans la même veine.

Et pourquoi ne pas leur installer Debian directement, alors ?

Je pose une vraie question, parce que ça fait un bail que je n'ai pas utilisé ces distributions: Ubuntu Gnome est-il meilleur/plus stable que Debian ?

Freenet se "contente" de stocker les fichiers que les pairs veulent, de manière à garantir la redondance et s'assurer que personne ne sache qui lit quoi et qui stocke quoi. C'est plus une sorte de système de fichiers distribué et "sécurisé. Fonctionnellement, c'est une sorte de Bittorrent chiffré et anonyme. (En gros, hein)

Gnunet est un framework: en soi il ne fournit rien, mais des services peuvent s'appuyer dessus pour fournir une couche d'anonymisation et de sécurité. Fonctionnellement, ca ressemble plus à Tor.

Pour choisir son thème GTK, j'utilise lxappearance, le sélecteur de LXDE. Peu de dépendances, et permet de choisir sa police, son thème d'icônes, …

Bon mais ça sert plus à rien puisque tu as déjà changé de DE :)

Ben moi, je ne fais pas confiance aux gouvernements.

Ben ouais mais ça c'est pas le problème de Microsoft.

Et puis, surtout, ce sont les gouvernements, dans leur bureaucratie la plus complète, qui font les choses, pas les citoyens. Donc cibler les gouvernements plutôt que tout le monde a plus de sens de ce point de vue.

un autre outil que tout le monde sait foireux

Euh ?

Bitlocker est closed-source et on suppose que Microsoft (et par ce biais la NSA) a accès aux données; pour la plupart des personnes c'est impossible de faire confiance à Bitlocker dans ces conditions. Mais

• Pour les personnes qui travaillent chez Microsoft ou chez la NSA, c'est pas un problème
• A ma connaissance, aucune analyse externe n'a été faite sur Bitlocker

Du coup, comment sait-on que ce logiciel est foireux ?

Ouais mais c'est un esclave qui se libère, donc cépapareil^tm

j'ai bonne espoir

hôpital, charité, toussa :)

Le vrai problème c'est surtout que cette erreur peut se comprendre a l'oral, quand le discours n'est pas préparé ou relu. A l’écrit par contre c'est inexcusable.

la plupart (tous les ?) des clients qui prennent en charge OTR prennent ça en charge également

De mémoire, Jitsi ne permet pas d'associer un contact avec plusieurs empreintes. Mais j'ai teste ça ya un bout de temps, ça a peut-être change depuis.

Sinon tu as raison, on est plus ou moins dans le même problème que les conversations OTR a plusieurs, qui est toujours non résolu.

ça veut dire quoi multi resources non synchronisées sur la même adresse ?

A mon avis ça veut dire que XEP-313 (Recuperation des messages stockés sur le serveur) et XEP-280 (Envoi du message a toutes les ressources connectées) ne sont pas suffisamment déployés: moi-même j'ai choisi yaxim plutôt que Chatsecure parce que ce dernier ne supporte pas la XEP-280, ce qui fait que j'avais des bouts de conversation a droite que j'avais pas a gauche.

Il ne sera même pas possible de commencer une conversation OTR.

Pour en commencer une, il faut deux clés: la clé long-terme (celle que tu vérifies et valide) et la clé court-terme, qui est créée pour chaque échange. Puisque l'autre est hors-ligne, tu n'auras pas cette clé.

OTR, c'est le truc révolutionnaire qui plante quand on change de client

Ça c'est parce que les implémentations n'ont pas pris ce détail en compte: rien n'interdit un même JID d'avoir plusieurs empreintes OTR différentes. C'est pas un problème lié seulement au protocole.

OTR, c'est sûrement bien d'un point de vue crypto mais ca ne s'applique pas très bien au multi client asynchrone.

Et justement, Moxie Marlinspike et sa clique ont développé un OTR avec un protocole un peu different, qui a plusieurs vertus intéressantes:

• meilleure deniabilité
• initiation de la conversation plus simple
• utilisation possible en asynchrone

C'est utilisé dans TextSecure et même dans Pond, mais malheureusement personne n'a encore fait quoi que ce soit pour essayer d'importer ça dans XMPP…