Je râle souvent en ce moment contre les gens qui réinventent la roue. Dernièrement, c’était pour les gens qui sortaient chaque semaine une nouvelle lib pour accéder à un dico avec la syntaxe dico.cle.cle.cle.

Cela m’énerve doublement.

D’abord parce c’est de l’énergie perdue : le temps passé à développer cette nouvelle lib aurait pu être consacré à améliorer l’ancienne, la maintenir, la corriger, etc. C’est pas comme si on avait trop de bras dans le monde de l’open source.

Ensuite, parce que ça créé plein de confusion.

Dans un monde où il y a 40000 libs, l’utilisateur qui doit choisir ne sait que faire. Créer une énième solution lui ajoute un choix, qu’il doit évaluer. Ca divise aussi l’impact de la publicité qu’on peut faire à la ou les meilleurs solutions. Et on sait que faire connaître quelque chose est difficile.

Bref, réinventer la roue est un pur gachi.

Certes, pas pour l’auteur. Il a amélioré ses capacités techniques, il s’est peut être même amusé, et il a mis un coup de polish a son égo. Je le sais, moi aussi je le fais. J’aime ça.

Mais le monde du libre ne fonctionne que si on peut mettre son cul de côté de temps à autre. Déjà qu’on utilise gratos tout le boulot des autres, c’est le minimum de se sentir un peu concerné, non ?

Alors, évidement, je ne parle pas de recréer une lib pour le même usage, mais qui le fait différemment. Où alors un fork du fait de mésentente avec la direction précédente du projet. Il y a des raisons acceptables pour faire une autre roue.

Il y a néanmoins des cas évidents où ce n’est pas le cas.

Par exemple, j’avais pondu requests-twisted pour me faciliter la vie, n’ayant pas trouver quelque chose de similaire.

Ce matin, l’auteur de txrequest me notifie qu’il a lui aussi une lib qui fait pareil, mais un poil plus avancée, et me demande si je peux fermer mon projet et pointer vers le sien.

Je regarde son projet, je l’évalue. Effectivement, le sien est plus intéressant. Le mien n’apporte rien par rapport à lui. Et sa lib a clairement besoin de visibilité puisque je ne l’avais pas trouvée.

J’ai donc édité mon projet pour pointer vers son projet. Si j’ai des améliorations futures, je ferai un PR sur son repo.

La communauté, ce n’est pas 2 ou 3 gros exploits qui brillent. C’est la somme de milliers petites choses qui amène le mouvement dans la bonne direction.

Il n’y aucune cohérence dans ma manière de donner. Je le fais au fil de l’eau, anarchiquement. Parfois j’oublie pendant des mois et des mois.

Là, je me baladais sur l’excellente documentation de la non moins excellente lib requests, à la recherche du one-liner qui allait, encore une fois, me faire gagner un bon quart d’heure.

Et j’ai vu un bouton “Buy request pro”.

Curieux. Il y a plus mieux que le meilleur de requests ?

Je clique, et en fait le bouton est juste là pour proposer de supporter requests. On “achète” la lib gratuite :)

Le minimum est $12, ce qui est fort raisonnable considérant que ce petit bout de code m’a sauvé la mise un million de fois :

• Pas besoin de se soucier de l’encoding du payload.
• Traitement élégant des headers.
• Api super simple et propre.
• Doc excellente.
• Ergonomie mettant les cas les plus courants à portée de main.
• Automatisation des choses importantes comme les redirections ou les cookies.
• Fonctions avancées pour les cas compliqués comme la vérification SSL.
• Extensibilité.
• Un claque pédagogique qui a influencé toute la communauté Python.

Bref, 10 euros, c’est le prix de mon amour en février. Je suis un mec facile.

J’ai reçu un email étrange nous signalant des pastes sur 0bin.net comme étant pédophiles et nous demandant de les retirer.

Le contenu en question ressemble à ceci. Vous pouvez cliquer, c’est safe.

Vu les abus de DMCA ces temps-ci, je suis plutôt méfiant sur ce genre d’allégation, et j’ai donc demandé un peu plus de détails. La personne, contrairement à pas mal de mecs de boites avec des avocats, a pris le temps de quelques échanges avec moi et, malgré mon ton clairement sceptique, a fini par m’expliquer le principe.

Certains forums hébergeant des photos sexualisant des mineurs sont accessibles au public. Néanmoins, pour y accéder, il faut obtenir des indices qui changent régulièrement. Ces indices sont postés sur des boards jetables, comme cette page facebook, qui pointe sur des pastebin, dans notre cas 0bin.

Ensuite, il faut aller sur le site connu pour son contenu, ajouter les filtres adblocks, faire quelques manipulations JS (dans l’exemple, un flag localstorage), et l’entrée est possible.

Je vire donc ces pastes quand on me les signale, et je fais circuler l’info, au cas où vous tombiez sur ce genre de trucs, que vous sachiez de quoi il retourne.

0bin n’étant pas modérable (c’est le principe), il est logique que des usages non souhaités en soit fait. J’aimerais donc profiter de cet article pour rappeler que le chiffrement n’est pas que pour les terroristes et les pédophiles. Tout comme les couteaux ne sont pas uniquement pour les serial killers : la plupart des gens découpent des carottes avec.

