Goffi a écrit 1521 commentaires

J'ai un épisode de parlons XMPP sur le chiffrement à moitié rédigé depuis très longtemps, mais je ne trouve pas le temps de le finir, je suis débordé. Il explique justement ça ainsi que les différences entre les méthodes de chiffrements utilisées sur XMPP.

En gros les 2 méthodes modernes (y'a de grosses discussions en cours pour que ça évolue, mais j'ai pas le temps maintenant d'expliquer en détails) sont OMEMO et OX (OpenPGP), qui permettent tous 2 (et contrairement à OTR) de fonctionner avec plusieurs appareils et quand le ou les correspondant⋅e⋅s sont hors ligne.

OMEMO a une confidentialité persistante, ce qui n'est pas le cas d'OX. En pratique, ça veut dire qu'un appareil ne peut pas avoir des messages antérieurs au moment où il est entré dans une conversation avec OMEMO, tandis qu'avec OX c'est possible. C'est une propriété qui est désirable ou non selon les cas.

Quant au chiffrement de bout en bout par défaut, le problème principal est que la spécification OMEMO a été mal faite et ne chiffre que le corps du message (et pas toutes les données autour, ce qui est très utilisé en XMPP avec les extensions). Du coup si on chiffre avec OMEMO, on fait une croix sur beaucoup de fonctionnalités, et on en arrive à des choses très moches et qui font grincer des dents dans la communauté XMPP, comme des données de mise en forme dans le corps du message (une partie qui ne devrait contenir que du texte pour les humains). C'est une des raisons pour lesquelles il y a de grosses discussions en cours, et que la version actuelle d'OMEMO va être retirée tôt ou tard pour une version faite correctement.

Il y a un chiffrement obligatoire entre clients et serveurs (C2S) et entre serveurs (S2S) avec XMPP. Le chiffrement de bout en bout ajoute une couche pour que tout ne soit pas en clair au niveau du ou des serveur(s), mais sur le réseau c'est toujours chiffré.

Tiens pendant qu'on est à parler de Qt et de Python, est-ce qu'il y a toujours les 2 bindings (PyQt et PySide) ? Si oui, et en dehors des licences (qui sont la raison principale d'une réécriture d'un binding si je me souviens bien), quels sont les intérêts à choisir l'un ou l'autre, et est-ce que les API sont compatibles  ?

C'est plus par curiosité, j'utilise Kivy à l'heure actuelle.

Merci pour la dépêche et aux équipes derrière ce logiciel.

J'en profite pour demander si vous avez une solution efficace pour bloquer les vidéos, c'était censé être fait par Firefox lui même, mais sur de nombreux site j'ai toujours des vidéos qui se lancent automatiquement (sans le son) malgré les réglages idoines, et prennent de la bande passante pour rien en plus d'être très énervantes.

Ce qui me bloque pour utiliser Poetry à l'heure actuelle, c'est l'installation. On demande d’exécuter aveuglément un script sur un dépôt git qui peut changer à n'importe quel moment. Autant je peux moi même vérifier ce script, autant je me vois mal demander ça à mes utilisateurs. C'est dommage parce qu'en dehors de ça ça a l'air super. Pour pip qui est maintenant officiellement distribué avec Python il y a ensurepip, est-ce qu'on a la perspective de quelque chose de similaire à court ou moyen terme ?

Pour celles ou ceux qui utilisent déjà Poetry, est-ce que cette installation ne vous pose pas problème ?

pourtant prosody explique comment dans sa doc: je fais tourner ce composant sur mon serveur depuis plusieurs années, et ce n'est que parce que j'ai un utilisateur sous iOS que je dois faire ces changements. Je n'ai jamais eu de problème de transfert de fichier auparavant.

Tu parles de proxy65 ou d'un composant Jingle pour le transfert de fichiers ? Parce que le premier oui ça existe depuis des années, ça date même d'avant Jingle (ça a été repris dans Jingle).

Si tu as un appareil A qui veut envoyer un fichier à un appareil B de ton contact, et que A<->B ne passe pas (à cause d'un NAT ou autre), tu peux utiliser ce proxy au milieu (appelons le P), et tu fais le transfert de fichier avec A->P, et B le récupère en faisant B->P et il n'est pas nécessaire d'accéder à un port ouvert de B. C'est expliqué dans la XEP-0065, d'où le nom. Mais ce composant ne change rien au fait que tu dois être connecté en même temps pour faire le transfert de fichiers via Jingle.

Ce dont je parle avec un composant Jingle, c'est un composant qui garde les fichiers et permet de les retrouver quand on veut, ce qui fait que A peut partager un fichier avec B même s'ils ne sont pas en ligne au même moment (mais du coup ça transite par le serveur). Et ça, il n'y a à ma connaissance que SàT qui le permet à l'heure actuelle. Le gros intérêt par rapport à HTTP Upload, c'est que tu as tous les mécanismes de négociation de Jingle + les extensions comme les vignettes (thumbnails) pour les grosses images, que j'utilise avec les albums photos.

Y a t il un moyen de mettre une espèce de priorité dans les méthodes d'upload ?

C'est le client qui gère ça, et la plupart du temps HTTP upload est utilisé de nos jours. Ceci dit ça marche bien pour les petits fichiers (< 10 Mio) mais c'est généralement bloqué au dessus.

Proxy 65 n'est qu'un outil pour faire le transfert de fichier en le faisant transiter par le serveur si la connexion directe ne passe pas (c'est un peu plus compliqué que ça mais c'est l'idée en gros). La méthode derrière c'est Jingle File Transfer, j'en avais parlé dans parlons XMPP épisode 10. C'est un meilleur système mais c'est moins répandu (et personne – à part dans SàT, que je développe – ne l'utilise avec un composant serveur, du coup ça oblige à avoir les clients connectés en même temps).

Donc bref, c'est HTTP Upload qui est utilisé dans la plupart des cas parce que ça marche à coup sûr pour ceux qui reçoivent les fichiers, et ça ne nécessite pas d'être en ligne en même temps.

Le lien aesgcm:// est une méthode non standard utilisée par Conversation pour envoyer un fichier chiffré avec OMEMO. C'est documenté de façon non officielle mais n'est pas passé en standard officiel, et nous n'avons à l'heure actuelle pas de méthode alternative pour chiffrer un fichier sur le serveur, donc si tu peux trouver un client qui le gère (c'est le cas au moins de Conversation et de Gajim) c'est pas plus mal.

Il y a eu des progrès sur le partage de fichier ces dernières années, mais ça n'est pas encode idéal (et c'est l'un des problèmes sur lesquels je travaille d'ailleurs).

Donc explications mises à part, utilise HTTP Upload et des clients qui gèrent aesgcm:// et ne te prends pas la tête. Pour un gros fichier, un bon client devrait passer automatiquement à Jingle quand c'est nécessaire.

Le transfert d'image se fait la plupart du temps avec HTTP File Upload, donc ton problème est très certainement là.

Sans avoir testé moi même (je n'ai pas d'appareil avec iOS), Monal est un nom qui revient souvent (avec ChatSecure que tu as testé). Sinon l'équipe de Tigase est assez active ces derniers temps, leur clients sont sans doute à tester (BeagleIM et Siskin IM).

Si tu testes, ça pourrait être pas mal de dire ce que t'en penses ici, pour voir si ce sont des clients qu'on peut recommander.

Le protocole de chiffrement et le protocole de communication ça n'est pas la même chose. XMPP aussi utilise une adaptation du protocole de chiffrement de Signal (c'est OMEMO). Je ne sais pas si WhatsApp utilise encore FunXMPP, mais ça n'est pas incompatible.

