Victor STINNER a écrit 1639 commentaires

Il ne faut pas forcer un charset, il faut juste le spécifier explicitement s'il est différent du charset par défaut. Python utilise ASCII par défaut et on peut changer ça avec « # -*- coding: utf8 -*- ». XML utilise utf8 par défaut, et on peut un spécifier un autre avec <?xml version="1.0" charset="iso-8859-1" ?>.

Au SSTIC 2008, on a eu une super présenter sur un banker (réseau mafieux visant à extorquer des l'argents par des banques en ligne) :
http://actes.sstic.org/SSTIC08/Autopsie_Observations_Banker/

En quelques : un troyan (Windows) s'installe la machine de la victime, le troyan se connecte en Peer to Peer au réseaux de robots (botnet), lorsque la victime va sur le site de sa banque, la page de login est remplacée par celle du troyan...

Le pire est que dans la conclusion, il est dit que le site est toujours en activité ! Ils sont vraiment très bien organisé et vu les frais de fonctionnement, je pense que leur arnaque marche très bien.

Hum, ça va être difficile de donner une URL de la vidéo étant donné que ce site utilise le protocole RTMP (Real Time Messaging Protocol) pour récupérer le contenu. Je vois un flux sur le port 1935 vers la machine 208.78.224.201. Wireshark ne semble pas connaître ce protocole...

T'as regardé ma conférence ? PyPy s'occupe de traduire l'interprète Python écrit en Python vers du C, LLVM, CLI, bytecode Java, ... En gros, en convertit du Python en C (ou LLVM ou ...). En détail, le noyau dur de PyPy est écrit en RPython, donc on ne peut pas compiler un programme Python quelconque en C. Par contre, y'a la compilation à la volé qui arrive doucement et promet de gros gains de performances !

Je dirai surtout que le projet PyPy est fort prometteur. Récemment ils parlaient, dans le blog PyPy status, de virer le GIL (Giant Interpreter Lock), et ce de manière optionnel !

Lit la partie "NOTES" de la page de manuel de la fonction rand(). Extrait : « Ceci n’est pas le cas avec les anciennes implémentations ...) où les bits de poids faibles n’étaient pas « aussi aléatoires » que ceux de poids forts ». En gros ça donne un truc du genre :
http://www.random.org/analysis/dilbert.jpg

Effectivement, en anglais le mot « hazard » fait plutôt peur (ex: biohazard). Peut-être que le nom est mal choisi. Au début j'avais choisi « random », mais c'est comme qui dirait un peu trop courant :-) J'ai pensé mettre le logo « biohazard » sur la page du projet, mais je crains que la blague ne soit pas comprise et qu'au contraire ça porte encore plus à confusion :-) J'ai pris un mot français pour continuer ma série Hachoir, Fusil, etc. :-) Bah au pire, je peux changer le nom du projet, si ce n'est que ça...

Hum, je ne comprend pas ta prose. Est-ce de l'humour ou de la poésie ? En particulier :

Je suppose que ENT est un outil dédié à la prédiction du cours des actions d'Autodesk.

Euh, est-ce que signifie qu'ENT n'est pas fiable ? Si tu as d'autres propositions, je suis preneur. Je pense que je vais utiliser Diehard(er) et ses copains. Là j'ai pris ENT car c'est le premier auquel j'ai pensé et qu'il est simple à utiliser.

Au passage l'histoire de la naissance du géant fait en LaTeX est une curiosité mémorable! Sacré Bacula! La pompe à fric procure la sécurité des données ...

Rien compris. C'est qui/quoi le géant fait en LaTeX ?

Je vais essayer de répondre à toutes les critiques ou questions dans les commentaires.

Effectivement, il y a globalement deux usages des générateurs de nombres pseudo-aléatoires : les simulations et la sécurité. Je ne connais pas trop les besoins en simulation, je dirai que l'algorithme doit être rapide. Tandis qu'en sécurité, on recherche un générateur le plus fidèle possible à un générateur réellement aléatoire, tant pis s'il est lent (ex: /dev/urandom vs /dev/random).

