rakoo a écrit 925 commentaires

le principe de le confidentialité persistante, du moins telle qu'implémentée dans OTR, fait que tu as une clef temporaire, jetable, et qu'il faut être en ligne en même temps pour échanger le message, du coup c'est à cause de PFS que tu ne peux pas utiliser OTR hors ligne.

Pas exactement. Il y a deux-et-demi choses importantes à séparer:

• PFS, Perfect Forward Secrecy: La définition est simple: étant donné une clé lié spécifiquement à un correspondant sur le long terme (nécessaire pour l'identification et l'authentification) et une communication chiffrée avec quelqu'un d'autre, si la clé long-terme est leakée alors les conversations passées ne sont pas dévoilées. Par exemple, PGP, tel qu'utilisé partout (que ce soit dans les mails, dans l'ancienne XEP ou dans la nouvelle), n'a pas de PFS: si ta clé privée fuite alors toutes tes conversations seront en clair. Par contre si tu hackes le truc et que tu crées une nouvelle paire de clés asymétriques pour chaque message et que tu signes chacune de ces nouvelles paires avec ta clé identité long-terme, alors tu as du PFS: si la clé long terme fuite, il est impossible de déchiffrer les messages passés. La définition peut aller plus loin en disant que si une clé éphémère (cad celle utilisée pour chaque message) fuite, alors l'intégrité des messages précédents n'est pas compromise.
• PFS', Perfect Future Secrecy: Le terme n'est pas très répandu parce que la plupart des gens ne voient pas la différence avec le point précédent, ou alors ils pensent que l'un inclue l'autre. En partant de la même configuration, à savoir une clé identité long-terme et une clé éphémère par message: un système a de la PFS' si une clé fuite et que l'intégrité des messages futurs n'est pas compromise. Les deux ne sont pas forcément équivalents. Si par exemple tu utilises une clé symétrique pour chiffrer un message, et qu'à chaque message que tu envoies tu prends la clé précédente et tu la passe dans un KDF, alors tu auras de la forward secrecy (vu que tu passes dans une KDF il est impossible de remonter le "courant") mais pas de la future secrecy (parce que suivre le "courant" vers l'aval est trivial).
• otr, Off-the-Record: c'est quelque chose qui pour le coup vient du monde "physique", où deux participants à une conversation veulent qu'il n'y ait pas de traces de ce qu'il s'est passé. Il y a d'ailleurs une section là-dessus dans la XEP-0136 (Archive Management): l'émetteur dit simplement "n'enregistre pas ce message stp". Une autre manière de faire, c'est de donner les billes pour que techniquement, quelqu'un qui veut faire de l'otr puisse dire "c'est pas moi qui ai écrit ça, regardez, n'importe qui aurait pu écrire ça et se faire passer pour moi" (bien sûr ceci arrive après la conversation, de sorte que ceux qui discutent savent que l'autre est bien l'autre, mais qu'après coup un tiers n'en ait aucune assurance). On parle aussi de Plausible deniability. D'ailleurs le concept me plait moyen, mais c'est autre chose.

Du coup quand on parle de l'archivage c'est pas lié à PFS, qui ne regarde que le chiffrement des messages en cours de transition, mais bien à la plausible deniability, où les participants veulent à tout prix effacer les traces et pour le peu qui subsistent faire comme si ils n'avaient jamais écrit ça. Malheureusement OTR est à la fois une politique de "pas de traces svp" et un protocole répandu dans XMPP, qui fait bien de la deniability mais aussi de la PFS. À cause de ça à chaque fois qu'on parle de chiffrement de bout en bout, il y a des gens pour se plaindre que les messages ne sont pas chiffrés au bout ou qu'il reste une trace, parce qu'ils s'attendent à avoir les même garanties qu'OTR.

Un autre point: le fait qu'OTR nécessite que les deux partis soient en ligne pour discuter n'est pas lié au fait qu'OTR essaie de faire de la PFS où de la deniability, mais juste que c'est un mauvais protocole. J'en veux pour preuve la crypto dans Signal, à savoir Axolotl, qui est capable de fournir la même chose qu'OTR tout en fonctionnant hors-ligne. Bon, c'est un peu du marketing, parce que pour que ça fonctionne hors-ligne il faut quand même le support d'un serveur (que Signal fournit) pour que ça marche. Mais c'est possible.

Pour (beaucoup) plus de détails, voir les articles de blog sur les parties crypto croustillantes de Signal (ex-TextSecure) par les gens d'OpenWhisper (c'est principalement de là que je sors tout ça):

