rakoo a écrit 921 commentaires

Et ben pour le coup je vais citer mon langage préféré du moment, mais qui a l'avantage de répondre au cahier des charges: Golang.

Je pense que Go remplacerait avantageusement C++ ici:

• extrêmement simple, la spec tient sur une page. Pas besoin de la lire, c'est juste pour dire que c'est extrêmement simple à apprendre pour quelqu'un qui sait déjà programmer, donc plus simple que C++ pour un débutant complet
• il a toutes les fonctionnalités "standard" attendues d'un langage impératif tout en gardant une syntaxe assez proche (c'était d'ailleurs un des buts des créateurs: un langage qui ressemble au C)
• la distinction est claire entre valeurs et référence, modulo les appels de fonctions qui se font tous avec .. À part ça les signatures des fonctions indiquent clairement ce qui est attendu
• typé, statiquement si les choses sont faites correctement
• le compilateur est extrêmement rapide et affiche des erreurs de compilation sont (subjectivement) claires
• une lib standard extrêmement fournie, il y a peu de chances qu'ils aient besoin d'une dépendance externe pour quoi que ce soit
• s'ils veulent faire les choses proprement, il y a tout ce qu'il faut pour se faire ses tests (unitaires ou non), son benchmarking et même son profiling avec la librairie standard. Super intéressant pour comprendre pourquoi une fonction prend autant de temps, ou pour commencer à toucher du doigt les allocations mémoire et voir où partent les précieux octets de la RAM.

Par contre, tout ce qui parle de concurrence (les channels, go) doit à mon avis être évité pour des débutants complets parce que ça ne leur apportera pas grand chose et ne se transposera pas facilement dans d'autres langages.

Ça dépend où tu arrêtes l'apprentissage, pour moi l'intérêt qu'il soit répandu est que tu trouveras plus facilement des libs pour aller plus loin et, surtout, de l'aide. Je pars du principe que l'apprentissage ne s'arrête pas au cours, mais c'est peut-être parce que dans le cas de la programmation je suis biaisé…

Si le fait qu'un outil/produit plus répandu en faisait un bon produit/outil

Si on reste dans le contexte "Premier langage pour apprendre la programmation", ie le sujet du 'nal, ça a du sens de chercher un langage plus répandu.

chiffrer avant de toucher le serveur n'est pas suffisant.

Et encore, il faut être sur que la clé n'est pas envoyée au serveur. Et comme le client de SpiderOak n'est pas open source, aucun moyen d’être sur.

Et bah ça doit faire un bail que t'as pas essaye alors, parce que moi je me sers très souvent de la recherche sur serveur et ça marche comme voulu. Mon compte est un Gmail, mais je pense pas que ça change quoi que ce soit.

reprendre K9mail (client libre sur android) et de lui ajouter le chiffrement de bout en bout ?

Ça existe déjà avec la combinaison K9mail + APG.

Seul (gros) défaut: APG ne fait que du chiffrement inline et pas via Multipart, ce qui donne un truc moche quand le MUA ne comprend pas PGP (c'est-à-dire l'énorme majorité des cas). Plus d'infos ici.

À part ça, ça marche tip top.

OK, je note : faire une chose gratuitement excuse de tout.

C'est pas une excuse, c'est une explication. Quand on reçoit un service de bénévoles qui font sur leur temps libre, faut pas s'attendre a un niveau de qualité maximale. Non pas que ça soit normal; juste, faut pas s'attendre a la lune.

Le passage en question:

À la croisée des libertés publiques et des enjeux économiques, la confrontation peut directement opposer un opérateur de l’Internet à un État: Twitter en Turquie. Ainsi le gouvernement turc, estimant que la souveraineté et l’intérêt national transcende les intérêts commerciaux, estime légitime de bloquer certains sites Internet et de leur demander d’installer une
représentation dans le pays qu’ils opèrent. Devant cette situation, Twitter a fait le choix de ne pas s’installer afin de ne pas s’exposer à la législation turque. Il est intéressant de noter qu’une entreprise étrangère défie directement le gouvernement de l’État dans lequel elle propose ses services en adressant un tweet à ses utilisateurs turcs contenant une procédure de contournement des mesures de blocage.

Je vois pas en quoi le rapport prône cette censure, il ne fait que citer l'affaire en restant assez neutre (la sous-partie est intitulée Des acteurs privés en passe de défier les États)

J'ai pas lu le reste, mais pour le coup je veux bien croire qu'il est assez nationaliste (ou plutôt européaniste), ne serait-ce que dans le titre: L'Europe au secours de l'Internet.

À l'usage, ce n'est pas un peu le bazar d'avoir une partie du JS mêlée au HTML ?

Il est temps de se demander vraiment ce que veut dire réellement la séparation des activités. Je sais pas si tu as déjà vu des applications web un peu grosses, mais dans la soi-disant couche "présentation" (ie HTML), il y a toujours un bout de "logique" (un semi-langage en plus, pas HTML mais pas javascript, qui permet de définir le contenu final en fonction des données, qui boucle sur ces données, etc…). La seule séparation qui existe vraiment dans ces cas-là est la séparation des langages, ce qui n'est pas intéressant du tout.

Je t'invite à regarder cette vidéo, présentée par l'un des types derrière React. Il y parle du framework, mais il invite surtout à réellement réfléchir sur ce que tu veux faire pour ton application: l'historique des technos web fait que tu veux naturellement séparer HTML, CSS et JS mais en fait ce qui t'intéresse réellement c'est séparer ton application en composants interopérables et réutilisables, quelles que soient les technologies/langages/frameworks que tu utilises pour les créer.

L'exemple proposé s'écrit facilement avec le standard jQuery.

C'est un exemple; je pense qu'il faut voir ça à l'usage, sur des applications un peu plus grosses.

gatejs est un proxy, c'est a dire qu'il fait du MitM, sauf que l'utilisateur est d'accord. Du coup quand un client veut faire du TLS avec un serveur, elle ne sécurise plus les applications jusqu'au bout mais seulement jusqu'au proxy, qui va lui se charger de chiffrer les données jusqu'au serveur distant. Le truc c'est que pour signaler que le proxy est de confiance, il faut bien le dire d'une manière ou d'une autre sur le client.

Le problème, c'est quand il n'y a aucune flexibilité dans les certificats gérés par l'applicaiton, et que celle-ci interdit tout intermédiaire…

Han j'ai lu un peu trop vite, je croyais que tu parlais de donner un TLD par personne, en référence a ceux qui n'ont pas la chance d'avoir un nom de domaine pertinent dans un TLD existant et qui du coup ont demande un TLD rien qu'a eux. Mea Culpa.

Supaire.

Comme ça, au lieu d'avoir un beau système hiérarchique qui est techniquement capable de tourner a l’échelle de la planète, chacun des serveurs racines devra avoir une ligne par être humain. C'est sur, ça va marcher du tonnaire.

C'est ça qui m’embête avec la multiplication des TLDs: on s’écarte de plus en plus du système de délégation qui permet le dynamisme qu'a connu internet jusqu’à aujourd'hui, pour en revenir a un système ou chaque décision est prise unanimement par l'ICANN.

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.