OpenSSL et libgcrypt ont d'excellents générateur pour la sécurité, mais n'utilisent pas de base commune de code. C'est dommage car un bug impactant les deux bibliothèques ne sera pas forcément corrigé dans les deux. De même niveau fonctionnalité, si on rajoute une nouvelle source d'entropie dans l'une, l'autre ne saura pas l'exploiter.

Mon idée serait donc de concentrer les efforts pour factoriser le code et donc avoir un maximum de sources d'entropie, beaucoup d'algorithme, et surtout un code bien testé. Pourquoi ne pas réutiliser GSL (ou autre) ? Je pense que le problème est qu' « on » n'a pas envie de tirer une grosse dépendance juste pour un sous-ensemble d'une bibliothèque. Maintenant si Hasard devient aussi gros qu'OpenSSL ou GSL, retour à la case départ :-) La licence BSD et un code écrit en C avec de nombreux bindings pourrait aider à l'intégration dans les autres projets.

Au sujet de ma phrase « Je pense donc récupérer les meilleurs morceaux d'OpenSSL, libgcrypt, et autres (ex: GSL) pour faire une bibliothèque dédiée. Puis en suite, propose à ces projets de réutiliser mon code. », je me suis mal exprimé. Le but est de permettre à OpenSSL d'utiliser les meilleurs bouts de libgcrypt, et inversement !

Bien sûr, il y a des problèmes de licence. J'ai contacté l'auteur de Mersenne Twister pour savoir si je peux utiliser la licence BSD et il m'a dit pas de problème. ISAAC est aussi compatible BSD (c'est dans le domaine public !). Pour RANDU, Park-Miller et drand48, je n'ai finalement réutiliser que des constantes, et je pense qu'elles sont dans le domaine public vu combien elles sont répendues.

Niveau sécurité, Hasard n'est pas prêt pour générer des clés SSH ou certificat X.509. Les algorithmes implémentés ne sont pas sûrs et le code n'est pas assez testé. J'ai implémenté les algorithmes libres trouvés sur Internet. D'autres viendront plus tard. C'était un peu une preuve de concept pour savoir si ça peut intéresser du monde. J'aimerai -si possible- réunir le meilleur des deux mondes, simulation et sécurité, pour factoriser les efforts.

J'ai regardé GSL vite fait. Cette bibliothèque ne s'occupe pas d'initialiser la graine du générateur (elle initialise à zéro), or c'est le point le plus critique ! J'ai regardé l'implémentation de Mersenne Twister et on peut seulement injecter 32 bits d'entropie, alors que ma bibliothèque utilise 4*32 bits d'entropie (et encore, je me dis que ça fait peu, faut voir). De plus, il n'y pas de fonction pour générer un boolean par exemple.

Côté positif, GSL a de nombreuses fonctions pour lire et restaurer l'état d'un générateur. C'est très intéressant. J'avais commencé à coder ça dans libhasard, mais je n'ai pas réussi à me décider sur la manière de le faire. GSL a également plus d'algorithmes : ranlux, ranlxs, cmrg, mrg, taus, gfsr4, bsd, libc5, glibc2, 3 variantes de Mersenne Twister, ... Maintenant, je pense que je pourrai toujours rajouter des algorithmes après, mais je veux surtout une base solide ;-)

Pour répondre franchement, je ne connaissais pas GSL, ni Boost Random, ni le 3e lien. D'ailleurs, il semble qu'OpenSSL, libgcrypt et Wormux ne les connaissent pas non plus :-) C'est justement le constat auquel je suis arrivé : chacun recode sa bibliothèque dans son coin. Selon moi, la génération de nombres pseudo-aléatoires est un problème suffisamment complexe pour qu'il mérite sa propre bibliothèque.