Et sinon Google et FB ont parlé XMPP à un même moment sans pouvoir se parler mutuellement (parce qu'ils ont désactivé la fédération, du moins FB).

Il est probable que si tous les développeurs de clients XMPP concentraient leur effort sur un client au lieu de toute une tripotée, ils arriveraient à y faire tenir plus de fonctionnalités et à se concentrer plus sur ce que l'utilisateur veux.

ça n'est pas si simple, les clients ont des architectures et des contraintes différentes. La méthode la plus commune aujourd'hui pour faire un client qui tourne partout serait de faire du web et d'utiliser Electron pour porter ça ailleurs que dans le navigateur. Ça marche, mais c'est lourd et ça n'est pas du natif, ce qui peut poser tout un tas de problèmes. C'est souvent ce que font les applications de messagerie (ou autre) les plus connues, mais y'a du monde derrière pour arrondir les angles (et on revient au problème du temps/des ressources disponibles). Il faut aussi noter que beaucoup de clients ont été commencés bien avant qu'Electron existe.

Conversations c'est du Java + API Android, difficilement portable. Gajim (probablement le plus complet), c'est du Python + GTK, là c'est déjà beaucoup plus portable, mais on va avoir des soucis sur Android, iOS, Web.

D'un autre côté, Movim utilise justement Electron, et fait du Material Design avec voix et tout, donc a priori tout ce qui est à la mode… sauf le chiffrement de bout en bout avec OMEMO, parce que c'est difficile à faire proprement avec cette architecture.

Et dans mon cas particulier, un projet comme SàT a une architecture différente qui fait une grande partie de sa spécificité, difficile de partir d'un client pensé pour le bureau (ce qui était le cas de la majorité des clients à l'époque où ça a été commencé) pour faire ça.

