Le Weboob nouveau est arrivé

Posté par  . Édité par Nÿco, Florent Zara, Lucas Bonnet et Pierre Jarillon. Modéré par Malicia. Licence CC By‑SA.
Étiquettes :
33
8
fév.
2012
Internet

Weboob (Web Out Of Browsers) est un ensemble d'applications interagissant avec des sites Web. Après quatre mois de travail acharné ou non, la version 0.a succède à Weboob 0.9 avec d'importants changements architecturaux qui seront détaillés en seconde partie de dépêche.

Cette sortie est aussi l'occasion d'inaugurer le nouveau site web de Weboob ! L'ancien, jugé trop rébarbatif pour les utilisateurs, a été astucieusement remplacé par un site plus léger essayant de privilégier la clarté à la verbosité et ravira les plus décideurs d'entre vous.

Dépôts

Ainsi qu'expliqué dans un précédent journal, un changement fondamental a été effectué dans Weboob, puisque les modules ne sont plus installés directement, mais sont présents sur des dépôts. Afin de garantir leur intégrité, ils sont signés par l'équipe de Weboob.

D'un point de vue utilisateur, peu de différence, puisque l'ajout d'un backend va télécharger le module correspondant si celui-ci n'est pas déjà installé. Ce changement est donc quasiment transparent.
Cependant, l'utilisation de la commande suivante est requise régulièrement pour mettre à jour les éventuels modules qui auraient subi des correctifs :

$ weboob-config update

Il est enfin à noter que ce système permettra à des personnes extérieures au projet de mettre à disposition leurs propres dépôts de modules que l'utilisateur pourra référencer dans son ~/.config/weboob/sources.list.

Intégration Debian

