Goffi a écrit 1537 commentaires

Merci pour cette dépêche bien écrite.

Petite coquille :

Cela permet, sauf si j’ai mal compris, de se passer du paquet pytz est de pouvoir jouer avec les dates et leur timezone plus simplement qu’avant.

s/est de pouvoir/et de pouvoir/

Python ne manque pas d'outils pour une interface graphique rapide. Ça va de la conversion automatique de la ligne de commande via https://github.com/chriskiehl/Gooey à des outils très complets comme Qt, cf. https://awesome-python.com/#gui-development.

Ça vaut le coup de passer un peu de temps à tester et voir les spécificités selon ce que tu souhaites faire. Depuis quelques années j'utilise Kivy qui n'est pas assez connu à mon avis au regard de ses capacités, avec la possibilité de mélanger du Python avec un langage déclaratif (Kv), et le support pour toutes les plateformes majeures (avec plus ou moins de difficultés pour les plateformes mobiles). J'ai d'ailleurs commencé une dépêche pour présenter tout ça.

Pascal n'est pas cité, mais il y a une communauté très active autour de Free Pascal et Lazarus. Je n'ai pas utilisé moi même, mais j'ai fait du Delphi dans ma jeunesse, c'était vraiment sympa et ça permettait d'avoir des choses concrètes très rapidement. Lazarus a l'air de gérer aussi toute les plateformes principales, et d'avoir une bibliothèque de composants assez fournie. Ça peut être un outil sympa pour faire des choses rapidement.

Une autre option qui sort des sentiers battus, c'est d'utiliser Godot (moteur de jeu libre qui a le vent en poupe), y compris pour faire autre chose que des jeux. C'est un des outils que j'envisage d'utiliser à plus ou moins long terme, parce que je pense que ça peut permettre de faire des choses très rapidement et de manière relativement agréable.

Attention par contre, pour les outils que j'ai cité, l'accessibilité peut être nettement moins bonne que sur des gros acteurs comme Qt ou GTK, c'est à ne surtout pas négliger.

Merci pour ces traductions régulières, super boulot !

Petite remarque : quand un terme est traduit comme ici « ajournée » pour « deferred » (terme bien choisi au passage), il serait utile de mettre la traduction en anglais soit en note soit entre parenthèses, parce que les specs sont en anglais uniquement, et ça permet de s'y retrouver.

Salut,

C'est du côté de Jingle qu'il faut regarder, et en particulier la XEP-0234. Le transfert de fichiers est un peu complexe à aborder parce que ça implique de nombreuse XEPs : il y a plusieurs méthodes, des façon de passer les NAT et autres, un système de fallback, une possibilité de faire du chiffrement de bout à bout, etc.

Cette XEP a un système de somme de contrôle (cf. XEP-0234 §8.2), permettant de vérifier que le fichier a été correctement reçu.

Je conseille fortement d'utiliser une implémentation existante plutôt que de partir de zéro, tu peux regarder sur https://xmpp.org/software/libraries.html.

Dans le projet sur lequel je travaille (Salut à Toi) il y a un composant de gestion de fichiers (via Jingle ou HTTP File Upload), fonctionnel mais qui pas encore stable. Il y a effectivement aussi le projet de jnanar (errol que tu as cité).

Bref, oui c'est possible, et non il n'y a pas de limitation sur le volume ou la vitesse de transfert (sauf si imposé par une des parties, par exemple un serveur qui sert de relai). D'autre part le côté extensible de XMPP te permet d'ajouter des choses qui te manqueraient, soit de manière spécifique à ton projet, soit en les proposant comme nouveau standard si c'est potentiellement utile à d'autres.

tu bluffes martoni !

pour manger loin des co nna llègues

C'est un peu triste de lire ça, dans tous les boulots que j'ai eu, un de mes plus gros plaisirs dans la journée de travail était justement de manger avec mes collègues (voire parfois la partie de pétanque, la mini rando, ou la plage).

Salut et merci pour le journal,

ce téléphone m'intéresse particulièrement pour porter des applications sur les différents OS, aussi je me demande s'il est possible de passer d'un OS à l'autre facilement. Je crois que c'est possible de booter depuis une carte SD, et qu'il y avait un projet de multiboot, tu sais ce qu'il en est en pratique ?

Aussi est-ce que le modem et autres composants avec des blobs proprios sont isolés ?

