Victor STINNER a écrit 1632 commentaires

Je pense vraiment que Red Hat s'oriente vers OpenStack.

"Red Hat is busy making acquisitions so it can become the Red Hat of the cloud with OpenStack"
http://gigaom.com/2014/06/19/red-hat-is-busy-making-acquisitions-so-it-can-become-the-red-hat-of-the-cloud-with-openstack/

In particular, the Red Hat CTO said that eNovance would help with getting new customers on board, because while everyone wants to talk about OpenStack, “the skills to deliver it are lacking, generally” among many software providers. “I haven’t met a customer yet who doesn’t want to talk about OpenStack,” he said.

D'ailleurs, j'ai l'impression que plusieurs boites passent de leur outil maison à OpenStack. Par exemple, Numergy a débuté avec une solution VMware mais vient de lancer son offre OpenStack.

La ou Openstack file des machines jetables sans gestion fine du stockage, de l'endroit ou se trouve chaque machine ou la migration à cahdu, Ovirt gére des systèmes qui ont pas pour vocation d'être jetable. Donc tu peux faire de la migration automatique, tu as un concept de datacenter, etc, etc.

Le grand principe d'OpenStack est d'offrir une API stable et commune à tous les sociétés qui proposent des services OpenStack (ex: Rackspace, Dreamhost, Numergy, CloudWatt). Par contre, chaque brique est interchangeable. Pour la virtualisation, on peut aussi bien utiliser KVM que Hyper-V ou ESX. Pour le image disque des machines virtuelles, Ceph peut être utilisé. Ceph a des outils pour rapprocher les données des machines qui les utilise, on peut lui décrire la manière dont les serveurs physiques sont placées et il se débrouille. Il existe aussi des solutions propriétaires comme NetApp pour le stockage. Je ne vais pas tout lister car il y a une moins une bonne dizaine d'implémentation pour le réseau, pour le stockage, etc.