Après il y a le cas de ceux qui veulent faire un client spécifique à une plateforme, et qui utilisent ce qu'ils connaissent, c'est le cas de 2 clients récents (Dino qui utilise Vala, et Kaidan qui utilise Qt).

Et il est probable que ça leur plaise plus de coder un client en partant de zéro que de contribuer à un client existant.

c'est extrêmement rare qu'un client parte de zéro. Bien souvent une bibliothèque est utilisée et complétée quand nécessaire.

c'est pas compliqué, c'est parce que la plupart des clients sont développés par un groupe très restreint de personnes (souvent 1 seule) sur le temps libre. « Conversations » est un des très rares clients à avoir un dév à plein temps, et du coup c'est un des clients les plus populaires parce que le dév a le temps de polir.

Côté serveurs il y a un peu plus de monde à plein temps, beaucoup avec des entreprises: ejabberd, MongooseIM, Tigase, Openfire ont tous une boîte avec du monde payé derrière, Prosody c'est plus petit mais y'a, sauf erreur, 2 dévs à plein temps. Et les serveurs sont, eux, très utilisés (ejabberd en particulier est ou a été utilisé avec de très gros réseaux).

Il y a beaucoup de légendes, de fantasmes et d'idées reçues sur ce que fait la communauté XMPP, et du monde pour critiquer et expliquer comment il aurait fallu faire ça on trouve sans trop de problèmes. Mais la réalité c'est qu'on sait très bien ce qu'il faut (vidéo conf, un bon client iOS, une interface léchée, les bonnes pratiques d'UX, une installation simple avec des paquets pour toutes les distributions/plateformes, du chiffrement de bout en bout) mais on manque de temps.

Dans les cas particuliers de SàT et Movim qui sont des clients qui creusent en dehors de la messagerie instantanée, on souffre aussi du fait que la plupart des gens qui connaissent XMPP l'ont associé au chat uniquement. On l'a vu avec ActivityPub, quand des gens s'émerveillaient d'une vidéo avec un commentaire partagé alors qu'on fait ça depuis des années.

Avec SàT j'expérimente sur des terrains complètement nouveaux (forge fédérée par exemple), et là encore je manque de temps pour que ça prenne vraiment (il me faudrait quelques jours pour ajouter la recherche full text, la gestion de Git en plus de Mercurial, des passerelles Gitlab/Github, et une interface un peu plus agréable, mais je ne les ai pas).

Rien que pour avoir des paquets sur Flathub, Yunohost, F-Droid etc. pour que les gens puissent tester facilement, ça prend un temps énorme (d'ailleurs si y'a des gens pour aider là dessus, je suis preneur).

Sur Android tu as aTalk (natif) et Movim (electron) qui gèrent la vidéo (je n'ai pas testé moi même, donc à voir), et c'est prévu sur Conversation pour le début d'année prochaine. Jitsi avait une application mais je crois qu'elle n'est plus trouvable (au moins sur F-Droid), mais sauf erreur aTalk en est un fork.

J'ai moi même prévu d'implémenter la vidéo sur Android, web et bureau, mais vu le peu de temps disponible, ça ne sera pas pour tout de suite.

Pour Tox, le problème de ne pas avoir de serveur est que ton client va faire son boulot, ça veut dire qu'il va avoir besoin de plus de ressources (réseau et processeur notamment), et du coup ça risque de se sentir fortement sur la batterie. À vérifier, je n'ai jamais testé Tox sur Android, et la dernière fois que j'ai testé sur bureau remonte à des années.

Émission super intéressante du début à la fin, autant la rubrique sur les transcriptions, l'interview de Jean-Baptiste que les perles avec le passage sur Wikidata. Merci à tous les participant⋅e⋅s et personnes qui travaillent régulièrement pour rendre tout ça possible.

Le / dans les arguments est une possibilité du langage qui peut être pratique mais qui n'a pas forcément (et ne devrait pas à mon avis) à être utilisé souvent.

Je vois 2 cas principaux où c'est utile et ça peut empêcher des problèmes:

• imiter une API C, je pense que c'est le cas d'utilisation principal
• pouvoir réutiliser des noms d'arguments dans kwargs. C'est un cas de niche, mais ça m'est déjà arrivé d'être embêté de ne pas pouvoir utiliser un nom d'une variable positionnelle dans des **kwargs, et le jour où ça arrive, on est bien content d'avoir cette syntaxe.

De toute façon, comme le rappelle le zen de Python (import this), « Explicit is better than implicit. »: ces syntaxes sont à utiliser quand elle sont vraiment nécessaires, et dans les autres cas il vaut mieux quelques lignes de plus pour rendre le code plus lisible.

Quelqu'un qui veut rendre un code illisible y arrivera toujours, Python ou pas.

Il y a une petite coquille dans le code aussi, le / manque dans le deuxième exemple de « Arguments exclusivement positionnels »:

def f(a, /, **kw):
  print(a, kw)

f(0, a=1)  # valide ! Affiche: '0 {"a": 1}'

Merci pour la dépêche en tout cas, elle résume bien sans aller dans tous les détails comme l'annonce officielle.

Python 3 est une énorme amélioration et c'était une bonne chose de le faire (rien que la gestion des strings/bytes et le unicode par défaut justifie Python 3). Mais la migration n'a pas été simple, et n'avait pas nécessairement à être gérée immédiatement par tout le monde.

Comme je le dis plus haut, pour ma part je suis content d'avoir eu le support étendu et de faire la migration maintenant, j'aurais eu beaucoup plus de mal il y a quelques années, voire ça n'aurait tout simplement pas été possible (et à lire en diagonale les commentaires sur hacker news c'est le cas pour beaucoup de monde).

Aussi quand on lit que Python 3 est dispo depuis 10 ans, c'est un peu oublier que les premières versions de Python 3 étaient loin d'être parfaites, et que certaines fonctionnalités manquaient (comme les formatage avec % sur les bytes, que j'ai déjà mentionné plus haut).

Bref, il faut aussi faire confiance au développeurs, si certains ont attendu (et j'en fait partie), il peut y avoir de bonnes raisons derrières.

Surtout que la migration n’était quand même pas bien compliquée.

Tu t'avances fort là, peut être que ça n'était pas compliqué dans ton cas, mais il y a des cas où c'était franchement pas simple (Twisted et Mercurial par exemple). Il faut noter aussi qu'il y a des améliorations arrivées plus tard qui bloquaient des migrations auparavant (le % formatting sur les bytes par exemples, il me semble que ça a fortement aidé à la migration de Twisted), et des dépendances qui pouvaient manquer.

Aucun. Fallait migrer il y a longtemps. Genre il y a dix ans. T’aurais eu moins de boulot. ;)

Bien au contraire, j'ai fait la migration récemment et j'ai eu moins de boulot parce que j'ai attendu (je n'avais de toute façon pas tellement le choix). D'une part certaines dépendances n'étaient pas prêtes, et d'autre part des fonctionnalités de Python ou de la bibliothèque standard n'existaient pas ou n'étaient pas aussi complètes qu'aujourd'hui (asyncio par exemple, même si ça n'est pas indispensable au passage Python 3, ça simplifie de pouvoir faire ça en même temps maintenant).

