moules a écrit 490 commentaires

Il y a eu par le passé quelques contributions relatives à Windows. Mais aucun développeur du projet n'utilise cet OS, et pour des raisons qui sont probablement compréhensibles, il ne s'agit pas pour nous d'une priorité.

Cela dit, nous sommes intéressés par les retours, notamment en ce qui concerne le nouveau système de dépôt.

Également, si quelqu'un veut apporter des informations au sujet de l'installation sous Windows, pour qu'on puisse les mettre sur la page d'installation, nous sommes preneurs.

Heu bien je dois t'avouer qu'on ne teste pas sous Windows, donc je ne sais pas trop.

Concernant les problèmes d'encoding, je pense qu'il faut surtout remercier Python qui rend pas les choses faciles, aussi il est probablement que si ton terminal n'est pas UTF-8 ça pose problème…

Peut-être faudrait-il faire une passe là-dessus.

On se pose ces questions, et on est attentif à tes interrogations et tes remarques, parce qu'on sait que ces aspects sont importants, et on est conscients des faiblesse actuelles de Weboob.

Nous sommes très ouvert concernant l'amélioration du projet et de sa gestion, donc ne t'excuse pas pour tes commentaires, on en prend au contraire bonne note.

Effectivement, personne ne review mes patches. C'est une remarque intéressante, mais j'ai du mal à imaginer qu'il y ait un comité qui doive valider chaque patch (incluant les miens). D'une part parce qu'on est assez peu nombreux et pas toujours disponibles, d'autre part parce que ça casserait la dynamique du projet.

Enfin, ça dépend si le problème est de vérifier les introductions de failles volontairement ou non. Dans le second cas, j'essaie de faire attention, et sur les aspects de conception il y a pas mal de concertation.

Je crois que t'es optimiste pour Weboob :)

Ouais mais en fait le problème c'est que j'utilise mechanize, qui lui-même repose sur urllib et httplib. Il faut arriver à récupérer les informations nécessaires à ce niveau là pour pouvoir ensuite valider le certificat.

Mais effectivement, je vais regarder comment fait cette lib là.

Pour la dépendance à Qt, il faut voir que rien ne t'oblige à utiliser QVideoob. Il me semble que niveau packaging Debian, tu as deux paquets, weboob qui installe les applications en console, et weboob-qt qui installes les applications Qt.

QVideoob lancera à terme le même player choisi par videoob, c'est juste qu'il faut le faire. La quantité de taf fait que ce n'était pas une priorité et qu'on ne s'était pas penché dessus. Je t'avouerai que je n'utilise pas QVideoob personnellement.

Concernant le .smb, je pense que c'est Qt, parce qu'il n'y a absolument rien dans Weboob qui a besoin de ça.

Je vais répondre à tes interrogations qui sont légitimes au sujet de la sécurité de Weboob.

Concernant d'éventuelles backdoors dans le code des modules, je ne peux effectivement pas te le prouver autrement qu'avec ma parole, néanmoins le fait que le logiciel soit libre devrait te permettre, si tu es parano, de faire une review du code. Je suis le responsable du dépôt git de référence et le seul ayant les droits pour pousser dedans. Je review tous les commits qui sont intégrés, particulièrement ceux concernant des sites sensibles tels que les banques.

Chaque module a un mainteneur, qui est la personne qui l'a écrit et qui est responsable de l'évolution du code et de la correction des bugs. Maintenant, il existe plusieurs personnes dans le projet qui ont un rôle plus transversal et qui touchent un peu à tout. Pour ma part j'ai une bonne vue d'ensemble de la plupart des modules, et il m'arrive régulièrement de corriger des bugs dans des modules que je n'ai pas écrit.
Afin d'assurer une certaine cohésion dans l'équipe, on organise régulièrement des soirées sur Paris, il y a peu de contributeurs réguliers que l'on n'a jamais vu.

La chaîne de sécurisation des modules utilisée est GPG. Lors de la première installation, il télécharge le keyring du dépôt dans lequel seules se trouvent ma clef et celle d'un autre développeur en qui j'ai une confiance totale. Pour l'instant on suppose que le keyring ainsi récupéré est fiable, mais nous réfléchissons à un moyen plus sûr pour son rapatriement (peut-être distribué avec les sources ?).
Chaque module est signé avec une clef de ce keyring, signature qui est donc vérifiée avant installation.

