Victor STINNER a écrit 1639 commentaires

La faille est également présente dans le noyau de test version 2.6.18 de RHEL5 (le patch introduisant la faille y a été backporté le 15 avril). Debian Sid propose le noyau 2.6.30.

J'ai testé l'exploit, mais il ne fonctionne pas sur ma Debian, car il a besoin de Pulse Audio (qui n'est pas installé chez moi). Il semble que l'exploit utilise 3 failles différentes :
* Faille noyau (tun)
* Bug (faille) Pulse Audio
* Bug dans la fonction personality() permettant de contourner la protection "mmap_min_addr" (adresse minimale qui peut être mappée). Par défaut, on n'a pas le droit de mapper une zone mémoire à partir de l'adresse NULL.

Pff, il est long ton exemple ! En Python 3.1, ton exemple est deux fois plus court (4 lignes contre 8 lignes) :
from urllib.request import urlopen
url = 'http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
with urlopen(url) as dlSavannah, open("what_is_dtest.pdf","wb") as f:
...f.write(dlSavannah.read())Avec le temps, les programmes Python deviennent de plus en plus court :-) Enfin, de plus en plus haut niveau (urllib est un niveau au dessus d'httplib).

En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême.

De quels messages parles-tu ? Si tu parles des exceptions : entre une traceback qui indique exactement où tu es (nom du fichier + numéro de ligne + ligne de code pour chaque fonction de la pile) et "Segmentation fault", j'ai fait mon choix :-)

... pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé

Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)

il faut re-apprendre toute l'API: A chaque ligne, je suis obligé d'aller voir la doc: Ouvrir un fichier, vérifier les permissions, récupérer un signal....

Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction. Exemples C => Python :
* open(), close() => os.open(), os.close()
* fopen(), fclose() => f=open(); f.close()
* sigaction(num, func, &oldfunc) => oldfunc = signal.signal(num, func)
* access(path, mode) => os.access(path, mode)

Et puis, la doc Python est plus agréable à lire que les manpages C je trouve. http://docs.python.org/library/

... ils parlent bien des pilotes et semblent suggérer que les pilotes Windows peuvent être réutilisés tel quel.

...
2) ils mentent, ils ont pompé du code libre ...

As-tu lu la dépêche jusqu'au bout ? « Il semble d'ailleurs que Tmax Window ait réutilisé du code de ReactOS, qui est distribué sous licence GPL, pour le support des pilotes Windows. »

Cette info provient de l'article Tmax Window Uncovered, section "Account of Actual Developer", qui lui même cite un article de blog en coréen.

Je ne vois pas en quoi c'est un mensonge de réutiliser un logiciel libre. Par contre, s'ils comptent en faire un logiciel propriétaire, réutiliser des bouts de code GPL va poser problème. Sinon, ils ont jusqu'à Octobre (allez, Novembre...) pour virer le code GPL.

- toujours faire auditer le code par des personnes extérieures

Il faut des personnes compétentes, en particulier pour ce bug : des personnes connaissant (très) bien les générateurs de nombres aléatoires... ce qui est très rare.

- passer tous les tests des compilateurs (et équivalent : valgrind...) sans aucun warning

AHEM. La faille a été introduite à cause d'un faux positif Valgrind...

- avoir un code très propre et bien documenté aux passages critiques
- avoir une API simple et claire

L'API OpenSSL est très claire (pas juste l'API publique, l'API interne également).

- avoir une batterie de test la plus large possible

Le problème dans le cas de Debian OpenSSL est que le générateur était parfaitement aléatoire, il passe tous les tests, même les plus complets. Le problème était celui de la graine, et il semble qu'aucun outil ne teste la qualité de la graîne : s'assurer que N générateurs génèrent N suites différentes. Même s'il existe un tel outil, il faut que l'outil pense à exécuter chaque générateur dans un processus différent... Or pour des raisons pratiques, on va préférer tout faire dans le même processus.

Le bug Debian OpenSSL est un cas très particulier et il n'existait pas de test pour détecter le bug. Maintenant, il faut espérer que l'histoire ne se répête pas.

PS : Hasard contient un outil pour tester que N générateurs génèrent N suites différentes. Je parlais d'un test utilisant fork(). Et bien il semble que mon outil ait trouvé un (nouveau) bug, différent. fork() est encore un autre cas :-/

J'ai recompilé OpenSSL après avoir réintroduit le bug. Les tests d'Hasard 0.9.6 sont finalement insuffisant. Le test "init" réutilise le même processus, et on obtient donc des suites différentes. Par contre, j'ai modifié les tests fork_xxx pour forker N fois (1, 2^15 ou 2^20, selon les options --slow et --very-slow). Avec N=2^15, le bug OpenSSL est détecté (presque à la fin, vers ~32.100 essais).

Vu que j'ai du écrire un test spécifique à ce bug, je me demande si demain on ne pourrait pas trouver un autre type de bug demandant également un test précis :-/

