rakoo a écrit 932 commentaires

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é.

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.