La fonctionnalité des dépôts dans Weboob a également permis d'entamer le processus d'intégration de Weboob à Debian. En effet, jusqu'à présent, un dépôt tiers était mis à disposition et les paquets étaient regénérés immédiatement dès qu'une nouvelle version, même mineure (avec l'accord des parents), était publiée.

Comme les modules étaient packagés, il n'était pas possible d'imaginer l'intégration à Debian Stable sachant que les sites peuvent évoluer et les modules se retrouver cassés. Avec la sortie de Weboob 0.a, il est maintenant possible de packager le cœur et les applications, puisque les modules seront toujours téléchargés sur les serveurs de Weboob. C'est ainsi que trois paquets vont intégrer NEW d'ici peu et devraient rejoindre Debian Unstable d'ici une à deux semaines.

Respect des spécifications XDG

Un autre changement important, qui répond à une demande qui a été faite ici même, est le support des spécifications XDG concernant les répertoires des applications. En effet, jusqu'alors, on utilisait naïvement le dossier ~/.weboob/, mais dans l'optique de respecter un maximum les standards, ainsi que d'apporter de nouveaux clients aux rhumatologues, les chemins se rallongent et sont maintenant ~/.config/weboob/ et ~/.local/share/weboob/.

Pour les personnes utilisant déjà Weboob, la transition sera effectuée automagiquement.

Boobathon

Sorte de coding-party où les participants se concentrent sur la rédaction de nouveaux modules, le Boobathon n'a malheureusement été édité qu'une seule fois pour l'instant. Afin de réparer ce manque, le prochain Boobathon va être organisé le 10 mars, et pas n'importe où, à la Fondation pour le Progrès de l'Homme, dans Paris. Initialement, il devait se dérouler dans les locaux de Mozilla Europe, mais pour d'obscures raisons les négociations avec eux ont été subitement arrêtées.

Pour participer à l'évènement, il vous suffit d'être sur Paris, d'avoir un compte sur symlink.me, de lancer l'application boobathon sur l'évènement Boobathon-2012-03 et de taper la commande join :

$ boobathon Boobathon-2012-03

join

Nouveaux modules

Voici la liste exhaustive des modules qui ont été ajoutés à Weboob 0.a :

Contributeurs

Merci aux contributeurs de Weboob 0.a :

  • Camille Baldock
  • Clément Schreiner
  • Florent Fourcot
  • Jocelyn Jaubert
  • Johann Broudin
  • Julien Veyssier
  • Laurent Bachelier
  • leto
  • Luc Didry
  • Nicolas Duhamel
  • Noé Rubinstein
  • Pierre Mazière
  • theo

Weboob est un projet qui grossit et qui vit grâce à ses contributeurs. Si vous souhaitez l’améliorer et que vous connaissez le Python, n’hésitez pas à contribuer.

Team
Le projet organise régulièrement des soirées à Paris, avec parfois des guest stars telles que Tanguy Ortolo.

Aller plus loin

  • # Première impression

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Alors, j'ai été faire un tour histoire de voir mais, ce qui est marrant, c'est la première impression que j'en ai ressorti:

    • Weboob, un nom coquin renforcé par la photo de l'article
    • "havesex" comme application mentionnée comme la plus importante (en fait permet de chater sur un site de rencontres)
    • Anal+ pour visionner les vidéos canal+
    • Youporn
    • DLFP : non, là c'est déconner. Y'a des limites à la décence tout de même.

    Mmmm, j'ai l'impression que le public cible est un mâle célibataire, me trompe-je ? ;-)

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Première impression

      Posté par  (site web personnel) . Évalué à 9.

      Non, puisqu'on peut accéder à AdopteUnMec !

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: Première impression

        Posté par  . Évalué à 10.

        Oui, pour les mâles célibataires homosexuels. :D

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Première impression

      Posté par  . Évalué à 3.

      Tu penses qu'il n'y a que des mecs pour apprécier les jeux de mots graveleux ou avoir envie de sexe ou regarder des vidéos sur youporn ?

      Ce n'est pas très diversité comme façon de penser. ;)

      me trompe-je ? ;-)

      s/trompe/trompé/

      Le FN est un parti d'extrême droite

      • [^] # Re: Première impression

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        « Tu penses qu'il n'y a que des mecs pour apprécier les jeux de mots graveleux ou avoir envie de sexe ou regarder des vidéos sur youporn ? »

        Non, pas du tout. Jusque là, c'était honnête. Mais l'appli DLFP, oui, c'est vraiment le comble.

        Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Première impression

      Posté par  . Évalué à 4.

      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.

      • [^] # Re: Première impression

        Posté par  . Évalué à 9.

        Le commentaire en question :

        Considère néanmoins que chaque mainteneur de backend l'a programmé parce qu'il en avait un besoin personnel. Nous on encouragerait volontiers les contributions féminines pour des backends d'actualité people, de mode, de voyance ou de vente de sextoys, mais on ne va pas nécessairement prendre le temps de les développer nous-mêmes.

        Ainsi les hommes regardent le porno, les femmes les stars, la mode et la voyance. Toi guerrier ramener nourriture pour femme dans hutte aussi ?

        • [^] # Re: Première impression

          Posté par  . Évalué à 8.

          Toi guerrier ramener nourriture pour femme dans hutte aussi ?

          Toi guerrier ramener femme dans hutte par les cheveux aussi ?

          Fixed.

        • [^] # Re: Première impression

          Posté par  . Évalué à 0.

          Ta réflexion est un peu abusée là, non ?

        • [^] # Re: Première impression

          Posté par  . Évalué à 3.

          Haaa mon dieu oser dire que les hommes et les femmes sont différents, tu n'as pas honte ?

        • [^] # Re: Première impression

          Posté par  . Évalué à 3.

          Alors ce commentaire (ironique) te choque, mais le commentaire de ploum plus haut, disant que c'est que pour les hommes, ne te choque pas ?

          Deux poids deux mesures ?

          Le FN est un parti d'extrême droite

          • [^] # Re: Première impression

            Posté par  . Évalué à 0.

            Ai-je écrit que le commentaire de Ploum ne me choquait pas ?

            On peut effectivement dire que Ploum sous-entend que la pornographie n'est regardée que par des hommes hétérosexuels. C'est certainement faux ; personnellement, je m'en fous un peu.

            Par contre, je n'ai pas vu d'ironie dans le commentaire de moules que j'ai recopié.

            Attends, c'est comme l'ironie dans "les noirs sentent mauvais" ?

            Tordant.

            • [^] # Re: Première impression

              Posté par  . Évalué à 2.

              Ai-je écrit que le commentaire de Ploum ne me choquait pas ?

              Non, mais ce n'est pas celui qui t'a fait réagir.

              Le FN est un parti d'extrême droite

        • [^] # Re: Première impression

          Posté par  . Évalué à 10.

          Toi bête. Moi guerrier dans hutte envoyer femmes chercher eau et nourriture pendant moi regarder porno !

      • [^] # Re: Première impression

        Posté par  . Évalué à 9.

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

        Et moi j'ai un domestique noir , je suis pas raciste !

        • [^] # Re: Première impression

          Posté par  . Évalué à 1.

          Une "petite" différence: elle a choisi de contribuer volontairement sans gain financier en retour.

    • [^] # Re: Première impression

      Posté par  . Évalué à 6.

      J'utilise Boobank, pour grapher l'historique du solde de mes comptes bancaires (via le boobank-munin) et je trouve ça génial.

      Et pour juste le solde de mes comptes, une console et "boobank ls" : pas besoin de me connecter sur la banque postale (avec un clavier virtuel de m....) et sur le credit mutuel, j'ai la visu des deux banques dans un seul tableau.

      Je ne m'en sers que pour ça, mais rien que ça c'est excellent.

    • [^] # Re: Première impression

      Posté par  (site web personnel) . Évalué à 3.

      Tiens c'est vrai y'a pas marmiton

  • # Sécurité des backends

    Posté par  . Évalué à 10.

    Bonjour,

    Cela fait plusieurs fois que je regarde avec envie ce soft, que j'aimerais particulièrement utiliser pour gérer mes comptes bancaires, mais il y a un point qui me chagrine (vraiment) : la sécurité. J'ai en effet du mal à donner mes identifiants/mots de passe à un soft, surtout s'il s'agit mes coordonnées bancaires.
    Ainsi, voici mes questions :
    -qu'est-ce qui garanti qu'il n'y a pas de code "caché" dans les backends (ou le reste) qui ferait qu'un développeur malintentionné puisse récupérer mes identifiants?
    -combien de personnes connaissent en détail le code en question pour me rassurer? Quelles sont les relations entre ces personnes ?
    -à quoi ressemble la chaine de sécurisation des téléchargements de plugins? Quels chiffrements sont utilisés?
    -comment se passent les mises à jour? Qui les valide? Sont-elles transparentes?
    -S'il n'y a pas de mise à jour automatique, comment serai-je informé d'une faille de sécurité que les développeurs auraient découverte?
    -comment sont stockées mes informations personnelles? Y a-t-il en particulier un "master password" qui chiffre tout le reste? C'est l'optique suivie par Firefox, et c'est très rassurant : si quelqu'un tombe sur mon portable, il n'en tirera pas grand chose sans ce mot de passe...

    Voilà, je suis peut-être un peu parano, mais l'argent c'est le nerf de la guerre, alors je ne file pas mon compte en banque à n'importe qui!

    Merci d'avance pour vos réponses!

    Frédéric.

    • [^] # Re: Sécurité des backends

      Posté par  (site web personnel) . Évalué à 2.

      comment sont stockées mes informations personnelles? Y a-t-il en particulier un "master password" qui chiffre tout le reste?

      $ cat ~/.config/weboob/backends 