Hasard intègre de nombreux tests pour vérifier que N générateurs différents génèrent N suites différentes. En particulier, le programme python/test_hasard.py comporte les tests :
* init : crée 10 (par défaut), 2^10 (option --slow) ou 2^20 (option --very-slow) générateurs différents et vérifie que les nombres générés sont différents
* reseed : appelle la fonction reseed(), qui regénère la graîne d'un générateur, 10, 2^10 ou 2^20 fois en s'assurant que le générateur génère des suites différentes
* fork_* (~17 tests) : vérifie qu'après un fork les deux générateurs (procesus parent et processus fils) génèrent des suites différentes

J'avoue ne pas avoir testé la version OpenSSL mais je compte le faire. Je suppose que la suite "init" devrait trouver le bug très rapidement.

Il y a une longue liste noire pour ces tests, car les générateurs faibles (dont l'état interne ou la graine font 32 bits ou moins) échouent rapidement. Le générateur libc_rand (fonction rand() de la libc) échoue par exemple après moins de 100.000 tests. Je viens de lancer le test "init" et j'ai obtenu une collision après 55094 essais. Ceci signifit qu'un attaquant a un espèce de recherche très restreint. Les générateurs utilisés dans Hasard utilisent un état interne et une graine d'au moins 128 bits. Consultez l'article suivant pour la théorie sur le risque de collision :
http://fr.wikipedia.org/wiki/Paradoxe_des_anniversaires

Il existe des chipsets pour carte mère qui génèrent de l'entropie. Linux sait les utiliser et s'en sert pour /dev/random. Voir quelques informations par ici :
http://bitbucket.org/haypo/hasard/src/tip/doc/linux_random.r(...)

Si on ne dispose pas d'un tel chipset, il est également possible de générer de l'entropie avec un carte son, une carte wifi, une webcam, voir même une lavalamp (par contre, c'est breveté ça, si si !). J'ai des liens vers ce genre de projet sur la page d'accueil d'Hasard.

Ça serait plus propre que de réinventer la roue à chaque fois, avec plus ou moins de succès.

Les générateurs matériels ne servent pas aux simulations (ils sont bien trop lents), mais peuvent beaucoup aider pour la sécurité (ça permet de générer des certificats plus rapidement, car /dev/random est très lent sinon !).

Enfin, il existe aussi le démon EGD (et quelques variantes) qui peut également servir à distribuer de l'entropie de tout le monde à partir de n'importe quelle source.

*PAN*

Utilise "zero", "one" ou "counter". Le premier ne génère que des zéros, le second que des uns, et le dernier est un simple compteur :-p À force d'avoir la blague à chaque fois, je me demande si je ne vais pas prévoir le coup en ajoutant un générateur « Debian ».

Il me semble qu'il y a plusieurs développeurs VLAN francophones (d'ailleurs, le projet ne serait pas français à la base par hasard ?).

Ouvrir un rapport de bug serait une initiative un peu plus constructive...

Voici l'explication : J'ai un énorme logiciel (en C AINSI) qui génère une suite de librairie (une 10aine) statique (en mode release, les librairies tournent aux alentour de 40Mo), et une suite de binaire (environ 500), linké avec toute les librairies en statique.

Est-ce qu'il ne faudrait pas commencer par là ? Ne pas compiler en statique, mais utiliser des bibliothèques dynamiques.

odict permet de parcourir les clés et valeurs dont leur ordre d'insertion, ce que ne permet pas le type dict (qui n'est pas ordonnée : l'ordre dépend de l'algorithme de hachage). Tu trouveras plus d'explication sur odict dans la PEP (citée au début de la dépêche) :
http://www.python.org/dev/peps/pep-0372/

Je n'ai pas compris si tu demandais si c'était possible ou bien que tu préfères le formatage avec %. En Python3, ça donne : "{prénom} {nom} a {age:03}".format(prénom="victor", nom="stinner", age=26) ou bien
"%(prénom)s %(nom)s a %(age)03d" % {'prénom': "victor", 'nom': "stinner", 'age': 26} Les deux donnent le résultat « victor stinner a 026 ». Perso je préfère largement format, car avec % on peut facilement oublier le suffixe "s" (en particulier pour les traducteurs), et la syntaxe des arguments est plus simple.

Les arguments pour/contre format et % ont déjà été discuté dans le journal http://linuxfr.org//~cho7/27909.html

PS : Python3 accepte les accents dans le nom des symboles ;-)

Y'avait pas la fonction log en base 2 ?

Il est possible d'utiliser math.ceil(math.log(abs(x + 1)) / math.log(2)), mais tu vas rapidement perdre en précision car ça utilise des nombres flottants de taille fixe. Le type int de Python3 a une taille illimitée et peut faire plusieurs milliers/millions de bits.

Exemple :x=2**100-1; math.ceil(math.log(abs(x+1)) / math.log(2)), x.bit_length()
x=2**100; math.ceil(math.log(abs(x+1)) / math.log(2)), x.bit_length()
donne (100, 100)
(100, 101)
À partir de 100 bits, la fonction utilisant math commence déjà à renvoyer des résultats faux.