• Asynchronous Security, où ils montrent comment faire de l'asynchrone tout en ayant de la PFS
• Simplifying OTR deniability, où ils regardent un peu plus précisément à quoi ressemble la deniability d'OTR, en quoi elle est pas parfaite et comment ils l'ont amélioré
• Advanced Ratcheting, où ils rentrent en détails dans le protocol utilisé par Signal, à savoir Axolotl (cf lien précédent), et où ils font justement la différence entre forward secrecy et future secrecy, que c'est pas si simple que ça

les présences qui étaient à la base de MUC sont facultatives dans MIX. L'absence de présence est surtout utile pour réduire (de beaucoup) le trafic (et donc améliorer la durée de vie de la batterie sur appareils mobiles)

Le deuxième avantage c'est qu'on peut découpler la présence (ie connecté ou pas, disponible a la conversation ou pas) de la participation au salon de discussion. Parce que par défaut, si je ne m'abuse, lorsque l'utilisateur se déconnecte il quitte automatiquement tous les salons ou il est, et les re-rejoint (automatiquement si c'est configure pour) quand il se reconnecte. Ce qui a du sens pour un protocole oriente messagerie instantanée type IRC, mais vu que XMPP permet les communications asynchrones, ce cote est perdu avec MUC. Avec MIX, on peut dire que l'on est intéressé par un salon et recevoir les messages, que l'on soit connecte ou non… Un peu comme une mailing list, en fait.

ça veut dire que mon client xmpp doit tourner au moment où je fais la requête HTTP.

Presque: ça veut dire qu'un client xmpp qui peut recevoir des messages doit tourner. Si tu es chez ton pote, tu peux recevoir la notification sur ton téléphone avec Conversations, par exemple, répondre dessus avec "YES", et te voila connecté sur ton site.

Pour les deux autres points, c'est quelque chose de très judicieux, et c'est vrai que c'est peut-être mort pour une intégration dans un navigateur…

Ça a l'air intéressant tout ça, mais il me manque un bout: l'identification se fait auprès de qui ? Si elle se fait auprès d'un nœud en particulier, ça veut dire que je reste dépendant de ce nœud au moins pour l'authentification (le contenu peut effectivement être répliqué un peu partout). Si elle se fait auprès de n'importe quel nœud, ça veut dire que n'importe quel nœud a mon mot de passe…

Le cas d'utilisation de base est simple, en fait:

ils viennent, posent leurs questions, repartent

Ce qui est beaucoup plus simple, en effet, que l'utilisation qu'on peut avoir en tête.

Ok, alors maintenant fais comme Slack:

• Historique large dans la version gratuite, illimité dans la version payante
• Envois de fichiers, images, vidéos, gifs
• Envois de liens qui sont automatiquement résolus pour afficher le titre voire même un mini-lecteur si le lien pointe vers une vidéo, pour ne pas avoir à sortir du client
• Recherche intégrale, y compris dans les fichiers envoyés
• Recherche "avancée", du style "message envoyés par xxx sur le chan yyy"
• Synchronisation automatique entre tous les clients

Si tu me dis "yaka installer le bon bot/le bon bouncer", t'as perdu. Slack fournit tout ça sans installer quoi que ce soit. Alors certes sapuesayfermay, mais c'est une expérience utilisateur un million de fois supérieure à ce que fournit une installation standard d'IRC.

Elle est là, la vraie différence. Les amateurs d'IRC diront toujours qu'il y a le bon bot ou la bonne fonctionnalité qu'il suffit d'installer; Slack (et les équivalents) fournissent la fonctionnalité de base sans bouger le petit doigt. Et je parle même pas des centaines d'intégrations, qui une fois encore sont techniquement dépassées par les bots mais qui peuvent être installées en un clic et fournissent 90% des fonctionnalités. Les utilisateurs utilisent le machin au lieu de le configurer.

Je me suis mal exprimé: lorsque je reçois un message sur Facebook, c'est Facebook qui m'envoie un mail. Même pas besoin de me connecter pour savoir qu'il se passe quelque chose.

C'est malin, je croyais que tu allais parler du nouveau merdier de Facebook qui fait tout comme RSS, mais qui s'appelle pas RSS.

Sinon pour les notifications des evenements Facebook eux-mêmes, j'utilise tout simplement les emails, j'en reçois un des que quelqu'un m'envoie un message comme ça je peux aller vérifier directement. Est-ce que ça serait pas suffisant ?

L'autre jour je suis tombe sur GoboLinux qui propose une hiérarchie du système de fichiers originale et, il faut le dire, assez intéressante.

Parce que c’est ce qui compte vraiment quand tu veux envoyer un mail à une destination quelconque.

A contrario STARTTLS est envoyé en clair dans la conversation, donc si un maychant homme du milieu passe par là il peut très bien retirer le bout qui annonce la possibilité de faire du STARTTLS.

En plus de ça c'est plus difficile de faire l'équilibrage de charges, parce qu'il faut un terminateur TLS qui sache parler le SMTP (en tout cas jusqu'à ce que la négociation soit finie). Et recommencer pour chaque protocole qui utilise STARTTLS.