Pour les mises à jour des modules, dès qu'un commit est poussé sur le dépôt git stable après avoir été testé (et évidement reviewé si je n'en suis pas l'auteur), je pousse la nouvelle version du module sur le dépôt Weboob, signée avec ma clef GPG.

Les mises à jour ne sont pas automatiques. Ta question concernant les mises à jour de sécurité est intéressante, il n'existe pour l'instant aucune procédure de communication, mais l'idée d'une mailing-list et/ou d'un flux RSS peut être intéressante. On est évidement ouvert à d'autres propositions.
Enfin, il est de toutes manières recommandé d'effectuer un weboob-config update régulièrement.

Et pour finir au sujet du stockage des informations personnelles, je te renvoie à ce commentaire que j'ai posté plus haut dans le thread.

Tes questions sont toutes légitimes, je pense même qu'elles devraient faire l'objet d'une page sur le site du projet.

Ça fait parti de quelque chose qu'il va falloir effectuer très rapidement. Malheureusement, il y a beaucoup de difficultés à ça, je me suis beaucoup documenté sur les libs Python qui gèrent le SSL, et c'est une opération qui ne me semble pas évidente.

Mais je suis d'accord que c'est une priorité.

Alors pour reprendre point par point :

• Le backend Dailymotion a un problème effectivement lorsque tu l'utilises avec videoob en REPl (en invite de commande), si tu l'utilises via le terminal ça marche (typiquement lancer videoob search blah et `videoob play ID@dailymotion).
• L'application QVideoob utilise historiquement python-qt4-phonon. C'est un mauvais choix car ça marche mal. Une modification à faire serait, comme pour videoob, de lancer dans un vrai player.
• pour les .smb, je dois avouer que je ne sais pas de quoi tu parles. Est-ce que tu aurais plus d'informations à ce sujet ?

C'est dommage que tu aies rencontré ces problèmes dès le départ et que ça t'ait découragé à l'utiliser. Néanmoins on s'active à corriger les bugs dès qu'ils sont signalés de façon constructive et que la personne est coopérative.

Typiquement, tout à l'heure, une personne a buté sur un bug du module pour la Banque Postale et est venu le rapporter sur IRC. Après quelques échanges, et ce alors que je n'ai moi-même pas de compte chez cette banque, le bug a été corrigé au bout d'une demi-heure et poussé sur les dépôts Weboob.

Weboob permet de faire énormément de choses différentes, est confronté à des sites web qui changent ou qui ne présentent pas la même interface suivant les personnes ou les situations, et c'est très difficile d'avoir quelque chose de 100% stable. Il y a 40 chantiers parallèles, et on manque de main d'œuvre pour ça.

Effectivement pour l'instant les mots de passe sont stockés en clair.

Il est possible de ne pas les stocker du tout (en laissant le champ « Password » vide lors de l'ajout du backend), et l'utilisateur devra l'entrer dès que nécessaire au cours de l'utilisation des applications Weboob.

Une fonctionnalité utilisant python-keyring afin de se servir des keyrings des différents OS/DM (gnome-keyring, kwallet, et les équivalents sous Windows et Mac OS) avait été intégrée, mais en raison de la médiocrité de la lib en question, elle a été désactivée car très peu satisfaisante.
Il est prévu de se repencher sur le problème.

Enfin, on peut considérer que la sécurité des informations présentes dans ton $HOME sont de ta responsabilité, et que c'est à toi de le chiffrer. Ce serait une solution centralisée afin de protéger tes données, plutôt que de demander à chaque application qui conserve des informations plus ou moins sensibles de gérer son propre système pour les sécuriser.

En fait pour dlfp c'est qu'il te manque une dépendance (python-feedparser).

Pour cragr, c'est un bug, le problème c'est que comme le site change d'une région à l'autre il n'est pas évident de s'adapter à chacun, d'autant plus qu'on ne dispose pas de comptes chez toutes.
Je t'invite à ouvrir un ticket (lance avec --debug pour avoir plus d'infos que tu peux partager dedans).

Enfin, pour weboob-config, il te manque python-prettytable.

Ne t'en fais pas, déjà actuellement si tu reçois un mail de @telephone.fr tu n'as aucun moyen (hors GPG mais ça ça change rien) de t'assurer de l'authenticité de l'expéditeur.

C'est faux, la preuve en est qu'une femme a contribué à cette version de Weboob !

En outre, il faut noter que si tu t'es attardé sur certains aspects, il y a quand même la gestion des banques, de sites de transports, de sites de vidéos non pornographiques, de radios, etc.

Je t'invite à lire ce commentaire.

C'est bien, tu viens de découvrir la joie de la boobisation.

Je te conseille un hebdomadaire nommé « Le Canard Enchainé ».

Merci Capitaine Évident !

C'est bien beau, mais d'un point de vue développeur, ça nécessite donc de savoir interagir avec les gestionnaires de paquets de toutes les distributions. Et ne pas proposer de gestion des mises à jour des modules pour les OS qui n'en proposent pas.

En plus de ça, il faudrait à chaque fois refaire un package des modules à mettre à jour pour toutes ces distributions, ce qui est également fastidieux.

Donc non, honnêtement, tel que ça a été mis en place dans Weboob, c'est beaucoup plus simple pour les développeurs du projet, et c'est également un gain pour l'utilisateur (c'est quasiment transparent).

Là il n'est pas question d'avoir un système pour que Weboob se mette à jour tout seul, mais pour installer et mettre à jour des modules, à l'instar des extensions Firefox.

L'idée est de continuer à garder le core et les applications gérés par le système de packages de son OS.

Actuellement, pour vérifier et installer les mises à jour, tu as la commande weboob-config update pour ça.

Maintenant, il est prévu également de faire en sorte que lorsqu'un module plante, il tente de vérifier si une nouvelle version n'est pas disponible et si oui l'installe.

Et c'est vrai qu'on pourrait aussi faire la vérification au lancement des applications graphiques.

C'est pas très discret .X pour ton pr0n téléchargé avec Videoob !

Et je voulais dire 3/4 des applications qui ne respectent pas les specifications XDG.

3/4 des applications le font. Mais c'est une suggestion qu'on va effectivement tenter de prendre en compte.

Ce n'est pas que c'est contraire aux dépôts des distributions Linux.

Le problème typiquement, c'est que si Weboob se retrouve dans Debian Stable, il n'y aura pas de mise à jour des paquets dans le cas où un backend est cassé.

Avoir un dépôt Debian propre, c'est ce qu'on faisait jusqu'à maintenant, mais d'une part tout le monde n'utilise pas Debian, d'autre part la mise à jour des paquets Debian c'est bien plus chiant qu'avec le système rajouté à Weboob, qui en plus fonctionne sur tous les OS.

Ça ne remet pas en cause les dépôts des distributions, le core de Weboob et les applications ont vocation à y être packagées et à rester stables. Il faut voir par contre les modules comme des data qui peuvent évoluer.

Donc puisque tu considères que les gens qui veulent envoyer des lol et des wizz par SMS sont des crétins, tu estimes qu'il est normal qu'ils se fassent entuber et qu'ils soient obligé de payer 10x leur prix réel (si on parle du coût d'un SMS) ?

Le problème est dans le choix, si les seuls opérateurs qui ont le droit d'exercer pratiquent des prix ahurissants, à cause d'une entente entre eux, tu ne peux pas dire qu'on est responsable de ça, puisqu'on ne pouvait de toute façon pas aller ailleurs.

Pour ma part, j'ai fait le choix de rester jusqu'à très récemment sans téléphone portable, d'une part à cause du coût, d'autre part comme expérience idéologique (qui fut d'ailleurs très satisfaisante).

Mais beaucoup de gens ne peuvent pas se le permettre et ont besoin d'un téléphone portable. Ils n'avaient comme choix que celui de se faire entuber passivement par l'un ou par l'autre des opérateurs.

Dans le même genre tu peux :

• ajouter des alias shell sur des commandes communément tapées
• jouer un son en boucle (si il utilise un casque) en cachant le processus
• envoyer un mail à l'ensemble du service annonçant qu'il apportera le petit déjeuner le lendemain

En fait c'est un « jeu » assez fréquent en entreprise, sur les personnes qui ont commis la faute de ne pas locker leur session, pour les punir de manquer à la sécurité de leur poste de travail, et donc potentiellement à celle de la boite.