rakoo a écrit 925 commentaires

Effectivement, tu ne pourras pas faire de backup incrémental en branchant juste C14, mais si ta solution de backup te permet de sauvegarder l'index des blocs existants en parallele des blocs de données, alors tu peux te débrouiller pour n'envoyer que les blocs de données dans C14. Si ton logiciel est bien fichu, le(s) fichier(s) d'index peut dans le pire des cas être régénéré depuis les blocs de données, au pire tu peux le(s) sauvegarder dans un autre système accessible plus dynamiquement tel que S3.

Ah ! Je savais bien que le monde n'était pas complètement pourri et qu'il y avait une certaine justice. Merci pour la référence.

Faux, Syncthing n'utilise pas le protocole Bittorrent, il utilise son propre protocole (qui reprend des éléments de Bittorrent, certes)

Par contre il y a un point qui est important pour moi: lorsque le fichier est gros, est-ce qu'il faut attendre qu'il ait été complètement traité avant de pouvoir être envoyé ? Ou est-ce qu'il peut être envoyé au fur et a mesure que les blocs sont calculés ?

Tu peux me citer une autorité de certification qui a arrêté de certifier quoi que ce soit après que sa clé a été utilisée de manière frauduleuse, même pas nécessairement par eux ?

Le seul exemple que j'ai en tête c'est que Chrome a arrêté de faire confiance au CNNIC par défaut. C'est pas beaucoup.

Un peu de visionnage: https://www.youtube.com/watch?v=pDmj_xe7EIQ

Je connais l'existence des procédures standardisées de chiffrement. Mais cela implique des modifications sur les logiciels client.