Bref, c'est pratique parce que ça évite de casser trop de choses, mais l'argument "le client sait qu'il peut tenter le SMTP direct" ne tient pas, parce que de la même manière en forçant SMTP-over-TLS on pourrait dire "le client sait qu'il peut tenter TLS+SMTP".

Je suppose que le but de cette loi n'est pas de prévenir le terrorisme. C'en est peut-être un, mais pas le seul.

C'est écrit dans le texte, il suffit de lire:

Art. L. 811-3. – Les services spécialisés de renseignement peuvent, dans l’exercice de leurs missions, être autorisés à recourir aux techniques prévues au titre V du présent livre pour le recueil des renseignements relatifs aux intérêts publics suivants :

1° La sécurité nationale ;

2° Les intérêts essentiels de la politique étrangère et l’exécution des engagements européens et internationaux de la France ;

3° Les intérêts économiques et scientifiques essentiels de la France ;

4° La prévention du terrorisme ;

5° La prévention de la reconstitution ou du maintien de groupement dissous en application de l’article L. 212-1 ;

6° La prévention de la criminalité et de la délinquance organisées ;

7° La prévention des violences collectives de nature à porter gravement atteinte à la paix publique.

Il n'y a absolument aucune surprise là-dedans: ces lois ont été mises en place pour légaliser la pratique actuelle, qui est de savoir ce qu'il se passe vraiment dans la vraie vie, et prévoir tout ce qui peut péter (que ce soit une menace "extérieure" type islamiste importé tout droit de Syrie qui veut se venger des maychans impérialo-capitalistes, ou une menace "intérieure" type citoyens qui s'opposent vigoureusement aux plans officiels, y compris physiquement, pour empêcher la construction d'un aéroport)

Il faut croire que Cisco a le droit alors, parce que leur produit de messagerie instantanée s'appelle tout simplement Jabber

(C'est une vraie daube, soit dit en passant. J'ai peur que les gens associent Jabber (le protocole) à un truc tout naze)

Au contraire, ça marche très bien. Peu importe que Madame Michu croie que Windows soit gratuit ou payant, il y aura de toute façon la dîme qui ira chez Microsoft.

donc ne justifie plus un poste client Windows pour être utilisées, n'importe quel machine avec un navigateur peut faire l'affaire.

Sauf qu'en pratique pour une entreprise acheter une machine pour ses employés c'est soit du Apple, soit du Microsoft, soit des miettes que se partagent Linux et les systèmes à démarrage distant. Dans l'esprit de beaucoup de gens Microsoft reste la solution facile (si ce n'est unique) d'utiliser un ordinateur, à mon avis Microsoft reste tranquille là-dessus.

Puis vous les ignorez

mumble est encore trop léger