[bnporc]
rotating_password = 654321
login = monid
password = 123456
_backend = bnporc

      La possibilité d'utiliser gnome-keyring/kwallet/autre serait bienvenue.

      • [^] # Re: Sécurité des backends

        Posté par  . Évalué à 5.

        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.

        • [^] # Re: Sécurité des backends

          Posté par  (site web personnel) . Évalué à 4.

          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.

          Ajoutons à ce sujet que weboob permet de stocker ta configuration ailleurs que dans ~/.config/weboob/backends (via des variables d’environnement). Il est donc possible d’avoir un fichier chiffré pour tes backends avec mot de passe sensibles, et le fichier général pour tout le reste. C’est clairement un pis-aller, mais ça rend les choses utilisables (sinon, déchiffrer à tout bout de champ pour une requête youtube, on n’en sortirait plus).

          • [^] # Re: Sécurité des backends

            Posté par  . Évalué à 4.

            C’est clairement un pis-aller, mais ça rend les choses utilisables (sinon, déchiffrer à tout bout de champ pour une requête youtube, on n’en sortirait plus).

            Et pour automatiser ça serait compliqué aussi (genre grapher ses comptes dans munin ou autre).

            J'ajouterais une autre chose concernant la sécurité de weboob.

            Il y a un mois (un peu plus maintenant), j'étais au CCC. C'est le plus grand rassemblement de hackers d'Europe.

            J'ai eu besoin de consulter mes comptes en urgence. J'étais bien content d'avoir boobank d'installé.

            Je ne me voyais pas vraiment passer ma souris sur des chiffres sur l'écran.

            La sécurité dépend surtout du contexte.

            En l’occurrence, je préfère avoir l'information en clair sur un disque dur chiffré qu'en clair sur mon écran entouré de 3000 hackers dont quelques centaines de grosses brutes ultra techniques.

            Le FN est un parti d'extrême droite

            • [^] # Re: Sécurité des backends

              Posté par  . Évalué à 1.

              Oh, une fois qu'on a le login et le mot de passe, pas besoin d'être une brute ultra-technique pour bidouiller tes comptes ;)

              • [^] # Re: Sécurité des backends

                Posté par  . Évalué à 4.

                Oui, et comment tu récupères le login et les mots de passe ?

                Si tu arrives à rooter la machine, c'est de toute manière pas très compliqué d'aller voler une session ou d'ajouter un faux certificat et de faire du man in the middle.

                C'est pas (beaucoup) moins sécurisé qu'un fichier de configuration weboob en clair.

                Par contre, je ne peux pas m'assurer que personne ne regarde mon écran au moment où je tape mon mot de passe. Directement, via une caméra (une caméra, ça peut mesurer moins de 10 centimètres cubes, batterie et module wifi compris), ou en récupérant les rayonnements de l'écran.

                Le FN est un parti d'extrême droite

        • [^] # Re: Sécurité des backends

          Posté par  . Évalué à 2.

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

          Est-ce que c'est précisé au moment où on nous les demande? Si non, ça manque vraiment (mais c'est facilement corrigeable!). Si oui c'est parfait alors.
          Dans les deux cas, je pense qu'il faudrait suggérer clairement qu'il est très fortement pas conseillé de les stocker, sauf si on s'en fout royalement, ou si on a une partition chiffrée.

    • [^] # Re: Sécurité des backends

      Posté par  . Évalué à 2.

      ++ moi aussi je me pose ces questions ++

      Les banques par Internet, c'est déjà faire confiance au site de ta banque. Là on ajoute un tiers à qui il faut faire confiance. Comment rendre ceci sûr pour ceux qui ne lisent pas le code?

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Sécurité des backends

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Tu fais aussi confiance à ta distro et à ton butineur quand tu accèdes à ta banques, tu remplaces ces 2 là par les admins et les devs weboob. Dans tous les cas (distro, butineurs, weboob), tu peux vérifier par toi même si le code n'est pas malsain.

        • [^] # Re: Sécurité des backends

          Posté par  (site web personnel) . Évalué à 5.

          Oui mais weboob ne valide pas le certificat SSL. Mon navigateur, si.

          • [^] # Re:Sécuritédes backends

            Posté par  . Évalué à 4.

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

            • [^] # Re:Sécuritédes backends

              Posté par  . Évalué à 1.

              Je ne sais pas comment c'est fait, mais y'a au moins une librairie qui a sû l'implémenter: http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification

              • [^] # Re:Sécuritédesbackends

                Posté par  . Évalué à 3.

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

              • [^] # Re:Sécuritédes backends

                Posté par  (site web personnel) . Évalué à 1.

                Ah ! Ça me motive encore plus à essayer de faire un nouveau « Browser » basé sur cette librairie que j'avais déjà remarquée pour d'autres raisons.

                Car urllib/urllib2/mechanize sont assez lourds à utiliser et pas toujours très adaptés au debug.

    • [^] # Re: Sécurité des backends

      Posté par  (site web personnel) . Évalué à 4.

      -qu'est-ce qui garanti qu'il n'y a pas de code "caché" dans les backends (ou le reste) qui ferait qu'un développeur malintentionné puisse récupérer mes identifiants?

      Rien, à part la disponibilité et la lisibilité du code source ( 25 000 lignes de code python en comptant les backends, contre 6 000 000 juste pour Firefox)

      • [^] # Re: Sécurité des backends

        Posté par  . Évalué à 2.

        Rien, à part la disponibilité et la lisibilité du code source ( 25 000 lignes de code python en comptant les backends, contre 6 000 000 juste pour Firefox)

        Je suis tout à fait d'accord au sujet de la comparaison, mais étant donné que Firefox est plus répandu (d'un facteur combien? 1000000? 100000?, 10000 peut-être au minimum) que weboob, cela augmente d'autant le nombre de gens susceptibles de se pencher sur le code.
        Des "experts en sécurité" (notez les guillemets...) se penchent probablement plus souvent sur Firefox que sur Weboob, ce qui fait que j'ai tendance à faire plus confiance à Firefox au final.

        • [^] # Re: Sécurité des backends

          Posté par  . Évalué à 1.

          d'un facteur combien? 1000000? 100000?, 10000 peut-être au minimum

          Vos noterez, avec 1.2 milliards de téléchargements pour FF, ça veut dire que j'estime le nombre d'utilisateurs de Weboob entre 1000 et 100000 :-)

          Wikipedia:Mozilla Firefox

        • [^] # Re: Sécurité des backends

          Posté par  (site web personnel) . Évalué à 1.

          Je pense que tu as raison (y compris sur les guillemets). On manque actuellement de relecteurs. Ça me ferait même plaisir qu'on trouve des failles dans mon code un jour :)

          Cependant, Weboob est potentiellement vulnérable d'« homme au milieu » et de « développeur malveillant », alors que les navigateurs sont quand même beaucoup plus complexes et sensibles. En tout cas moi je n'ai pas confiance en mon navigateur !

        • [^] # Re: Sécurité des backends

          Posté par  . Évalué à 2.

          Je suis tout à fait d'accord au sujet de la comparaison, mais étant donné que Firefox est plus répandu (d'un facteur combien? 1000000? 100000?, 10000 peut-être au minimum) que weboob, cela augmente d'autant le nombre de gens susceptibles de se pencher sur le code.

          Combien de gens se sont penchés sur la sécurité des 15 addons Firefox que tu as installés ?

          Le FN est un parti d'extrême droite

    • [^] # Re:Sécuritédes backends

      Posté par  . Évalué à 10.

      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.

      • [^] # Re:Sécuritédes backends

        Posté par  . Évalué à 2.

        Je suis heureux de voir que vous vous êtes posé ces questions :-)

        Pour l'instant j'en conclut qu'il faut quand même attendre encore un peu avant de donner ses mots de passe à Weboob. J'aurais tendance à dire que le minimum sera le passage par le keyring.

        avoir été testé (et évidement reviewé si je n'en suis pas l'auteur)

        Ce qui signifie que personne ne review tes patchs?

        Pour les clefs GPG, le mécanisme de révocation (ou plutôt vérification de liste de révocation) est-il sollicité?

        Bref, excusez ma paranoïa aigüe, mais il faut bien que quelqu'un le fasse :-)

        • [^] # Re:Sécuritédesbackends

          Posté par  . Évalué à 3.

          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.

          • [^] # Re:Sécuritédesbackends

            Posté par  (site web personnel) . Évalué à 2.

            Intéressant cette histoire de patch. Dans les projets où on est plusieurs, j'estime que tous les patchs doivent avoir été relu par quelqu'un. En général, c'est en post-commit via une mailing liste qui mail un diff de tous les changements.

            Ce processus fonctionnait super bien avec svn, mais avec du décentralisé, c'est un poil plus compliqué. De ta description, j'en conclus que tu relis tout ce qui est poussé vers ta branche avant intégration. Et donc tes commits arrivent directement sur cette branche et ne sont pas relus par les autres...

            A mon avis, tu devrais te plier au même processus que les autres. Non pas pour t’embêter, mais pour que tes collègues puissent relire tes patch. Personne n'est à l'abri d'une erreur à la con...

        • [^] # Re:Sécuritédes backends

          Posté par  (site web personnel) . Évalué à 3.

          Bref, excusez ma paranoïa aigüe, mais il faut bien que quelqu'un le fasse :-)

          Dans ce cas pourquoi ne pas chiffrer ton /home ?

        • [^] # Re:Sécuritédes backends

          Posté par  . Évalué à 2.

          chmod 600 .config/weboob ça a quoi de moins bien qu’un keyring ?

      • [^] # Re:Sécuritédes backends

        Posté par  . Évalué à 2.

        Je pense qu'une page sur ces thèmes de sécurité est en effet manquante sur le site du projet.

        Je suis très intéressé par le principe, pour éviter de me taper le site de ma banque juste pour voir où en est mon compte. Du coup j'ai installé weboob et cela fait plusieurs fois que je lance boobank mais que je me pose des questions existentielles au moment où il me demande le mot de passe. J'ai fini par abandonner à chaque fois et j'ai pas mal cherché sur le site des infos sur la sécurité sans en trouver.

    • [^] # Re: Sécurité des backends

      Posté par  (site web personnel) . Évalué à 3.

      Je pense que l'on a bien conscience de ces divers problématiques. C'est d'ailleurs rassurant de voir que d'autres personnes s'en soucient.

      Les développeurs vérifient le code et les mainteneurs des modules bancaires ne sont pas anonymes ce qui diminue fortement l'incitation à ce genre de pratiques.
      Tu peux donc vérifier le code (assez accessible) ou faire confiance aux développeurs principaux.
      Rien ne garantit qu'il n'y a pas de code « caché ». Mais c'est aussi le cas de ton OS ou de ton navigateur (et de toutes ses extensions !).

      Pour le téléchargement des modules, on utilise GPG pour vérifier qu'ils sont authentiques (je me suis basé sur la façon de faire de Debian). Il n'y a pas de mise à jour silencieuse, l'utilisateur est toujours au courant. Mais pas de notification de failles de sécurité, ce qui pourrait effectivement être utile dans le futur.
      Je pense qu'on utilisera bientôt le support GPG de git aussi, qui est disponible depuis peu.

      Au sujet des relations entre développeurs, je n'ai pas en tête les proportions, mais la plupart se sont déjà rencontrés et ne sont pas employés par la mafia (boobank) ou la RIAA (weboorents).

      En revanche, il reste les problèmes évoqués dans d'autres commentaires :

      • pas de vérification des certificats SSL
      • stockage des mots de passe

      Pour ma part je stocke les mots de passe sur une partition chiffrée ; on peut aussi choisir de ne pas les enregistrer. On projette d'utiliser les keyrings sécurisés fournis par le système plutôt que d'inventer notre solution.

      • [^] # Re: Sécurité des backends

        Posté par  . Évalué à 2.

        Rien ne garantit qu'il n'y a pas de code « caché ». Mais c'est aussi le cas de ton OS ou de ton navigateur (et de toutes ses extensions !).

        Comme dit plus haut : je suis tout à fait d'accord, mais j'ai tendance à penser que plus de gens se penchent sur la sécurité de mon OS ou de mon navigateur. De plus, les gens qui développent des sous-systèmes critiques comme le chiffrage SSL, les couches d'authentification, les keyrings, sont (à confirmer mais j'ai une bonne confiance en cela) des experts en sécurité (notez : sans les guillements cette fois ci :-) ).
        Je ne dis pas que vous n'êtes pas bons, mais entre un bon développeur, et un développeur expert en sécurité dont on sait qu'il ne fera pas de bourde, il y a un fossé... (qui s'appelle l'expertise). J'ai moins de mal à donner mes comptes bancaires au 2e qu'au 1er :-)
        (même si Sony s'est fait pirater hein, comme quoi...)

        Pour ma part je stocke les mots de passe sur une partition chiffrée ; on peut aussi choisir de ne pas les enregistrer. On projette d'utiliser les keyrings sécurisés fournis par le système plutôt que d'inventer notre solution.

        Je ne suis pas très partisan de la partition chiffrée : une fois loggué, le déchiffrage est totalement transparent (en tous cas pour le chiffrage que j'avais essayé à une époque, basé sur ecryptfs) et se fait sans contrôle de l'utilisateur. N'importe quel programme a accès à toute la partition chiffrée.
        Pour le Keyring, au moins on sait quand le coffre est ouvert ou non, et on peut le paramétrer finement (idem, de mémoire, ça fait longtemps que je ne l'ai pas utilisé, car à part Firefox cité plus haut, je tape les autres mots de passe sur demande).

    • [^] # Re: Sécurité des backends

      Posté par  . Évalué à 2.

      C’est du Python. Tu ajoutes

      import httplib
httplib.HTTPConnection.debuglevel = 1

      et tu peux voir toutes les requêtes HTTP faites par Weboob, et s’il se connecte à hack.weboob.com, tu peux te poser des questions.

      J’ai pas testé, mais tu devrais pouvoir faire ça aussi :

      import socket as oldsock
class socket:
    def connect(self, *addr):
        print "Connecting to ", addr
        return old_connect(self, *addr)
old_connect = oldsock.socket.connect
oldsock.socket.connect = msock.connect

      En jouant sur PYTHONPATH tu devrais même pouvoir faire ton propre socket.py qui fasse ça plus proprement.

      Sinon, tu as aussi d’autres solutions du genre https://github.com/sloonz/utils/blob/master/bin/tcproxy + tsocks (tcproxy 12345, puis tu configure tsocks pour passer en SOCKS 4 sur le port 12345)

  • # Taiste...

    Posté par  . Évalué à 6.

    Depuis le temps que je lis des infos dessus ici, je viens d'essayer

    Récupération par git, installation, test.

    >weboob-config add cragr 
[snip]
=== [100%] Module cragr has been installed!
[snip]
[website] Website to use (choose in list): 17
[login] Account ID: xxxxxxxxxxxxx
[password] Password (hidden input): 
------------------------------
Backend "cragr" successfully added.

boobank> list
Error(cragr): 'NoneType' object has no attribute 'text'

    pas grave, testons autre chose

    >weboob-config add dlfp
Module "dlfp" is available but not installed.
[snip]
=== [100%] Module dlfp has been installed!
Unable to load module "dlfp": Unable to load module "dlfp": No module named feedparser

    J'ai aussi testé ecrans : pareil que dlfp

    pour info j'ai eu avec weboob-config

    >weboob-config modules
Unable to load formatter "table": No module named prettytable
Falling back to "multiline".

    Dommage...

    Voyons plus loin

    Dans les autres modules testés arte, ouifm, nova fonctionnent.

    Cela semble intéressant même si les deux modules (banque et dlfp) qui me plaisait le plus semblent avoir quelques soucis...
    En tout cas, très bonne idée pour avoir un usage rapide de certains sites web en allant à l'essentiel.

    • [^] # Re: Taiste...

      Posté par  . Évalué à 3.

      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.

      • [^] # Re: Taiste...

        Posté par  . Évalué à 9.

        Pourquoi il n'y a rien sur la page d'installation du site en ce qui concerne les dépendances ? Ça me semble le minimum à indiquer avec les instructions si par installation on entend "pourvoir faire fonctionner le programme" non ?

        • [^] # Re: Taiste...

          Posté par  . Évalué à 1.

          J'ai aussi installé le paquet sur une Ubuntu 10.10, et c'est aussi plein de bugs. videoob avec Dailymotion et Youtube : dailymotion ne marche pas (erreur 403). qvideoob : avec Youtube, on voit les images, mais la vidéo ne se lance pas (alors qu'elle fonctionnait avec videoob qui lance totem). Avec Dailymotion, on ne voir même pas les images.

          Bref, pour l'instant, ça a quand même l'air bien bourré de bugs -- dépendances cryptiques, recherche de fichiers en .smb (???) qui n'ont pas l'air d'exister, appel apparemment aléatoire de différents lecteurs en fonction du contexte... Franchement, il faut avoir du courage pour l'utiliser pour ses comptes bancaires :-) Je désinstalle tout, on verra quand il y aura un vrai paquet Debian.

          • [^] # Re: Taiste...

            Posté par  . Évalué à 5.

            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.

            • [^] # Re: Taiste...

              Posté par  . Évalué à 3.

              Oui oui, je ne voulais pas que mon commentaire soit interprété comme une critique forte, désolé.

              Je comprends parfaitement les bugs d'interface -- les site web changent sans prévenir, ils sont potentiellement merdiques, et c'est un vrai soucis. Je pense que de tels bugs sont tout à fait pardonnables, et même normaux.

              Maintenant, les bugs que j'ai rencontrés sont vraiment bloquants : en gros, weboob ne m'apporte rien par rapport à la visite directe des sites en question. Par exemple un truc qui m'énerve c'est les modules python-qt4 et les dépendances à QT : non seulement ça ne rend pas très bien dans mon zoli Gnome et ça m'oblige à installer tout un tas de dépendances, mais si en plus ça ne fonctionne pas... Le système me semble carrément trop compliqué, on a les mêmes fonctions dupliquées entre une interface graphique et une interface en ligne de commande, mais en plus lancer "play" en ligne de commande n'ouvre pas le même logiciel qu'un clic dans l'interface graphique. Bref, ma remarque revenait à dire que le logiciel n'était pas pret pour l'utilisation normale (sudo apt-get install weboob && weboob devrait être la seule chose à comprendre).

              pour les .smb, je dois avouer que je ne sais pas de quoi tu parles.

              Pardon, ma mémoire m'a fait dislexiser les noms de fichier:

              params.c:OpenConfFile() - Unable to open configuration file "/home/user/.smb/smb.conf":
              No such file or directory

              Je ne sais pas si c'est l'interface QT qui essaye de lire là dedans, mais je ne vois absolument pas l'intéret.

              • [^] # Re: Taiste...

                Posté par  . Évalué à 1.

                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.

        • [^] # Re: Taiste...

          Posté par  (site web personnel) . Évalué à 1.

          Elles sont spécifiées dans les packages. Pas dans le setup.py, pour une raison qui n'est peut-être plus valable (surtout pour les plus essentielles comme yaml, mechanize ou lxml).

          En revanche certains modules peuvent avoir des dépendances supplémentaires, à installer par l'utilisateur de la façon qu'il souhaite (idéalement par un paquet de sa distribution).

          Il y a un effort particulier pour ne pas tout planter et afficher un message à l'utilisateur quand une dépendance manque.

          Mais je suis d'accord, il y a encore du travail au niveau de la documentation de l'installation par les sources, et pour avoir plus de paquets de qualité pour les diverses distributions.

          • [^] # Re: Taiste...

            Posté par  . Évalué à 2.

            Quand on installe sans utiliser les paquets, on est obligé de se frapper des exécuter > plantage > installation du paquet qui va bien > exécution > …

            Pas la peine de faire un truc tout automatisé, juste une liste de dépendance ça ne ferrais de mal à personne.

            Remarque : boobank plante quand il n'a pas lxml.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Taiste...

        Posté par  . Évalué à 1. Dernière modification le 08 février 2012 à 14:58.

        Ok vu pour les dépendances, je ne suis pas habitué à python et j'avais pas trop cherché.
        Le setup m'avait réclamé quelques libs mais pas celles -là, le fait de les vérifier serait appréciable.
        Par contre mageia ne semble pas avoir python-prettytable en dépôt.

        Je vais regarder pour ouvrir un ticket pour cragr.

  • # Et côté encoding stdout, ça progresse ?

    Posté par  (site web personnel) . Évalué à 2.

    J'avais essayé de l'utiliser mais, malheur à moi, je faisais du ssh sur une machine linux depuis un terminal sous Windows. Et, cela créait des problèmes douloureux d'encoding, car le codepage de mon terminal Windows ne savait pas afficher ce que weboob voulait afficher...

    C'est résolu ?

    • [^] # Re: Etcôté encoding stdout, çaprogresse ?

      Posté par  . Évalué à 3.

      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.

      • [^] # Re: Etcôté encoding stdout, çaprogresse ?

        Posté par  (site web personnel) . Évalué à 2.

        Oui je pense que si le terminal n'est pas en UTF-8, il va y avoir des problèmes (et comme la plupart des sites ont de l'unicode, c'est à peu près obligatoire).
        Même depuis Windows tu devrais pouvoir configurer le client SSH du Windows et les locales du Linux pour utiliser UTF-8.

        Mais tous les rapports de bug détaillés sont les bienvenus.

  • # Support en environnement hostile ...

    Posté par  . Évalué à 1.

    J'avais vu dans le code des portions spécifiques à Windows. Est-ce que c'est fonctionnel ou pas ?
    J'ai pas vu de notes sur le site sur le sujet.
    Est-ce que quelqu'un a déjà essayé ?

    Merci.

    • [^] # Re: Support en environnement hostile ...

      Posté par  (site web personnel) . Évalué à 1.

      Comme l'a dis moules, on ne teste pas sous windows, il y'a eu quelques patchs il y a quelques mois mais le contributeur n'a pas donné suite.
      https://linuxfr.org/nodes/89381/comments/1318861

      Ceci dit les patchs ou meme simplement les retours d'utilisation et les rapports de bugs sont les bienvenus, il est possible d'ouvrir les bugs via boobtracker
      http://weboob.org/applications/boobtracker

    • [^] # Re: Support en environnement hostile ...

      Posté par  . Évalué à 1.

      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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.