Ben non, justement; bien que nous autres amateurs du libre auront une préférence naturelle pour PGP et dérivés, il y a aussi S/MIME qui est déjà reconnu par la majorité des MUA commerciaux (même l'iPhone le fait!), et qui fournit plus de fonctionnalité que PGP.

A priori:

1. Dans la mesure ou les records nécessaires a SPF, DKIM et DMARC transitent via DNS, il faut aussi s'assurer qu'ils ont voyagé sans encombre, c'est-a-dire les signer de ton cote avec DNSSEC et être sur que le destinataire fait aussi du DNSSEC et les vérifie correctement (c'est-a-dire que si les records sont invalides, l'email doit être considéré comme invalide… ce qu'aucune application ne fait aujourd'hui)

2. Effectivement, un MD5 ou meme un SHAx d'un document ne sert a rien, dans la mesure ou les pièces jointes font partie du body qui est signé par DKIM. Surtout que MD5 peut tranquillement être considéré comme cassé aujourd'hui.

Après, au niveau légal, je ne peux pas me prononcer. Même pour la solution qui me parait la plus adaptée (S/MIME) je ne sais pas quelle est sa valeur légale.

Riot games (les gens qui font LoL) utilisent XMPP pour la messagerie instantanée, les rosters et la présence. Ils ont fait un ensemble de post de blogs intéressants la-dessus:

• Aperçu du protocole
• Un petit talk avec le recapitulatif qui explique comment ils ont fait pour scaler
• Plus de détails sur l'architecture exacte qu'ils utilisent en interne

Je ne me souviens pas avoir vu un compte-rendu aussi détaillé de l'utilisation d'XMPP ailleurs.

Non mais tout le monde ici sait ce qu'est un glider; c'est a l’extérieur que les gens pourraient se demander ce qu'un caractère braille vient faire dans le texte.

Ah oui, tu as raison, je n'avais pas pensé à ça.

Je ne connais pas vraiment les autres solutions donc je ne sais pas si elles pourront t'aider. Pour rester dans ce que je connais et dans les bup et autres restic, une autre solution serait de faire un truc à la rdiff-backup:

• Le serveur de backup garde une zone "staging" avec la hiérarchie à backuper
• Le serveur de prod rsync ses données vers la zone de staging, ne transférant ainsi qu'une partie des données
• Le serveur de backup déduplique via bup, de son côté, une fois que le transfert est fini

Le gros inconvénient c'est que ça demande de la bonne synchronisation pour que les différents processus ne se marchent pas sur les pieds. En plus de ça tu stockeras toutes les données sur la zone de staging en plus du vrai backup dédupliqué. Une solution serait peut-être de faire en sorte que la zone de staging soit en fait un mount FUSE du backup qui pointe vers le dernier backup. Ou, encore plus poussé un server qui fait rsync+ssh+déduplication, qui n'existe pas mais dit comme ça ça a l'air plutôt alléchant.

J'ai pas entièrement compris la question: tu as un serveur distant que tu aimerais backuper sur un autre serveur distant, sans envoyer la totalité des données sur le réseau ?

bup et associés permettent de faire sans en feintant le système: monte le dossier de backup sur la machine à backuper. Seuls les index seront transférés du serveur de stockage vers le serveur à backuper, et dans l'autre sens seuls les blocks complètement nouveaux seront envoyés.

Ou alors j'ai pas tout saisi.

Le mieux reste encore d'aller voire la page DESIGN de bup que j'ai pointée plus haut. Pour faire simple, l’idée est la suivante:

Rolling checksum

Deja tu prends un algorithme qui te permet de calculer des rolling checksum; c'est une checksum qui permet de calculer efficacement une somme de contrôle a partir de n'importe quel offset du fichier. Imagine une fenêtre de calcul qui donne la valeur de l'octet N a l'octet M. Tu veux calculer la somme de l'octet N+1 a l'octet M+1, c'est a dire décaler la fenêtre d'un octet vers la droite. Avec une somme de contrôle "standard", il faudra tout recalculer octet par octet. Avec une rolling checksum pour calculer cette nouvelle valeur tout ce dont tu as besoin c'est:

• la valeur precedente, c'est-a-dire de l'octet N a l'octet M
• l'octet que tu rajoute, a M+1
• l'octet que tu enlèves, a N

En pratique, il y a adler32, créée par Mark Adler (le créateur de rsync, qui a mis au point cette checksum justement pour rsync vu son fonctionnement particulier) et Rabin-Karp, du même nom que l'algorithme de recherche de string dans une string (justement parce que l'algorithme a besoin d'une rolling checksum)

Trouver une limite aux chunks

Une fois que tu as une rolling checksum, tu peux calculer la somme de contrôle "a chaque octet", c'est a dire que tu calcules de 0 a W, de 1 a W+1, etc…

A chaque somme tu appliques une petite heuristique, du style "est-ce que les 13 premiers bits sont a 1". Une telle heuristique a une probabilité de 1 / 2¹³; dit autrement, la réponse devrait être oui si tu calcules cette somme 2¹³ = 8192, c'est-a-dire que après avoir avancé de 8192 octets tu devrais avoir un oui. Comme c'est juste une probabilité, en pratique tu te retrouves avec des valeurs différentes, mais en gros tous les ~8kio tu es capable de définir une limite; a partir de la, un bloc est l'ensemble des octets entre deux limites (qui devrait donc avoir une taille moyenne de 8kio, donc).

La ou il faut bien faire la différence, c'est que la rolling checksum est calcule sur une petite fenêtre, typiquement 128 octets. Si tu as trouve une limite, on dira qu'elle correspond au dernier octet de la fenêtre. Par contre tu peux être certain que la limite précédente est en-dehors de la fenêtre. Voici un schéma fait a l'arrache, dans lequel les octets sont alignes, tu vois la limite precedente, la fenêtre ou la valeur est calculée, et comme la rolling checksum matche la condition, on met une limite a la fin de la fenêtre.

____________________________________________________________________________________________________
              |                                                   [     ]|
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
            limite                                               fenêtre  limite

Et voila, tu peux calculer une somme de contrôle forte (type SHA-1, SHA-256) sur chaque bloc, qui lui donnera une identité, et ne le stocker qu'une seule et unique fois; si le même bloc se retrouve dans un autre fichier ou dans une version ultérieure du même fichier (qui n'est qu'un cas particulier d'un autre fichier, après tout), il existera déjà, pas besoin de le stocker une 2nde fois.