Firefox 3.5 supporte maintenant nativement les vidéos en Ogg/Theora et le son en Ogg/Vorbis. Anciens articles qui en parlent :
http://mozillalinks.org/wp/2008/07/native-ogg-vorbis-and-the(...)
http://mozillalinks.org/wp/2007/06/firefox-3-to-feature-nati(...)

La place d'Ogg dans le format HTML5 semble faire controverse :
http://en.wikipedia.org/wiki/Ogg_controversy

Ceci va être très bénéfique à la démocratisation de ces codecs, et Wikipédia va sûrement rajouter en une couche ;-)

La dépêche proposée ne parle pas de politique (alors que le billet de blog ThePirateBay en parle). Elle ne parle pas non plus du procès en cours dans lequel est impliqué ThePirateBay.

Perso, je ne sais pas si ça a un rapport avec le libre ou pas. Je ne faisais qu'évoquer une remarque d'un des modérateurs... Bon ok, j'ai aussi un peu de mal à voir le rapport avec le libre.

Peut-être qu'en reformulant le texte pour expliquer le contexte (politique, procès), la dépêche aurait plus de chance d'être acceptée.

Il faudrait aussi clarifier cette histoire de conditionnel / rachat futur ou présent ? Le titre de la dépêche proposé est « The Pirate Bay vendu pour 5,5 M€ » (vendre au passé), or le rachat n'a pas encore eu lieu.

Il y a une grosse différence entre « ThePirateBay.org racheté » et « Une société suédoise d'informatique va racheter »... Le rachat n'a pas encore eu lieu et est soumis a une sacré condition : « L'acquisition ne sera définitive qu'une fois que Global Gaming Factory X se sera assuré que ce qu'elle a acquis peut être utilisé de manière légale et appropriée ».

À mon avis, le rachat de ThePirateBay est bidon. C'est un gros coup de pub juste pour mettre en avance la seconde information (rachat de Peerialism, d'ailleurs c'est quoi cette histoire de nouvelle technologie de P2P ?). Les gens derrière ThePirateBay se sont toujours vanté de violer les droits d'auteur en faisant la nique aux majors. Ça m'étonnerait qu'ils changent du tout au tout, même pour une telle somme.

Tout ça pour dire que je me suis exprimé contre la publication de la dépêche. Et puis de toute façon, ça n'a aucun rapport avec le libre. LinuxFR est pour le libre, mais pas la violation du droit d'auteur !

Je voulais écrire une dépêche sur python 3.1 mais je n'en ai pas eu le temps (très pris ce week-end). Je vais compléter et corriger la dépêche proposée.

« Selon le tabloïd britannique « Daily Mirror », la star aurait subi une batterie de cinquante tests, exigés par les assurances, pour prouver qu'il était capable de remonter sur scène. » (début mars dernier)
source : http://www.20minutes.fr/article/308199/Culture-Michael-Jacks(...)
source originale : http://www.mirror.co.uk/celebs/news/2009/03/04/michael-jacks(...)

Les concerts étaient estimés à 50 millions de livres (en mars, selon le Daily Mirror), voir 100 millions de livres (selon l'Evening Standard, aussi en mars).

Parce que bon, il avait annoncé son grand retour et les billets ont du se vendre à prix d'or ! Sur ebay, je vois des billets entre 150 et 1500€. Et puis, c'est dans son style, le mort vivant.

Le safe-mode est la seule tentative sérieuse de faire de php (l'interpréteur), un environnement d'exécution un tant soit peu adapté à son usage.

La seule ? Suhosin et suPHP c'est du vent ?
http://www.hardened-php.net/suhosin/a_feature_list.html
http://www.suphp.org/

De très nombreuses bibliothèques de calculs reposent sur BLAS et LAPACK dont les implémentations de références sont écrites en Fortran. C'est du code éprouvé depuis une treinte d'années, alors pourquoi y retoucher ? Il suffit d'écrire un petit surcouche pour les utiliser dans Python / Java / ...

Si je me trompe pas, numpy utilise par exemple BLAS et LAPACK.

Pendant ce temps, PHP 5.3 se prépare. À ce que j'en ai lu, cette une petite révolution dans PHP (en attendant la grosse, PHP6 qui passe à Unicode, enfin !).
http://www.nexen.net/actualites/php/17807-php_5.3_:_le_tour_(...)

Je reste assez perplexe vis à vis de la syntaxe choisie pour les espaces de nom, et encore plus sur la nécessité de l'instruction goto. Pourquoi ne pas plutôt avoir introduit le try / finally (comme en Java, Delphi ou Python par exemple) ?
http://www.php.net/manual/fr/language.namespaces.php
http://www.php.net/goto

Bon, il est vrai que l'utilisation d'une BD xkcd dans la documentation de GOTO le rend plus crédible.