En avril, Red Hat a racheté Inktank (la société derrière l'object storage distribué Ceph) :
http://www.redhat.com/about/news/press-archive/2014/4/red-hat-to-acquire-inktank-provider-of-ceph

Red Hat veut renforcer sa position dans le projet OpenStack sur lequel ils sont déjà leader en nombre de contributions.

Je trouve ça très dommage que LibreSSL utilise encore CVS pour stocker l'historique du code source. Pour rappel, CVS n'a pas de notion de "commit" modifiant plusieurs fichiers. Un changement modifiant deux fichiers donne deux commits. Chaque fichier a son propre historique indépendant du projet global. Je ne sais plus si on peut "taguer" une version dans CVS, ni comment sont géré les branches, mais ça me semble difficile à utiliser (comparé à git/hg).

Du coup, ça va être très galère pour synchroniser LibreSSL avec OpenSSL, ou bien LibreSSL et un fork de LibreSSL.

Je sais pas moi, utilisez Git, Mercurial ou n'importe quoi d'autres de plus récent que CVS !

Comme dit dans l'article de Glyph, il existe un backport d'asyncio pour Python 2 :
http://trollius.readthedocs.org/

C'est "presque" pareil qu'asyncio, la principale différence est la syntaxe de coroutines (yield From(…) vs yield from …). Il est possible d'écrire du code compatible Trollius, Tulip (Python 3.3) et asyncio (Python 3.4, 3.5) :
http://trollius.readthedocs.org/#write-code-working-on-trollius-and-tulip

Effectivement, les projets écrits pour asyncio sont jeunes. C'est normal, asyncio n'est stable que depuis quelques mois. Pour en avoir la liste :
https://code.google.com/p/tulip/wiki/ThirdParty

Voir aussi ce site qui liste les ressources asyncio :
http://asyncio.org/

Ma principale critique de Twisted est qu'il est facile de mal utiliser le système de callback et d'écrire du code qui ne sera pas exécuté séquentiellement (car les callbacks ne sont pas bien chaînés). Écrire du code par callback est verbeux, répétitif et difficile. Je ne parle même pas du débogage :-( @inlineCallbacks rend l'écriture de code Twisted plus aisé, mais ce n'est pas utilisé pour tout et ça reste un peu du bricolage dans Twisted.

Un Tweet semble confirmer que GRsecurity protège de cette vulnérabilité :
"No fewer than four grsec features (UDEREF/KERNEXEC/RANDSTRUCT/HIDESYM) prevent this exploit for the pty vuln: No fewer than four grsec features (UDEREF/KERNEXEC/RANDSTRUCT/HIDESYM) prevent this exploit for the pty vuln: http://bugfuzz.com/stuff/cve-2014-0196-md.c"
https://twitter.com/grsecurity/status/465815357299896321

Quelques détails sur le cas de Python.

Python utilise cette solution et décide de changer sa fonction de hachage pour Murmur.

Peut-être que Murmur a été discuté, mais Python ne l'utilise pas. La modification apportée à Python est d'ajouter un secret qui est utilisé dans la fonction de hashage (DJBX31A modifié pour utiliser ce secret). Le secret est un nombre de 64 ou 128 bits (2 long en C). Il a été montré qu'en pratique, on obtient seulement 256 fonctions de hashage différentes (au lieu de 2⁶⁴ ou 2¹²⁸ ). Dans Python 3.3, le secret est généré aléatoirement à chaque exécution. Dans les versions précédentes, il faut utiliser une option en ligne de commande ou une variable d'environement pour rendre la fonction de hachage aléatoire (que le secret soit généré et utilisé).

Pour améliorer la sécurité, Python 3.4 utilise désormais SipHash qui est plus difficile à casser (clé plus grande, construction cryptographique, etc.). Je n'ai pas entendu d'attaque sur SipHash pour le moment.

D'ailleurs, le type dict de Python n'utilise pas de liste chaînée mais l'adressage ouvert :
http://fr.wikipedia.org/wiki/Table_de_hachage#Adressage_ouvert

Changer complètement l'implémentation du type dict de Python a également été discuté. Martin von Loewis a par exemple proposé le type "AVL tree" (avec une implémentation "presque fonctionnelle") :
http://bugs.python.org/issue13703#msg152030

Il faut relire la discussion complète (ce ticket, mais également la liste de discussion python-dev). Il me semble que cette option a été rejeté pour plusieurs raisons. Dave Malcolm a par exemple noté que l' "AVL tree" ne permet pas d'utiliser des types arbitraires comme clés (ou plutôt que l'AVL tree s'y prête mal). Antoine Pitrou souligne un problème de consommation mémoire.

Pour comprendre la discussion, il faut se rappeler qu'en 2012, la fonction hash() de Python était déterministe et les développeurs s'attendaient à ce que les types dict et set aient toujours la même représentation (repr(data)). La première question était d'estimer le nombre d'applications cassées par une nouvelle fonction de hash.

Au sujet de la PEP 456, il était prévu au départ de pouvoir charger une fonction de hash via une bibliothèque externe. Finalement, la PEP a été simplifiée pour utiliser plutôt des options de compilation, et la PEP se concentre essentiellement sur SipHash. L'implémentation permet quand même de changer plus facilement de fonction de hash.

De l'autre côté beaucoup de plateformes ont changé de fonction de hachage pour éviter le pire cas mais n'ont pas cherché à l'améliorer et sont restés aux listes chainées.

Il faut aussi savoir que le type dict de Python est un type "fondamental" dans le langage. Quand on écrit "x = 1", "x" devient la clé d'un dictionnaire. Ensuite, "print(x)" va chercher la valeur de x dans un dictionaire. Il existe un dictionnaire des variables globales, un dictionnaire des variables locales (note : souvent optimisé en utilisant une liste en interne), le passage de paramètres à une fonction peut aussi nécessiter une dictionnaire, etc. Les performances du type dict impactent donc fortement les performances globales du langage Python.

Perso, je garde un goût amer de toutes ces discussions sur les fonctions de hash. Pour moi, c'est bidon. Je trouve les attaques algorithmes très compliquées, comparativement à la facilité d'un DoS classique (en attaquant le réseau plutôt que l'application). Du genre, Spamhaus où un bug DNS a été exploité (flood UDP). Pour attaquer un site web, suffit de trouver une page de prendre longtemps à être calculée et demander au serveur de calculer plein de fois cette page.

C'est mieux que de publier le code source en 0-day.

Je ne suis pas d'accord. La sécurité se passe mieux quand c'est transparent. En l’occurrence, une faille dans la randomization de l'espace d'adressage n'est pas une régression en terme de sécurité, étant donné que le noyau 3.13 ne l'avait pas. C'est juste que la protection n'est pas efficace. Publier la faille (le code source de l'exploit) ne va mettre en danger quiconque.

Avec le code source de l'exploit, il serait plus facile de chercher de corriger la faille, mais aussi de réfléchir à une solution plus générale pour corriger le problème.

Pour la faille de sécurité "vmsplice", un correctif d'urgence avait été mis en place. Il bloquait l'exploit qui circulait, mais était insuffisant. Plus tard, avec plus de temps, un correctif complet a été écrit. La faille :
http://linuxfr.org/news/important-bug-de-s%C3%A9curit%C3%A9-sur-noyau-2617-%C3%A0-2624
(je ne me souviens plus des détails sur les différents correctifs.)

Et toujours d'après son texte il n'y a pas "une faille de sécurité" à corriger : il y en a des tonnes.

Selon Brad, il n'existe que deux options : aucune zéro ou GRSecurity. Ce raisonnement ne se tient pas. Il y a de bonnes raisons de pas utiliser GRsecurity : l'énorme patch est très intrusif et n'est pas intégré upstream. En conséquence, GRsecurity n'est pas utilisable directement sur RHEL, Debian ou OpenSuse. Quand des bugs sont corrigés, les distributions Linux fournissent des correctifs. Avec GRsecurity, il faut mettre à jour le noyau soit même, c'est très délicat. Bien sûr, il existe des personnes qui utilisent GRsecurity et sûrement des paquets tout prêt, mais c'est différent du point de vue de la responsabilité que d'utiliser des paquets fournis par une distribution Linux.

L'attitude de Brad n'est pas constructive. Les développeurs noyau ne veulent pas de son patch, car personne n'est capable de dire de relire son patch et parce qu'il tue les performances.

Je pense qu'il existe un juste milieu entre GRsecurity (lent mais sûr) et aucune sécurité. Comme je l'ai dit, les améliorations liées à la sécurité prises indépendemment ne sont pas efficaces, mais mises bout à bout, ça devient complexe d'écrire un exploit noyau.

Yep, et comme GrSecurity est libre, tout le monde peut faire le travail.

Il existe peu de gens qui ont des compétences en développement noyau. Seule une partie de ces développeurs sont sensibles à la sécurité. Il y a encore moins de développeurs noyau qui ont les compétences pour comprendre l'énorme patch Grsecurity. Autrement dit, à part Brad, je ne vois pas qui pourrait redécouper son énorme patch et l'intégrer petit à petit, en expliquant l'intérêt de chaque patch, argumenter, etc.

Brad Spengler n'a pas changé. Il se moque des améliorations liées à la sécurité dans le noyau Linux et insulte les développeurs noyau. Au lieu d'écrire un framework pour écrire des exploits noyau, il ferait mieux d'apprendre à communiquer avec les développeurs pour faire entrer ses grosses modifications GRSecurity dans le noyau.

Je pense que le travail de fond sur la randomization de l'espace d'adressage du noyau est une bonne chose. Aucune protection n'est infaillible, mais j'ai cru comprendre que plus il y en a, plus l'écriture d'un exploit "stable" (qui fonctionne sur plusieurs versions de Linux, différentes versions, architectures, etc.) devient complexe.

Un travail a été entamé par plusieurs développeurs pour cacher progressivement les adresses mémoires. Je doute que Linux 3.14 soit parfait, mais je suis sûr que ça ne peut que s'améliorer.

Les changements dans le noyau se font progressivement, pas à pas, et sans dégrader les performances.

Publier une vidéo sur Youtube sans fournir aucune information ne fait pas avancer le schmiblick. Pourquoi ne pas montrer clairement le code source et aider à corriger la faille de sécurité ? Sûrement pour se faire mousser et vendre son travail sur GRSecurity.

Un langage qui répond true à la question md5('240610708') == md5('QNKCDZO'), je ne pense pas que ça vaille la peine d'investir du temps dessus. En 10 ans, Facebook aurait eu le temps de réécrire son site web depuis zéro vu les ressources qu'ils ont.

Utiliser des threads est simple à programmer (si chaque requête n'utilise pas de ressource partagée), mais n'est pas performant pour gérer un grand nombre de requêtes concurrentes. Je m'attends à de meilleures performances avec un grand nombre de requêtes concurrentes (de beaucoup de clients différents).

Il existe différentes méthodes pour partager des données entre plusieurs processus, notamment la mémoire partagée. Dans le cas précis de numpy, je ne sais pas ce qui est le mieux.

J'ai déjà écrit un programme qui partage de la mémoire avec mmap, ça se fait facilement.

asyncio, c'est vraiment la killer-feature de cette nouvelle version. Ca pourrait à lui seul justifier que des projets emprisonnés dans Python 2.7 passent en Python 3! Sauf que … il existe un backport Python 2 !

Trollius n'est pas identique à Tulip. La syntaxe Tulip est plus simple et courante (yield from …/return …) que celle de Trollius (yield From(…)/raise Return(…)) :
http://trollius.readthedocs.org/#differences-between-trollius-and-tulip

Et puis, il manque tellement de choses à Python 2 …
http://haypo-notes.readthedocs.org/python2.html

Bien sûr, il est possible de programmer les bras attachés dans le dos en tapant sur les claviers avec les dents.

Il est bien connu qu'on s'occupera de la qualité du code et de la sécurité une fois que le projet sera terminé. Bon, le projet a débuté avec 6 mois de retard, le client a changé les spécifications et l'effectif est réduit, mais ne vous inquiétez pas, on va bientôt changer nos méthodes et se mettre à la qualité. Ah tiens non, le patron nous indique qu'il y a un nouveau projet à commencer (à terminer? boarf, quelle différence…) pour hier, avant que le projet actuel soit terminé. L'équipe sera coupée en deux, et les développeurs vont changer quotidiennement de projet. Si le projet est en retard, on augmentera la quantité et la durée des réunions. Pas d'inquiétude. Tout est sous contrôle.

Cette histoire est une pure fiction et n'a aucun lien avec la réalité. Toute ressemblance avec des personnes ayant réellement existé est purement fortuite

Salut, je ne sais pas si ça peut t'aider, quand je bossais pour INL/EdenWal, un collègue codait une GUI pour gérer une PKI : générer une autorité, créer un certification, le renouveler, le révoquer, télécharger un cerficat + clé publique de l'autorité, générer une CRL, etc. Le code Python se trouve par ici :
http://ufwi.org/projects/edw-svn/repository/revisions/master/show/trunk/src/nupki/nupki

NuPKI utilise OpenSSL.

C'est quand même curieux de réagir comme cela, tout le monde est en train de passer à Python 3, ils n'ont strictement aucune chance que le reste du monde reste à Python 2 pour leurs beaux yeux…

Les problèmes que pourraient introduire le passage à Unicode sont listés dans la page suivante :
http://mercurial.selenic.com/wiki/EncodingStrategy

Je pense que cette page est pessimiste, les problèmes peuvent être résolus l'un après l'autre, et pas tous d'un coup.

Soit il y aura un projet concurrent, soit il y aura un fork, mais clairement ils vont rater un virage.

Le projet Mercurial est très actif, maintenir un fork serait très chronophage. Il faut que la transition à Python 3 soit progressive et soit faite upstream.

Ouai, enfin moi [Twisted] est au cœur de mon projet

Je doute que ça vaille la peine de porter les projets actuels de Twisted à asyncio. Le portage risque d'être long et risqué (en terme de régression).

Asyncio vise plutôt les nouveaux projets, ou bien les projets qui utilisent une boucle d'événement compatible (tout sauf Twisted?? :-p).

Un peu pour les mêmes raisons, à savoir un manque chronique d'intérêt de la part des devs Twisted, voire une hostilité occasionnelle (cela se voit peut-être moins aujourd'hui, mais à une époque, notamment sur IRC, les devs Twisted étaient ouvertement hostiles à Python 3).

Pour information, j'ai fait deux tentatives de portage de Mercurial sur Python 3. Ma fork fonctionnait (dumoins avec les commandes simples). Mais pareil : vu la réaction très hostile, j'ai vite abandonné.

Le développeur principal semble carrément borné. Il est impossible de communiquer avec lui sur Unicode, il se bloque complètement. De mémoire, il m'a écrit un truc dans le genre "écoute, je suis développeur noyau, toi tu ne connais rien à UNIX, j'ai raison". Bon euh, j'ai quand même investi 3 années de ma vie à corriger des centaines de bugs Unicode dans Python 3, et je pense avoir quelques notions d'UNIX depuis le temps que je l'utilise (plus d'une dizaine d'années). J'ai proposé plusieurs solutions de transition (octets => Unicode) et des solutions pour que ça fonctionne avec Python 2 et 3. Je refuse de travailler avec des gens bornés et incapables de communiquer. J'ai passé mon chemin & basta.

Cette release pue le frenchy à plein nez.

PEP 428, a "pathlib" module providing object-oriented filesystem paths
PEP 442, improved semantics for object finalization: Safe object finalization

écrite et implémentée par Antoine

PEP 445, a new C API for implementing custom memory allocators: Add new APIs to customize Python memory allocators
PEP 446, changing file descriptors to not be inherited by default in subprocesses: Make newly created file descriptors non-inheritable
PEP 454, a new "tracemalloc" module for tracing Python memory allocations

écrites et implémentées par moi-même, la PEP 445 a été validée par Antoine, la PEP 454 validée par Charles-François. Je vous rassure, ils ont été super chiant, quand on écrit une PEP, les amis ne comptent plus ! :-)

PEP 3154, a new and improved protocol for pickled objects: Pickle protocol version 4

écrite par Antoine, implementée par Alexandre Vassalotti à l'occasion d'un Google Summer of Code.

new "selectors" module: High-level I/O multiplexing (surcouche à select, poll, epoll, kqueue)

écrite et implémentée par Charles-François

PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O: Asynchronous IO Support Rebooted: the "asyncio" Module, module aussi connu sous nom "Tulip" (version pour Python 3.3)

écrite par Guido van Rossum, implementé par Guido mais avec un grand nombre de contributeurs, validée par Antoine

Ça fait presque 40% des nouveautés majeures faites uniquement par les français, et les français sont impliqués dans 50% des nouveautés majeures. D'ici Python 3.5 voir Python 3.6, on a prévu de traduire les mots clés en français, puis de mettre du fromage dans la stdlib.

C'est bien comme ça, merci patrick.

Les développeurs Twisted ne semblent pas intéressés par un portage sur Python 3, sinon ils l'auraient déjà fait. De plus, Antoine Pitrou a fait un fork non officiel qui tourne sous Python 3.
http://twistedmatrix.com/pipermail/twisted-python/2011-October/024649.html

Twisted est ancien (plus de 10 ans ?) et repose sur un système de callback. Le module asyncio reprend les bonnes idées de Twisted (ex: transport et protocole) en s'affranchissant de la syntaxe "callback" difficile à déboguer et à relire.

En discutant, j'ai cliqué sur le bouton Envoyer au lieu de Prévisualiser, je n'ai pas eu le temps de finir ma relecture. J'ai vu la typo à posteriori, mais je ne vois pas comment éditer mon journal. Il va donc falloir que j'apprenne à vivre avec (soupir).

La véritable pomme de discorde concerne les installeurs. SourceForge a en effet commencé à inclure des logiciels tiers dans ses installeurs pour Windows, des logiciels qui sont, aux yeux de bien des internautes, des adwares.

Autrement dit : Sourceforge modifie les binaires .EXE pour Windows uploadés par l'équipe de Gimp ? Je trouve ça risqué d'un point de vue sécurité : SourceForge pourrait rajouter un virus, même involontairement. Et puis je doute que l'équipe de Gimp ait accepté dans les clauses d'utilisation que SourceForge modifie les binaires de l'installeur Windows :-(

Je suis encore étonné que Sourceforge soit utilisé. Ce site est bourré de pub et la navigation est plutôt laborieuse je trouve.