(note: la valeur exacte de la première somme de contrôle ne sert a rien; tout ce qu'on regarde c'est si elle passe le test des x premiers bits)

Pourquoi c'est top

Dit comme ça on ne voit pas vraiment l'avantage par rapport a, par exemple, du chunking statique tous les X octets. La ou ça fait la différence c'est si tu modifies le fichier, par exemple en plein milieu. En refaisant passer la moulinette, bien entendu le début suivra exactement la même procédure, et tu te retrouveras avec les même blocs. Par contre a l'endroit ou il y a eu une modification le contenu a change, donc la rolling checksum va changer, et la limite se retrouvera a un autre endroit. Le truc c'est que après la modification le contenu n'a pas changé, donc la rolling checksum donnera la même valeur qu'avant, et ce jusqu’à la fin du fichier. Du coup tu te retrouves avec les mêmes blocs avant et après la modification, et seule la modification crée de nouveaux blocs, le tout sans même avoir besoin de faire un traitement spécial. La grosse différence par rapport a un diff classique c'est que les deux versions sont totalement indépendantes; tu peux tout a fait supprimer les blocs uniques a une version donnée sans pour autant affecter les autres versions, a la différence des rdiff-backup et autre duplicity, ou tu as une longe chaine de backups "incrémentaux" qui se suivent tous les uns les autres depuis un backup "full". Dans les backups qui utilisent du content-defined chunking, il n'y a plus de "full" et d’"incrémentaux", tous les backups sont considérés comme full et c'est le stockage derrière qui fait de la magie.

Je suis tombé sur le sujet de la déduplication avec bup, que j'aime beaucoup parce que le code est lisible et la démarche est documentée. Je pense qu'il a plus ou moins engendré les autres qui fonctionnent de la même manière (à savoir content-defined chunking), mais je n'en suis pas sûr à 100%:

