systemd-networkd sert à configurer les interfaces réseaux. Ca peut être pratique que cet outil gère l'option IP forward et le NAT. Par contre, l'article Phoronix ne parle pas d'une réimplémentation du parefeu ni d'outil pour manipuler iptables ou nftables. Extrait :
Also added on Tuesday was minimal firewall manipulation helpers for systemd's networkd.
Et puis bon, Phoronix n'est pas la meilleure source qui existe…
Le module distutils.version qui fait parti de distlib implémente cette PEP. C'est-à-dire qu'on peut valider qu'un numéro de version respecte une PEP, mais surtout comparer deux numéros de version.
Il est maintenant plus fiable de mettre à jour des modules dans un environnement virtuel géré par pip (le gestionnaire de modules Python de référence).
Vu la longueur de la PEP, on se rend compte de l'originalité dont font preuve les développeurs pour numéroter leurs logiciels !
A priori, le test compare des images dont la taille en octet est quasiment identique : "Images were first encoded with bpgenc at 25 QP/CRF. Everything else was matched to +/- 2.5% filesize.".
Je ne suis pas sûr que le temps de décompression soit pertinent vu que certaines décodeurs sont implémentés dans le navigateur web alors que d'autres sont implémentés en Javascript, du moins pour le cas précis de cette page web. Mais oui, les temps de compression et décompression m'intéressent.
Pour moi, le décodeur Javascript est plutôt un contournement temporaire en attendant que les formats WebP et BPG soient gérés nativement dans les navigateurs webs les plus populaires (Chrome, Firefox, Safari, IE). Chrome et Opera gèrent nativement les images WebP : http://caniuse.com/#feat=webp
Je crains que le principal frein à l'adoption du format BPG, notamment dans les navigateurs web, soit les sulfureux brevets. Je vois mal une société comme Apple ou Microsoft payer des brevets pour un gain discutable (taille des images). De plus, utiliser des codecs matériels pour HEVC dans un navigateur web peut poser de gros soucis de portabilité. Par exemple, le support H.264 dans Firefox semble encore incomplet sur plusieurs plateformes (Linux: Firefox sait utiliser GStreamer, Cisco paie la licence H.264 et fournit un codec binaire à Firefox, etc.). Sur ma Fedora 20 avec Firefox 32, je dois encore utiliser des lecteurs Flash pour regarder les vidéos Youtube (bien que https://www.youtube.com/html5 me dise que Firefox gère H.264 et WebM VP8, en pratique ça déconne), quelle tristesse…
Mais les images ne sont utilisées dans dans les navigateurs web. Stocker des photos au format BPG plutôt que JPEG sur une appareil photo numérique (APN) serait très intéressant pour pouvoir stocker beaucoup de photos sans trop rogner sur la qualité. Je ne parle pas des photographes amoureux de la technique qui stockent en RAW, mais le commun des mortels qui appuyent sur le bouton et ne vont jamais dans les menus régler la qualité du stockage des photos. Si HEVC est effectivement déjà supporté en hardware pour la vidéo, c'est tout à fait pertinent de réutiliser le hardware pour stocker également des photos. Il existe déjà des hacks pour les APN, par exemple CHDK pour Nikon. Voir aussi The Ultimate Custom Firmware For Any Camera Roundup (je doute que tous ces logiciels soient libres).
Salut, j'ai appris à programmer en C++ en codant sur le jeu Wormux sur lequel on a bossé à plusieurs. Le développement a duré plusieurs années. Problèmes rencontrés pendant le dev :
bibliothèque de jeu ClanLib qui subissait de lourde modifications internes, API instable
j'ai passé 3 mois à porter tout le jeu de ClanLib 0.6 à 0.7. Finalement, tout le jeu a été réécrit pour SDL
le moteur physique a été codé à partir de nos cours de physique au lycée : le moteur était plutôt bancal, instable et bogué
le réseau est arrivé très tard dans le jeu et fonctionnait mal sur Internet (bien en local avec une très faible latence)
on a passé une grosse partie du temps à s'occuper des aspects qui n'ont pas de lien avec le jeu directement : pile graphique, réseau, entrées-sorties, etc.
Si c'était à refaire :
Développer le réseau dès le premier jour
Penser le réseau pour Internet : latence importante (50 ms à 500 ms ?) et perte de paquet
Choisir une bibliothèque qui gère la majorité des aspects du jeu et qui est réputée stable : je ne sais quoi conseiller en 2014
Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.
Sourceforge n'est qu'un exemple parmi malheureusement beaucoup d'autres. Déjà que ça me les brises, je n'avais pas envie de dresser une liste exhaustive des sites Internet exigeant mon consentement pour utiliser ces cookies.
Bon allez, je lâche quelques noms :
*.google.* : petit bandeau qui ne propose pas directement de refuser les cookies
http://www.ibm.com/ : grosse popup TRUSTe (mal)… qui permet de configurer (bien!)
http://www.cisco.com/ : petit bandeau qui ne propose qu'une croix pour la cacher (et comment on les refuser !?)
http://slashdot.org/ : énorme popup qui prend tout simplement l'intégralité de la page, impossible de voir le contenu. Il est impossible de refuser les cookies à priori, on est obligé de cliquer sur "Accepter les Cookies" (mal). C'est exactement la même popup que sourceforge.net. L'image (drapeau français) vient de fsdn.com. Allez, j'accepte les cookies => redirection vers http://beta.slashdot.org/ qui m'affiche exactement le même bandeau. Dis moi, tu me prendrais pas pour un jambon par hasard ? 2e clic : grosse popup TRUSTe, woh putain…
www.free.fr : petit bandeau qui propose de configurer (bien)
Bien sûr, tu peux boycotter tous ces sites, mais je n'ai donné que quelques exemples. Si tu veux boycotter tous les sites qui affichent ces popups, bonne chance.
Ma principale critique est que dans la majorité des cas, on ne peut pas refuser les cookies d'un simple clic. Pardon, aucun site ne permet de refuser les cookies en un simple clic.
Et puis souvent, même en acceptant les cookies, on me repose la question plusieurs fois par mois, voir plusieurs fois par jour… Je suppose qu'il faut accepter le cookie qui permet de se souvenir qu'on accepte les cookies. Hein quoi ? Je m'y perds.
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.
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 !
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
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
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 264 ou 2128 ). 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.
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 !
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
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…
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.
# Journal approximatif
Posté par Victor STINNER (site web personnel) . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 7.
systemd-networkd sert à configurer les interfaces réseaux. Ca peut être pratique que cet outil gère l'option IP forward et le NAT. Par contre, l'article Phoronix ne parle pas d'une réimplémentation du parefeu ni d'outil pour manipuler iptables ou nftables. Extrait :
Also added on Tuesday was minimal firewall manipulation helpers for systemd's networkd.
Et puis bon, Phoronix n'est pas la meilleure source qui existe…
[^] # Re: Crédibilité ?
Posté par Victor STINNER (site web personnel) . En réponse au journal 4,3 millions d'euros volés à la plate-forme d'échange de bitcoins Bitstamp. Évalué à 2.
Bitcoin a un intérêt limité sans les plateformes d'échanges, non ? Il est nécessaire d'avoir confiance dans ces plateformes pour les utiliser.
# PEP 440 - Version Identification and Dependency Specification
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Gestion sémantique de version. Évalué à 10.
Pendant ce temps dans la communauté Python, un document écrit en mars 2013 normalise les numéros de version :
https://www.python.org/dev/peps/pep-0440/
Le module
distutils.versionqui fait parti de distlib implémente cette PEP. C'est-à-dire qu'on peut valider qu'un numéro de version respecte une PEP, mais surtout comparer deux numéros de version.Il est maintenant plus fiable de mettre à jour des modules dans un environnement virtuel géré par pip (le gestionnaire de modules Python de référence).
Vu la longueur de la PEP, on se rend compte de l'originalité dont font preuve les développeurs pour numéroter leurs logiciels !
[^] # Re: javascript rules
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 6.
Il manque la taille des images
A priori, le test compare des images dont la taille en octet est quasiment identique : "Images were first encoded with bpgenc at 25 QP/CRF. Everything else was matched to +/- 2.5% filesize.".
Je ne suis pas sûr que le temps de décompression soit pertinent vu que certaines décodeurs sont implémentés dans le navigateur web alors que d'autres sont implémentés en Javascript, du moins pour le cas précis de cette page web. Mais oui, les temps de compression et décompression m'intéressent.
Pour moi, le décodeur Javascript est plutôt un contournement temporaire en attendant que les formats WebP et BPG soient gérés nativement dans les navigateurs webs les plus populaires (Chrome, Firefox, Safari, IE). Chrome et Opera gèrent nativement les images WebP : http://caniuse.com/#feat=webp
Je crains que le principal frein à l'adoption du format BPG, notamment dans les navigateurs web, soit les sulfureux brevets. Je vois mal une société comme Apple ou Microsoft payer des brevets pour un gain discutable (taille des images). De plus, utiliser des codecs matériels pour HEVC dans un navigateur web peut poser de gros soucis de portabilité. Par exemple, le support H.264 dans Firefox semble encore incomplet sur plusieurs plateformes (Linux: Firefox sait utiliser GStreamer, Cisco paie la licence H.264 et fournit un codec binaire à Firefox, etc.). Sur ma Fedora 20 avec Firefox 32, je dois encore utiliser des lecteurs Flash pour regarder les vidéos Youtube (bien que https://www.youtube.com/html5 me dise que Firefox gère H.264 et WebM VP8, en pratique ça déconne), quelle tristesse…
Mais les images ne sont utilisées dans dans les navigateurs web. Stocker des photos au format BPG plutôt que JPEG sur une appareil photo numérique (APN) serait très intéressant pour pouvoir stocker beaucoup de photos sans trop rogner sur la qualité. Je ne parle pas des photographes amoureux de la technique qui stockent en RAW, mais le commun des mortels qui appuyent sur le bouton et ne vont jamais dans les menus régler la qualité du stockage des photos. Si HEVC est effectivement déjà supporté en hardware pour la vidéo, c'est tout à fait pertinent de réutiliser le hardware pour stocker également des photos. Il existe déjà des hacks pour les APN, par exemple CHDK pour Nikon. Voir aussi The Ultimate Custom Firmware For Any Camera Roundup (je doute que tous ces logiciels soient libres).
# Conseils d'un ancien programmeur de jeu
Posté par Victor STINNER (site web personnel) . En réponse au journal Dead Pixels Society. Évalué à 10.
Salut, j'ai appris à programmer en C++ en codant sur le jeu Wormux sur lequel on a bossé à plusieurs. Le développement a duré plusieurs années. Problèmes rencontrés pendant le dev :
Si c'était à refaire :
Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.
[^] # Re: Et la crémière
Posté par Victor STINNER (site web personnel) . En réponse au journal Marre des popups qui obligent à accepter les cookies. Évalué à 10.
Sourceforge n'est qu'un exemple parmi malheureusement beaucoup d'autres. Déjà que ça me les brises, je n'avais pas envie de dresser une liste exhaustive des sites Internet exigeant mon consentement pour utiliser ces cookies.
Bon allez, je lâche quelques noms :
Bien sûr, tu peux boycotter tous ces sites, mais je n'ai donné que quelques exemples. Si tu veux boycotter tous les sites qui affichent ces popups, bonne chance.
Ma principale critique est que dans la majorité des cas, on ne peut pas refuser les cookies d'un simple clic. Pardon, aucun site ne permet de refuser les cookies en un simple clic.
Et puis souvent, même en acceptant les cookies, on me repose la question plusieurs fois par mois, voir plusieurs fois par jour… Je suppose qu'il faut accepter le cookie qui permet de se souvenir qu'on accepte les cookies. Hein quoi ? Je m'y perds.
# libinput
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 7.
Je vous conseille la lecture de l'article http://who-t.blogspot.fr/2014/09/libinput-common-input-stack-for-wayland.html qui explique d'où vient le projet libinput et à quoi il sert.
[^] # Re: La vraie nouvelle du jour
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
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/
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.
[^] # Re: La vraie nouvelle du jour
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
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.
[^] # Re: La vraie nouvelle du jour
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 3.
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.
# Gestionnaire de source
Posté par Victor STINNER (site web personnel) . En réponse au journal Des nouvelles de LibreSSL. Évalué à 10.
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 !
# asyncio et Python 2 : Trollius !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Twisted 14.0.0. Évalué à 7.
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.
[^] # Re: Hardened !
Posté par Victor STINNER (site web personnel) . En réponse au journal Vulnérabilité locale dans le noyau Linux : 2.6.31-rc3 (2009) <= version <= 3.15-rc6 (CVE-2014-0196). Évalué à 6.
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
# Python
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche OpenJDK JEP 180: HashMap, collisions & attaques par la complexité. Évalué à 10.
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
longen C). Il a été montré qu'en pratique, on obtient seulement 256 fonctions de hashage différentes (au lieu de 264 ou 2128 ). 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
dictde 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.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 6.
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.)
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 7.
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.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 9.
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.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 10.
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.
# Ça reste du PHP
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche The Hack language : PHP avec un peu de typage statique. Évalué à 1.
Un langage qui répond
trueà la questionmd5('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.[^] # Re: asyncio et socketserver
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.4 est sorti avec 7 nouveaux modules. Évalué à 2.
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).
[^] # Re: Deux petites questions
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.4 est sorti avec 7 nouveaux modules. Évalué à 3.
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.
[^] # Re: asyncio vous emmène vers Python 3
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.4 est sorti avec 7 nouveaux modules. Évalué à 5.
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.
[^] # Re: Qui a fait ce code?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Encore un exemple de code spaghetti : Toyota. Évalué à 10.
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
# Nupki
Posté par Victor STINNER (site web personnel) . En réponse au journal python-easy-pki. Évalué à 2.
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.
[^] # Re: Twisted
Posté par Victor STINNER (site web personnel) . En réponse au journal Python 3.4 beta 1 est sortie. Évalué à 3.
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.
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.