Est-il possible d'utiliser une application Android avec une couche de type Anbox ou similaire ? Je pense particulièrement à OSMAnd~ qui est sans doute une des applications les plus utiles sur un téléphone (quoique avec l'autonomie réduite, c'est pas idéal à l'heure actuelle).

J'avais fait ça il y a quelques années avec XMPP. La « radio collective» était une fonctionnalité expérimentale de Salut à Toi qui permettait d'écouter et partager la musique en même temps sur un salon de discussion :

(d'ailleurs on voit en dessous de la dépêche une autre fonctionnalité — toujours en place — pour contrôler un lecteur multimédia à distance avec MPRIS)

Et une vidéo qui présentait la fonctionnalité (en 2012, le temps passe !) :
https://www.goffi.org/post/2012/02/02/Radio-collective

Le code est toujours présent dans le backend, c'est juste que l'interface web a été refaite, mais j'envisage de remettre en place à l'occasion.

J'avais fait, plus jeune, un freeware pour ajouter les bureaux virtuels à Windows, il avait eu un petit succès (GDesktops). Après je suis passé à Gnunux et au libre, et je n'ai plus jamais regardé en arrière…

Salut, c'est vraiment super merci beaucoup du partage. Je fais parti de ces devs logiciels attirés depuis longtemps par l'électronique mais qui ne trouve jamais le temps de s'y mettre sérieusement (surtout avec un gros projet logiciel sur les bras).

Petites questions :

combien de temps réel entre l'idée et la réalisation, et combien de temps tu y as vraiment consacré par semaine ?

Pour la réalisation du circuit, tu as fait ça au boulot, ou par un tiers, ou tu as ce qu'il faut à la maison (comme je me souviens avoir fait à l'école, avec insoleuse et tout) ?

Enfin question de débutant : est-ce qu'il est possible de simuler un tel circuit avec des outils libres avant de passer à la réalisation physique ?

Merci et encore bravo !

Jitsi Meet permet de faire du partage d'écran, et il n'y a pas de compte à créer. Par contre vu la situation, je ne serais pas étonné que les serveurs soient un peu surchargés, donc à voir s'il n'est pas possible d'avoir une instance à vous.

https://meet.jit.si/ (Framasoft a aussi une instance à https://framatalk.org/, mais ils ont annoncés être déjà surchargés, il vaut mieux trouver une autre instance pour les laisser respirer un peu).

Et en plus c'est du XMPP :)

Oui donc ça fait confiance à la première utilisation (TOFU), si le serveur t'envoies n'importe quoi au début ça passe.

Que se passe-t-il si quelqu'un a un nouvel appareil (quelqu'un qui était sur un téléphone et ajoute une tablette par exemple) ? Il y a une notification, quelque chose ? Rien à valider je suppose ?

OMEMO est l'adaptation de double ratchet pour XMPP, ça n'a pas de sens en dehors de XMPP. OTR par contre n'est volontairement lié à aucun protocole, ce qui fait qu'on peut l'utiliser avec pratiquement n'importe quoi. C'est d'ailleurs un des rares avantages qu'il a sur OMEMO : il peut fonctionner avec des passerelles vers d'autre protocoles.

le principe du chiffrement de bout en bout, c'est justement de ne pas faire confiance au serveur. Si c'est ton serveur qui valide les identités, ça ne sert à rien (à la limite à chiffrer les données pour le serveur, comme ça s'il y a un problème il peut indiquer – ou prétendre – qu'il ne pouvait rien savoir).

Et proprio ou libre ça ne change pas grand chose ici, l'important c'est qui a accès au serveur.

ouch oui, fatigue toussa :). Bon enfin avec le contexte, ça n'a pas empêché de comprendre.

Je trouve que c'est ce qui fait la grande force de Wire, Signal et Whatsapp. Cela ne demande aucune action de la part de l'utilisateur.

Oui justement j'ai vu un Whatsapp tourner récemment (je n'ai jamais utilisé moi même), et j'ai l'impression que ça ne demande jamais de valider la ou les empruntes du correspondant, est-ce vraiment le cas ? Si oui ça me laisse perplexe, parce qu'un chiffrement de bout en bout sans vérification de l'authenticité ça ne sert pas à grand chose (à part à avoir un argument marketing peut-être).

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.