• ddar, qui n'a pas l'air d'avoir beaucoup bougé mais qui a priori marche. L'auteur a choisi d'utiliser SQLite pour stocker les métadonnées, ce qui peut s'avérer intéressant pour le futur (supprimer des blocs est par exemple
• attic, déja mentionné
• restic, encore une autre implémentation des mêmes idées
• zbackup, qui contient quelques liens vers la fin

Tout ça pour un rendement énergétique (pour l'homme) moindre que si on mangeait directement l'équivalent de la nourriture des bêtes.

Ben non, à la base si on mange de la viande c'est parce que c'est bon, ça n'a rien à voir avec l'apport énergétique. De l'autre côté je suis d'accord avec toi, la consommation que l'on fait par chez nous de viande est source de problèmes environnementaux et même de santé si on en mange trop.

Du coup j'ai d'abord pensé au tofu. […] Soit je suis infoutu de le préparer comme il faut, soit c'est vraiment fade avec une texture bizarroïde.

En même temps c'est du tofu, hein. La réponse 2 est la bonne réponse.

Donc mon FAI le vois aussi.

Pas tout à fait, tout ce que voit ton FAI est que tu utilises Whatsapp, quand et pendant combien de temps. Il manque l'information la plus juteuse, qui est de savoir avec qui tu parles.

Ok, c'était un peu rapide mais je pensais que le contexte était clair: il y a un canal chiffré end-to-end du contenu entre les participants, et un canal chiffré entre chaque participant et Whatsapp. Le contenu est invisible par Whatsapp, mais les métadonnées (qui parle avec qui, quand, combien de temps, …) leurs sont accessibles. Le monde extérieur n'a accès à rien, bien sûr.

Le contenu est chiffré mais les métadonnées sont en clair. Qui parle a qui, combien de temps, etc… Ça peut avoir l'air anodin en termes de monétisation mais avec l’arrivée des bots qui communiquent directement avec le client, ça peut être très intéressant pour Facebook de voir que tu passes ton temps a parler avec le bot de Coca-Cola…

(Grosse spéculation bien sur, je n'ai aucune donnée pour confirmer ça)

Il y a deux choses différentes:

Et il faut de vrai compétence pour ça : avoir un serveur bien sûr, mais au delà de ça, des admin, de la sécurité, des sauvegardes…

C'est pour moi une perte de temps et de moyens de chercher a héberger ses outils sur des serveurs a l'ancienne depuis que le cloud existe. Il faut penser comme une startup: quand t'es a la rache en termes de moyens, il faut concentrer le peu de temps et d'argent que tu as sur la construction de ton produit/projet, pas se perdre en infrastructure.

des personnes qui réfléchissent à l’outil le plus pertinent, démocratique, etc…

Ca c'est la vraie question, parce que l'outil doit servir la fonction. J'ai pas de vraie réponse de cote la, pour moi un *pad ou, mieux, un Google Docs (ou équivalent libre, hein, mais j'en connais pas) bordelique-mais-persistent reste la meilleure solution dans un mouvement comme celui-ci quitte a réorganiser après coup quand les choses sont en place, dans un wiki ou un site ou un blog ou autre.

En fait la vraie question dans mon message est: existe-t-il des logiciel facilement hébergeable dans le Claude sans administration qui passent a l’échelle facilement ? Des trucs qui s'"hébergent" sur un PaaS comme AppEngine plutôt que sur un VPS en gros.

Déjà, on peut lire l'annonce côté OpenWhisperSystems (ie les gens qui font Signal) par ici.

Pourquoi mettre en place ce chiffrement dans un outil privateur concurrent de celui qu'il développe dans sa propre société ?

Mon intuition: parce que en fait le boulot d'OpenWhisperSystems n'est pas Signal, mais le Protocole Signal. L'application est aujourd'hui le moyen qui rassemble le mieux sécurité et facilité d'utilisation, et toute sa puissance vient du protocole. Moxie est un cryptographe et un codeur; avec ses copains son centre d'intérêt majeur c'est avoir un protocole standard et simple de chiffrement qui peut être intégré partout.

On peut d'ailleurs le voir dans le message d'annonce originel (emphasis mine):

For the past three years, we've been developing a modern, open source, strong encryption protocol for asynchronous messaging systems, designed to make seamless end-to-end encrypted messaging possible.

Today we're excited to publicly announce a partnership with WhatsApp, the most popular messaging app in the world, to incorporate the TextSecure protocol into their clients and provide end-to-end encryption for their users by default.

Je n'imagine pas une seule seconde que l'intégration du Protocole Signal dans Whatsapp ait été faite gratuitement, et au vu de leur propre communication on sent bien que répandre le protocole est le but final. C'est même dit explicitement dans l'annonce d'aujourd'hui:

Over the next year, we will continue to work with additional messengers to amplify the impact and scope of private communication even further.

Pour le reste:

Rien ne permet d'affirmer qu'une porte dérobée n'a pas été ajoutée avec ou sans son concours

Au pire on a la même situation qu'aujourd'hui. Sinon on fait confiance à OWS comme on ferait confiance à une boîte qui fait l'audit d'un logiciel, proprio ou non, et on envisage la possibilité que le chiffrement dans les applications se répand petit à petit, que les développeurs commenceront à intégrer l'intégrer comme fonctionnalité de base et pas comme ajout facultatif (n'est-ce pas, Telegram) et que du coup les communications sont de moins en moins en clair.

Et clairement, un Debian GNU/kFreeBSD est plus proche de "l'écosystème Linux" qu'un Android, alors qu'il n'utilise pas une ligne de code du noyau Linux.

Pire: Microsoft vient de sortir son GNU/NT: pas une ligne de Linux, et pourtant tu fais tout comme sur ton Linux (enfin, Ubuntu) standard.

Certainement donc des binaires compilés pour Windows..

D'après ce post (en angliche, pardon aux puristes) c'est encore mieux que ça. En fait de la même manière que wine permet (théoriquement) de lancer un exécutable Windows dans un univers Linux, ici Microsoft a rajouté une couche appelée "Windows Subsystem for Linux", qui permet de prendre un binaire censé tourner dans un univers Linux et de l’exécuter dans Windows. C'est-à-dire qu'il n'y a pas de recompilation spécifiques, il y a juste une couche d'adaptation pour qu'en dessous ça tourne avec le Windows natif. Une sorte d'émulateur. La page Wikipédia du noyau NT (en angliche encore) donne plus de détails et devrait permettre de se faire une meilleure idée.

En tout cas c'est plutôt sympa de la part de Microsoft, on ne peut s'empêcher de penser à "Embrace->Extend->Extinguish". En tout cas si ça peut permettre à plus de gens de découvrir Linux (pas besoin d'install, de double boot, pas de "ouais mais je peux pas jouer"), et ça, saybien.

En tant que développeur, l'un des intérêts que je vois c'est de tester la compatibilité d'une application avec Windows, ou en tout cas d'en avoir une idée fiable, sans avoir besoin de payer une licence et de pourrir son ordinateur avec tout plein de mouchards.

EDIT: doublon

Je suis plutôt d'accord avec toi et avec la vague de rejet de gpg comme solution (déjà évoqué ici ou ici), j'ai compris que le problème n'est pas gpg en lui-même, mais comme toujours l'horrible expérience utilisateur. Se créer son trousseau de clés et le diffuser est un cauchemar (j'en veux pour preuve les tutos "Comment se créer une clé pgp parfaite en 723 étapes") et que pour améliorer la situation il faudra s'attaquer aux interfaces utilisateurs, et abandonner l’éducation sur le fonctionnement interne du machin, sur comment faire des keysigning parties et tout le tralala semi-social que personne ne fait et qui explique pourquoi gpg est si peu déployé (en valeur relative, hein).

D'ailleurs c'est pas un constat nouveau, Werner Koch lui-même a identifie le problème et esquisse un début de solution (plus un ensemble de bonnes pratiques qu'un logiciel en tant que tel) avec STEED:

• Un logiciel qui fait du pgp doit générer une clé correcte des le premier lancement
• Les clés doivent être diffuses via DNS, sur le domaine de l'utilisateur, de manière a ce qu'un correspondant éventuel puisse les récupérer facilement
• Un logiciel qui fait du pgp doit faire le maximum pour récupérer les clés pgp des correspondants, ou qu'elles soient, et chiffrer avec. Quitte a ce qu'elles soient fausses parce que …
• Un logiciel qui fait du pgp doit partir du principe qu'une clé est bonne a partir du moment ou c'est la première qui a été vue pour le contact en question; a partir de la on regarde si la même clé est utilisée dans les échanges futurs, et tout changement est considéré comme suspicieux. Ce mode de fonctionnement n’empêche pas de confirmer la confiance lors d'un rendez-vous physique ultérieur, bien sur.

Dans la même veine, j'irais même encore plus loin: s'il est possible d'automatiser la création de clés et leur distribution, autant créer une nouvelle cle pour chaque utilisation de manière a réduire l'impact des métadonnées et faire tourner plus fréquemment les clés afin qu'elles ne soient plus utilisées. Il est même possible de ne pas afficher le destinataire d'un message chiffré. Il y a donc ce qu'il faut pour répondre aux points 1 et 3, a condition d'avoir le bon logiciel…

… Et c'est la qu'on touche le point le plus important. La crypto dans gpg a beau être hideuse et antique, elle reste solide. Il nous faut créer des outils qui utilisent ça et fournissent l’utilisabilité qui permettront a gpg d'avoir de nouvelles utilisations un peu plus modernes et un peu plus utiles, et faire en sorte que plus personne n'ait besoin de taper "gpg" en ligne de commande.

C'est une des raisons pour lesquelles je garde cet article sous la main dans l'espoir de pouvoir jouer un peu avec du CSP en Javascript, ça donnerait quelque chose du genre:

go(function*() {
  let results1 = yield take(first())
  let results2 = yield take(second(results1))
  console.log(results2)
})

C'est un peu du async/await en première approximation, sauf qu'avec CSP on gagne la puissance des select par exemple, le tout en javascript "standard" (bon, c'est faux, il faut quand même du javascript récent avec générateurs)

Au pifomètre, 10 hébergeurs sur 10 proposent du PHP, aucun autre langage ne fait pareil (sauf peut-être perl…). Ça facilite l'installation sur hébergement mutualisé.