Je pense donc récupérer les meilleurs morceaux d'OpenSSL, libgcrypt, et autres (ex: GSL) pour faire une bibliothèque dédiée. Puis en suite, propose à ces projets de réutiliser mon code. Le but serait de concentrer les efforts pour obtenir un code de meilleur qualité que du code que chacun écrit dans son coin.

Maintenant, peut-être qu'effectivement il existe déjà une bibliothèque comme celle que j'essaye d'écrire, mais je ne suis pas au courant. Je vais voir les URLs que tu as postée, merci :-)

Ou alors RTFM ! ;-) L'aide est disponible dans le menu principal et durant une partie (échappe => clic sur aide).

Netscape, stunnel, l2tpd, ClamAV, serveur NFS, Kerberos, les implémentations du protocole TCP, etc. ont tous eu leurs lots de bugs dans leurs générateurs de nombres pseudo aléatoires. Plus récemment, c'est Bind et le serveur DNS de Microsoft qui ont eu des soucis. Encore plus récemment, c'est carrément des bugs dans les générateurs de Linux et de Windows qui ont été trouvés...
http://www.haypocalc.com/blog/index.php/2007/12/02/96-bugs-g(...)

J'avais regardé un peu pour BIND8, et en fait l'implémentation du double générateur à base registre à décalage était correcte, mais le développeur s'était trompé en recopiant un des deux polynômes utilisés (du livre de Bernstein). Oups :-)

Bon, ok, le bug openssl est un peu plus critique (quoique, TCP et Kerberos, on s'en soucie un petit peu quand même) car on se croit protégé derrière une armée d'algorithmes et de théories de mathématiques... Sauf que l'erreur est humaine et personne n'est à l'abri d'un bug.

Pour ceux qui comme moi lisent les dépêches linuxfr en diagonale, il faut bien comprendre que Peerfuse est encore en gros chantier. Pour l'instant, il n'y aucune sécurité : aucun contrôle d'accès (on peut lire n'importe quel fichier sur le disque dur) et code peu testé. Cette version est destinée aux développeurs qui veulent contribuer, pas aux gens qui veulent partager leurs fichiers.

Contrairement à SSL et SSH qui ont un protocole connu avec une négociation en clair (ex: le serveur SSH annonce sa version dans une bannière en clair), Freenet n'a pas d'annonce. Il est donc facile de distinguer SSL/SSH de Freenet. De plus, SSL est essentiellement utilisé sur TCP/443 et SSH sur TCP/22, alors que Freenet utilise des ports UDP aléatoires.

J'avais écrit un script de quelques lignes pour calculer l'entropie (des symboles de 8 bits) de messages Freenet, et il était assez flagrant que Freenet a l'entropie la plus élevée (en comparaison avec HTTP ou HTTPS). L'entropie minimale de 1000 paquets était de -de mémoire- de 6,3 sur 8, alors que les autres protocoles avaient des valeurs bien plus faibles (pour les minimums en tout cas). Ça veut dire que Freenet cache extrêmement bien les discussions. Mais ça peut aussi être un point faible.

J'ai lu « stéganographie » dans un autre commentaire : ok, mais l'entropie du contenu risque d'être toujours très élevée.

À mon avis, il est simple de développer un IDS pour détecter les utilisateurs utilisant Freenet. D'ailleurs, Freenet c'est du P2P, c'est-à-dire qu'il y a beaucoup de traffic dans les deux sens, alors qu'habituellement c'est pas du tout équilibré (upload vs download). Et je pense qu'un chinois qui utilise Freenet n'aura pas besoin de justifier l'utilisation qu'il en fait, il est forcément coupable.

(x) Arbre GIT des sources de noyau (branche de Torvald) :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

(x) Schéma des chaînes Netfilter par xkr47 :
http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/

(x) Schéma de Netfilter par Jan Engelhardt :
http://jengelh.medozas.de/images/nf-packet-flow.png