Il y a aussi des projets qui n'ont tout simplement pas pu être portés sur Python 3. C'est le cas de Pyjamas, un transpileur Python => JavaScript. On utilisait ce projet et on a dû jeter une bonne partie du code. Il y a probablement des cas similaires qui ont dû refroidir les envies de passer à Python 3 rapidement.

Et bien sûr, plus on attend, plus on a de chances que les plâtres aient été essuyés.

ah ben je vois que c'est déjà changé, merci aux modérateurs (et merci aussi pour le passage en article de tête :) ).

c'est du SVG, du coup je suppose qu'il prend le max-width. C'est parce que je n'avais pas utilisé d'image dans la première partie que le logo SVG s'est retrouvé là. Si ça pose problème il y a :

• une version PNG en 128x128 
• n'importe quelle autre capture de la version 0.7 peut faire l'affaire, cf. https://repos.goffi.org/sat_docs/file/tip/screenshots/0.7 . Le chat par exemple (même s'il n'est pas encore très élaboré) : 

Sinon peut-être qu'il est possible de limiter la taille du SVG ? Si c'est possible c'est sans doute le plus simple.

Salut,

il y a plusieurs choses qui me motivent, on peut citer en vrac et sans exhaustivité le plaisir de créer et voir évoluer quelque chose, de mettre en pratique des idées, la motivation politique (comme ne pas abandonner et laisser le champ libre aux grosses boîtes avec peu ou pas d'éthique, et qui contrôlent et surveillent déjà trop), l'utilisation personnelle (je l'utilise et je souhaite avoir un outil qui me plaît et que je peux utiliser avec mes proches), une certaine habitude aussi, et ne pas vouloir jeter des années de travail. Il y a des hauts et des bas, mais la motivation baisse rarement dans mon cas. Et puis je sais aussi où je vais, ça aide beaucoup.

Est ce que ça n'empiète pas trop sur ta vie de famille ou d'autres choses importantes?

ça a des conséquences sur la vie de famille oui, j'ai un rythme assez soutenu (en pratique je bosse entre 1 et 2 h chaque jour avant le boulot et plus rarement le soir, j'ai une journée dédiée qui n'est donc pas payée, et je travaille parfois le week-end, sans compter les cas exceptionnels comme les événements type FOSDEM), mais heureusement j'ai des proches compréhensifs, et je fais attention à garder du temps pour eux (et aussi pour les tâches ménagères et administratives).

Il y a des choses qu'il faut mettre de côté (ça fait des années que je veux me mettre à l'Arduino par exemple, mais je dois faire des priorités), et d'autres qu'il faut garder coûte que coûte comme aller en extérieur ou faire un peu de sport (ça je ne le fais pas assez par exemple).

Ça a des conséquences sur la santé aussi : le fait de faire ça en plus de mon travail salarié qui est aussi sur un écran, ça amène des migraines, des douleurs de dos ou de poignets, ça fatigue (abîme ?) les yeux et le corps en général. On peut limiter un peu en s'adaptant (écran spécifique, travailler debout de temps en temps, faire des pauses), mais ça reste malsain.

Est ce que ça vaut le coup?

Je pense oui. Déjà le projet en lui-même je le vois évoluer et arriver où voulu. C'est une brique essentielle pour d'autres projets que j'ai en tête et qui sont désormais possibles. Ensuite sur le plan personnel ça apprend beaucoup de choses (techniques, mais aussi de gestion de temps et de projet, de communication, etc). Sur le plan professionnel c'est aussi un atout : j'ai la chance de ne jamais avoir eu à envoyer plus d'un CV pour trouver du travail, et je pense que c'est en bonne partie dû à mes projets en ligne. Donc même si le projet tombait à l'eau (ce qui n'est pas du tout à l'ordre du jour), il aura été utile.

Qu'en penseras-tu dans 10 ans?

Ça on verra, si je suis encore là (on n'est pas à l’abri d'un accident ou d'une maladie).
Ce qui est sûr c'est que je vais devoir limiter le rythme à un moment si je n'arrive pas à en faire mon travail principal, mais j'ai bon espoir vu les progrès récents et les indices qui montrent un certain intérêt pour ce projet.

oui ça peut être une solution :). Plus sérieusement il faudrait que j'évite de relancer un serveur pendant que je fais autre chose à l'avenir, et que je revois un peu la procédure de maintenance (jusqu'ici le serveur étant uniquement là pour la démo, les mises à jour et autres opérations de maintenance étaient un peu aléatoires). Un serveur de secours ne serait pas une mauvaise chose non plus.

Non non c'est de ma faute, j'ai voulu relancer le serveur à cause d'un petit soucis de ralentissement (peut-être dû à LinuxFr), j'ai fait un systemctl stop qui a pris du temps… et que j'ai oublié.

J'avais beaucoup aimé le livre de Dimitri Robert (Eyrolles) pour GIMP 2.8, je ne sais pas s'il y a eu une mise à jour pour 2.10, j'avais même écris un journal à ce sujet : https://linuxfr.org/users/goffi/journaux/gimp-ca-dechire . Je recommande (et pour ma part je préfère nettement la lecture d'un bouquin papier qu'un tuto ou de la doc sur un écran, et même une liseuse).

la sous-section est une bonne idée en effet. Sinon ça ne me semble pas choquant d'avoir :

• lien 1 (fr)
• lien 2 (fr)
• lien 3 (en)