Il y a, en proportion, peu de pédophiles, et peu de serial killers. Ils existent, il ne faut pas les ignorer. Mais ne paniquons pas à l’idée qu’ils utilisent des outils utiles pour les citoyens lambda également. Nous créons un monde pour ces citoyens, pas pour les autres.

Sous beaucoup d’OS, tous les ports d’un nombre inférieur à 1024 ne peuvent pas être utilisés par des processus sans avoir les privilèges administrateurs. Néanmoins, on a pas vraiment envie que son app bricolée un lendemain de cuite soit lancée en root, pour que la moindre faille de sécurité donne l’accès total à son système.

Beaucoup de logiciels se lancent en root, et relâchent leurs privilèges a posteriori. C’est ce que faisait Apache a une époque (peut être le fait-il toujours, j’ai pas cheché). Nginx lui, lance un processus racine en root, et spawn des enfants avec un utilisateur normal.

Mais nous, on a pas la foi de se faire chier à faire ça, donc généralement, on met nginx en front et il gère ça pour nous.

Sauf que, parfois, on a pas envie de mettre 40 couches devant notre app. Par exemple, si on utilise crossbar.io (ouai, j’ai encore réussi à le placer \o/), le logiciel est clairement capable d’être en front tout seul.

Bonne nouvelle, sur les Linux modernes, les exécutables peuvent avoir des permissions avancées, comme “pourvoir changer l’horloge système” ou “empêcher la mise en veille”. Ces permissions sont changeables avec l’outil setcap.

Sous Ubuntu, ça s’installe avec :

sudo apt-get install libcap2-bin

Puis on choisit l’exécutable à qui on veut donner nos nouvelles permissions. Dans mon cas, le Python du virtualenv de mon projet :

$ pew workon super_projet
$ which python
/home/sam/.local/share/virtualenvs/super_projet/bin/python

Je check si il a pas déjà des permissions (normalement non) :

$ sudo getcap `which python`

Nada. Good.

Un petit coup de man setcap nous liste les permissions utilisables, et on peut voire que CAP_NET_BIND_SERVICE est la permission qui permet d’autoriser un exécutable à binder n’importe quel port.

On rajoute les permissions :

sudo setcap cap_net_bind_service=+ep `which python`

On check que les permissions ont bien été ajoutées :

$ sudo getcap `which python`
/home/sam/.local/share/virtualenvs/super_projet/bin/python = cap_net_bind_service+eip

On a rajouté avec le + la permission cap_net_bind_service pour les cas e et p qui correspondent aux premières lettres de ces définitions :

Permitted (formerly known as forced):
    These capabilities are automatically permitted to the thread, regardless of the thread's inheritable capabilities. 

Inheritable (formerly known as allowed):
    This set is ANDed with the thread's inheritable set to determine which inheritable capabilities are enabled in the permitted set of the thread after the execve(2). 

Effective:
    This is not a set, but rather just a single bit. If this bit is set, then during an execve(2) all of the new permitted capabilities for the thread are also raised in the effective set. If this bit is not set, then after an execve(2), none of the new permitted capabilities is in the new effective set.

Et je n’ai absolument rien compris à celles-ci, je sais juste que ça marche.

Voilà, maintenant tout ce que vous lancez avec le Python de ce virtualenv peut se binder au port 80.

Si vous n’aimez pas l’idée de donner cette permission à tout un Python, il existe une alternative : rediriger tout ce qui rentre sur le port 80 vers un autre port.

Pour ça on peut utiliser un autre soft :

sudo apt-get install socat

Par exemple, balancer tout le trafic du port 80 vers le port 8080 :

socat tcp-listen:80,fork,reuseaddr tcp:localhost:8080

Et pouf, votre appli qui écoute sur le port 8080 reçoit le trafic du port 80.

C’est plus simple, mais il faut le faire pour chaque port, et s’assurer que la commande est bien lancée au démarrage du serveur.

Utiliser les outils de Twisted de base pour faire les requêtes est assez chiant, et quand on est habitué à requests, c’est le retour au moyen age.

La lib treq tente de corriger ça mais n’utilise pas l’API de requests et ne propose pas certaine de ses fonctionnalités.

Du coup, après l’article d’hier, j’ai regardé le code source de requests-futures pour voir si je pouvais pas faire la même chose pour Twisted.

Et on peut. J’ai fais un petit (bon, ok minuscule) wrapper qui permet de faire ça :

    from requests_twisted import TwistedRequestsSession
    session = TwistedRequestsSession()
    defer = session.get('http://github.com/sametmax/')
    def print_status(response):
        print(response.url, response.status_code)
    defer.addCallback(print_status)

Ça utilise l’objet Session de requests et donc on peut faire session.get|post|touslestrucsderequests et toute l’API est disponible.

Donc si vous en avez besoin :

pip install requests-twisted

Le truc fait 3 lignes et 2 tests unittaires, en fait c’est juste un deferToThreads derrière. C’est certain que c’est moins performant que l’approche de treq qui utilise directement l’Agent non bloquant de Twisted, mais pour la plupart des cas c’est juste plus pratique, plus familier, et surtout, plus facile à maintenir :)