(x) J'avais aussi fait un schéma d'autotools (rien à voir :-)) pour ceux que ça intéresse :
http://www.haypocalc.com/blog/index.php/2007/07/05/57-schema(...)

Je pense que le site web s'est fait infecter. L'URL /favicon.ico pointe effectivement sur une page HTML qui contient du Javascript obfusqué. Il y a un lien clair vers le site smsrate.ru : il y un ifame et le javascript sert à rajouter deux iframe vers le même site. Dans ce forum on trouver des gens proposant de gagner de l'argent avec smsrate.ru :
http://rbforum.ru/viewforum.php?f=7

Selon la page about.html du site smsrate.ru, le principe est que les internautes envoient un SMS avec un code pour voter pour un site qui est inscrit dans au service smsrate. Euh, je trouve ça super bizzare quand même.

Quelqu'un a contacté les développeurs de Puppy Linux ?

Contrairement à une idée reçue, on peut patcher un OS n'utilisant pas de support accessible en écriture. La différence est que l'attaque ne sera pas persistance. Il est tout à fait possible d'injecter du code dans un noyau en cours de fonctionnement (ex: un module), dans Apache, dans Firefox, etc.

Effectivement, c'est très laid ! Je viens de finir Mario Galaxy sur Wii... il est trop beau ce jeu :)

Metallica c'est bien le groupe est qui à l'origine de la chute de Napster, le premier logiciel de P2P non ?
http://en.wikipedia.org/wiki/Napster

Salut, j'avais écrit un article qui donne un usage original de code.google.com : recherche les mauvais usages de memset(). http://www.haypocalc.com/blog/index.php/2007/10/27/84-analys(...) code.google.com est le seul à supporter les expressions réguluères, dommage.

Pour ceux qui ne connaissent ni PC SOFT, ni WinDev, je leur conseille de lire mon petit article :
http://www.haypocalc.com/blog/index.php/2007/11/07/83-pc-sof(...)

Effectivement, comme le souligne Earered, il y a une controverse sur l'utilisation du terme « langage de cinquième génération » (L5G), particulièrement dans l'article WinDev (voir la page de discussion Discuter:WinDev). À l'heure actuelle, il n'y a plus de mentionde génération du langage. En fait, il n'y a jamais eu de controverse, d'ailleurs oubliez ce que j'ai dit (fixer mes yeux, vos paupières sont lourdes...) :
http://fr.wikipedia.org/w/index.php?title=PC_SOFT&diff=2(...)

Il y a d'autres polémiques comme les performances d'HyperFile (cf. mn autre commentaire plus bas).

Si vous souhaitez participez aux débats sur Wikipédia, merci de rester objectif et courtois.

Il y a une guerre d'édition en ce moment. Tu trouveras plus de détails dans le Wikifeu :
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Wikipompiers/Feu(...)
et dans la page de discussion : Discuter:HyperFile

Je n'ai jamais installé ni utilisé HyperFile, je ne pourrai donc pas te répondre pour ton histoire d'installation. Demande plutôt au support PC SOFT ou dans des newsgroups et autres forums.

Malheureusement, l'historique ne porte que sur 4 mois, ce n'est pas encore très intéressant pour regarder la tendance d'un article. Dans un an, ça commencera à être intéressant :-) Sinon, est-ce qu'il existe une liste des articles les plus consultés ?

Bon sinon, on voit effectivement l'agitation de l'article HyperFile en ce moment.

J'ai déjà été en contact avec un admin qui était branché sur un fournisseur d'accès, son conntrack contenait 140.000 entrées... De quoi faire quelques parties. Après on pourrait filtrer, genre ne montrer que les connexions illégales genre eMule :-p En même temps, pour avoir longtemps joué au jeu original, je peux dire qu'il est très dur et qu'on meurt rapidement si on ne fait pas attention aux coins. D'ailleurs, il y a pas mal de passages secrets...