Je ne peux pas te laisser partir comme ça. Qu'est-ce que tu trouves trop léger chez mumble que Teamspeak, par exemple, fait ? Je n'utilise mumble que pour du très basique (avec ma famille on se synchronise avec le téléphone standard, puis on discute avec mumble parce que la qualité est incroyable, et qu'il est simple comme bonjour à utiliser) mais je le trouve bien suffisant.

Félicitations pour cette release, poezio est vraiment top !

Est-ce que vous avez prévu de vous diversifier dans le non-IM possible avec XMPP, ou est-ce que vous avez prévu de rester dedans ? Je pense par exemple à pubsub et tous ses dérivés, qui à mon avis sont la deuxième application naturelle de XMPP après la messagerie instantanée.

Ah mais je suis tout à fait d'accord avec toi, 42 forme des humains à un état d'esprit bien spécifique. Tu décris cet état d'esprit comme étant le mal, comme si les gens qui en sortaient n'étaient rien d'autre que des zombies cracheurs de code. Sauf que les 2 points de la notation sont une forme stricte de ce que tu trouveras de toute façon en entreprise (dans une boite qui fait du logiciel, hein). Si tu t'habitues à ça, la version "vie réelle" sera enfantine. Je peux t'assurer que ces deux points sont absolument critiques à la réussite d'un projet (parce que dans réussite, il y a aussi maintenance après la livraison, et c'est là qu'on voit très clairement ceux qui n'auraient jamais du passer la Moulinette).

Ah, et on en fait tout un foin, mais on parle là de la piscine, c'est-à-dire la période de 1 mois qui ne sert qu'à sélectionner les gens qui passent. Un peu comme quand tu as un projet pour un gros client dans un mois, si tu rates ce client t'es foutu, tu t'es mal débrouillé du coup t'es à la bourre comme pas possible: tu peux ne pas aimer ça, mais parfois se démener pour une cible précise peut être nécessaire.

Du peu que j'ai vu, 42 est une école préparatoire aux entreprises, il faut être clair.

meilleur lycée publique de la ville

Comment pourrait-il être le meilleur puisqu'il donne autant de chances de réussite que les autres ?

Il a dit que c’était théorique, il a pas dit que c’était compliqué. Les deux notions sont orthogonales.

• Première étape: le compilateur est con comme un manche, les autres développeurs sont nuls mais croient tous être uniques. Le seul moyen de bosser correctement ensemble, c'est d’être rigoureux sur la manière dont on s'organise; c'est se poser des conventions et s'y tenir.
• Deuxième étape: a moins que tu écrives du logiciel libre pour une entreprise, les seuls qui pourront lire ton code et te donner leurs commentaires seront tes collègues, et j’espère bien que tu fais des revues de code avec eux avant de passer ton code en production. Le fait qu'ils soient en compétition avec toi, tant dans l'entreprise que chez 42, est selon moi une énorme erreur, malheureusement. Par contre c'est beaucoup plus intelligent que de faire corriger ça par un prof (il n'y a pas de prof qui connait tout a 100% en entreprise)

C'est pas du tout mon expérience, mais c'est vrai qu'elle est pas très longue. J'aurais tendance a penser que c'est comme ça dans une boite qui tourne dans l'informatique, et dans ce cas je confirme, écrire du code qui fait ce qui est demande sans dépasser les contraintes temps/budget, c'est beaucoup plus important que la couleur de la cravate du consultant (qui n'en n'a même pas, d'ailleurs).

"pourvu que ça marche"

Il serait peut-être judicieux de se renseigner un minimum, non ?

La notation se passe en 2 temps:

• Première étape, la Moulinette et sa copine la Norminette: cette dernière vérifié juste des trucs bêtes comme la syntaxe, si les fichiers ont le bon nom, s'ils sont dans le bon dossier, bref, s'il respecte les normes, si ça passe pas c'est 0. Si ça passe, le code est compile puis teste, si ça passe pas, c'est 0. Ça ressemble pas mal a ce qui peut être attendu de toi en entreprise (un code qui fait pas ce qu'on lui demande, voire qui le fait mal, c'est direct des problèmes avec le client ou l'utilisateur et les brouzoufs qui s'enfuient a toute vitesse)

• Deuxième étape, la notation par les pairs: ce sont d'autres nageurs qui notent, en groupe, et cette notation est elle-même notée. Je connais pas les détails, mais d’expérience sur des situations similaires ce sont les pairs qui sont toujours les plus critiques.

En bref, pisser du code comme un consultant ne suffira pas, loin de la.

Ça dépend. Je suis de ceux qui pensent qu'une situation exceptionnelle est effectivement exceptionnelle, et que tu n'as donc pas nécessairement le temps/les moyens de nettoyer proprement derrière toi quand un problème survient. Si tu te débrouilles pour qu'un SIGKILL soit la manière normale de fermer ton logiciel (pas de transaction à écrire, pas de fichier à créer/déplacer/supprimer, …), alors tu es prêt pour toutes les situations.