laurentb a écrit 274 commentaires

Ce qui m'irrite par dessus tout avec GitHub c'est le refus d'accepter d'autres façons de fonctionner, et ses utilisateurs. J'avais écrit sur le sujet il y a… 2 ans.

Sinon petite astuce, tu peux ajouter .patch à une URL de pull request pour récuperer le patch. Je me suis même fait un alias pour ça : amu = "!curl ${1}|git am - #"

En revanche pour contribuer, je n'ai pas vraiment d'astuce.

Pour ma part en plus de la visibilité (il est certain que ça simplifie énormément la recherche d'un travail) j'ajouterai la vanité. J'aime bien voir mon profil Ohloh (maintenant OpenHub) grossir.

Ma motivation première reste le "Pour ma gueule, et je partage ensuite".

De plus les URLs de téléchargement ont parfois des identifiants secrets, j'ai du mal à voir pourquoi ils sont envoyés…

Même si il était libre, tu ne peux pas vérifier ce qui est lancé sur leur serveurs.

Un système hébergé à distance, même avec du chiffrement dans le navigateur, ne peut pas être sécurisé. Il est possible que le site donne du JavaScript malicieux parce qu'on l'a forcé, ou piraté. Même si on a confiance dans le site, le MITM est possible (le système SSL demandant de faire confiance à trop d'intermédiaires).

Encore une absurdité du "tout web" quand on a déjà des solutions qui marchent vraiment en dehors du navigateur.

Tout d'abord, les serveurs de ProtonMail sont localisés en Suisse et dépendent donc de la législation suisse qui est l'une des plus protectrices au monde concernant les données personnelles (d'après les développeurs).

C'est particulièrement naïf. Par exemple le secret bancaire n'existe plus pour les américains en Suisse.

ProtonMail n'enregistre aucun log. Il ne sauvegarde aucune métadonnées, que ce soit les adresses IP à partir desquelles l'utilisateur se connecte, ou bien le temps durant lequel un compte est consulté.

Jolie promesse mais aucun moyen de le vérifier.

On dirait que les donateurs n'ont jamais entendu parler de Hushmail…

lecture directe des vidéo sur les sites populaires de streaming

Oui, à condition d'avoir libquvi installé. (D'ailleurs, weboob peut utiliser libquvi !).

http://repo.or.cz/w/libquvi-scripts.git/tree/HEAD:/share/lua/website pour la liste des sites supportés.

De l'autre côté, le Web Scraping est très éloigné du cœur de ton application, et cela demanderait un boulot fou de gérer autant de banques que Weboob.

Je peux confirmer, gérer les banques, et surtout leur bugs et changements incessants est un énorme travail.

En rapport au premier commentaire, il s'agit donc plus d'utiliser weboob la librairie que boobank l'application. Même si boobank est une bonne application, la vocation de weboob est de s'interfacer avec d'autres applications établies autant que possible (par exemple, videoob va appeler mplayer).

Je me dit que si un produit est certifié

Le problème (entre autres) de la certification c'est que le processus n'est pas public.

Sinon, pour vérifier qu'elles sont chiffrées, tu peux tester de monter ton disque dans une distribution liveCD, et voir qu'il n'y a pas de table des partitions

Justement non, puisque c'est matériel. Il faudrait pouvoir accéder aux données brutes du disque ce qui n'est pas permis ; et si le disque te le permet avec un mode spécial, qui te dit que les données ne sont pas stockées en clair, et chiffrées à la lecture ?

À la limite, si le matériel qui chiffre est séparé du disque dur, étant une sorte de proxy, tu peux vérifier en le débranchant. Mais là, qui te dit qu'il n'y a pas un truc très subtil, comme par exemple un mauvais générateur de nombre aléatoires, qui réduirait grandement le temps nécessaire aux attaques ?

Mauvaise idée, c'est encore plus facile de mettre une porte dérobée au niveau matériel.

On ne sait pas, mais il n'est pas raisonnable de le considérer comme fiable puisque non audité et non auditable. On pourrait dire « présumé foireux ».

J'ai l'impression que l'auteur était sincère, si c'était un troll c'est encore plus triste pour Django.

Je voudrais tout de même noter que si je considère cette modification idiote et inutile, l'auteur a au moins proposé un patch plutôt que d'aller se plaindre sur un réseau social à la mode.

C'est peut-être pour ça que le patch a été accepté aussi vite. La terminologie choisie (leader/follower) était très mauvaise car incorrecte et impossible à comprendre. La nouvelle (primary/replica) est bien meilleure même si primary est utilisé dans d'autres contextes.

Je trouve donc l'attitude de l'auteur du patch louable, mais beaucoup moins celle des développeurs qui l'ont inclus sans réfléchir, surtout pour un framework sensé être professionnel, qui adopte un vocabulaire peu utilisé, pour des motifs politiques et non pragmatiques.

Pas seulement. Les prises mâles et femelles impliquent pénétration, et en général la prise femelle est fixée au mur, à la carte, etc. et n'a pas d'autre choix que de recevoir.

Ce n'est à la fois pas safe pour les féministes radicaux et les petits nenfants.

Et que dire des prises mâles et femelles.

J'invite les mainteneurs voire simple utilisateurs de paquets à se signaler pour être ajoutés à la page installation. Par exemple, j'ai vu des paquets pour Fedora, mais je ne sais pas s'ils fonctionnent bien ou sont tenus à jour.

Le paquet pour Arch Linux étant bien maintenu, j'ai changé le message du site pour qu'il fasse moins peur (devrait être bientôt visible).

Les Gentooïstes peuvent aussi voter pour ce bug.

Globalement on simule le navigateur, ce qui a des avantages (moins de requêtes et moins de ressources) et des désavantages (certains sites sont plus durs à gérer).

Le bugtracker, ça n'est jamais oublié contrairement au reste.

Pour le taux de retour, je pense que ça dépend surtout du bug.

Je pense que c'est prévu, on a déjà un système de téléchargement de factures qui pourrait être réutilisé. Je pensais faire de même avec les relevés en PDF fournis par les banques, car c'est une horreur à télécharger manuellement, et ils suppriment les anciens…

C'est intéressant.

N'hésite pas à nous faire des retours, notamment, je pense que les erreurs devraient toutes être sur stderr, si ce n'est pas le cas on devrait le corriger. Pareil pour les codes de retour.

Même si pour beaucoup de besoins, il devrait être plus rapide et robuste d'utiliser Python directement.

La plupart des modules weboob supportent la configuration d'un proxy, mais je n'ai pas l'impression qu'il soit passé à libquvi.

Tout dépend de si il faut aussi accéder à la page via le proxy, ou seulement pour l'URL de la vidéo.

Je te conseille d'ouvrir un ticket.

La plupart des applications Weboob sont faciles à scripter, et on peut personnaliser la sortie.

Et enfin, il y a la console Python !
Soit import de Browser2, soit weboob-debug MODULE pour faire directement des appels sur le module ou son browser.

Un browser oui, mais uniquement programmable, alors que un navigateur comme Firefox est interactif.

L'utilisateur, avec weboob, ne "browse" pas.

est-ce que browser2 est utilisable en dehors de weboob ? Pour un projet d'une fois qui ne mérite pas une inclusion sous forme de module ?

Justement, je suis actuellement en train d'écrire du code qui utilise uniquement Browser2. Ça marche sans problème.

Je pense cependant que Browser2 va encore pas mal évoluer, donc il faut suivre le développement.

C'est sûr que le code des SSII peut être absolument dégueulasse, et ne sera jamais corrigé, puisque c'est un coût incompris et difficile à mesurer par le client.

Par ailleurs, le code libre d'une même organisation et le code propriétaire, en terme de qualité, ça n'a souvent rien à voir.

Le plus amusant c'est de trouver des failles bateau qui sont là depuis des années, mais que visiblement personne n'a daigné exploiter. Comme quoi, la sécurité par l'obscurité, ça peut marcher ;-)

Si il y a OpenID alors on peut fournir une URL à soi, et héberger son propre serveur OpenID ou déléguer.

http://wiki.openid.net/w/page/12995226/Run%20your%20own%20identity%20server
https://openid.net/specs/openid-authentication-1_1.html#delegating_authentication