gc a écrit 2109 commentaires

et les vieux cons qui s'occuperont de leur progéniture, n'en parlons pas.

rien à rajouter

et bien consensuel.. un bisounours n'aurait pas mieux dit ! :)

Le truc c'est que l'évolution technologique qui permet la copie numérique "gratuite" des données, et la difficulté (l'impossibilité ?) de la protection anticopie rendent sa prédiction inéluctable, à mon avis. La seule solution serait d'avoir des protections "dures" dans le silicium à la TCPA, mais le public n'est pas encore "prêt" pour cette renonciation de liberté, je pense. Mais pour combien de temps encore ? Au bout d'un moment, on utilisera probablement le même argument que pour le fichage génétique : "vous comprenez, c'est pour lutter contre <insérez l'ennemi de la société du moment en question>" et hop.

De toutes façons, tu ne pourras jamais empêcher que des gens fassent du tunneling (sur HTTP, simple) pour faire passer n'importe quoi / n'importe quel protocole, pour peu qu'ils puissent installer un relai sur un serveur à eux sur le net.

Poste_de_travail <=> Serveur_relai_qui_va_bien(80) <=> Serveur_cible(n'importe quel port)

Pour peu qu'on ait un serveur_relai_qui_va_bien un peu bien foutu, n'importe quel protocole (bon, sur TCP) passe. Une "politique de sécurité" ne pourra que tenter de détecter ce genre de chose, mais si le relai est bien foutu, c'est très difficile à détecter.

La seule solution c'est de faire signer des chartes informatiques aux utilisateurs, et qu'ils soient pleinement responsables en cas de non-respect de cette charte.

Sur le premier lien, on peut voir qu'actuellement en Albanie il y a 19,802 participants, ce qui est à peu près le double de l'Allemagne, le triple de la France ou du Royaume-Uni... :)

y'en a sur le site on dirait

http://attal.sourceforge.net/base.php?langue=en&page=gra(...)

c'est pas beau :)

MESSAGE: Connection refused

Soit tu t'es trompé de port, soit ton mysql n'écoute pas sur TCP/IP (tu peux aussi avoir un firewall qui fait ça mais c'est rare). Tu es peut-être dans ce cas :

http://dev.mysql.com/doc/refman/5.0/en/connector-j-usagenote(...)

Non, bien sûr que non, la sécurité d'openssl ne repose pas sur un bloc de mémoire non initialisé, mais bien sur une bonne source de random (/dev/random par exemple, mais c'est surement un peu plus complexe et il y a surement plusieurs facons de faire). Ils ont juste trouvé malin d'utiliser ça aussi en se disant "ca ne peut pas faire de mal, et peut-etre du bien, donc on le fait". On voit aujourd'hui les conséquences possibles d'un geste aussi anodin à l'époque.

Non. Pour schématiser, OpenSSL se sert de plusieurs sources de random : entre autres (probablement), une était une zone de mémoire non initialisée, une était /dev/random, une était le PID ; les deux premières partagent le même chemin de code ; au lieu de corriger uniquement le premier truc ce qui faisait gueule valgrind (avec raison), le patch corrige au niveau au-dessus, et supprime du coup à la fois l'utilisation de la zone non initialisée et /dev/random. Au final il ne restait plus que le PID comme random, et l'espace de clés générées était donc extrêmement limité.

"windows était trop gros pour tenir dans 1 giga, on a du changer le hardware et mettre une SD de 2 gigas pour faire tenir windows et office"

lol !

Merci pour la distro !

Au passage, j'ai entendu que Mandriva ne nage pas forcément dans une montagne de cash. Si comme moi, vous utilisez depuis longtemps, et vous vous dites depuis un certain temps que vous pourriez peut-être acheter un des produits pour les soutenir, c'est peut-être un chouette cadeau d'anniversaire à leur faire :)

Debian a choisi de communiquer intensément, dans la tradition d'"on ne cachera pas les problèmes".

Ce n'est pas par choix : une fois qu'une faille comme cela est découverte par quelqu'un (hors Debian) qui choisit d'en parler, Debian a l'obligation d'en parler et même intensément, pour ne pas compromettre encore davantage ses utilisateurs, et du coup complètement se décribiliser/ridiculiser.

Pas très intelligent de mettre dans le serveur ssh un détecteur de clés pourries, pour désactiver les serveurs potentiellement compromis ? Ça pourra au contraire potentiellement sauver la vie de nombreux admins..

Oui, complètement. D'autant plus que le contexte est le problème à debugger des programmes utilisant openssl avec valgrind à cause de cela. Donc il répond bien que pour faciliter le debug "des applications utilisant openssl", ce patch ne devrait pas faire de mal. Le tort est vraiment partagé.

Non, le problème vient bien de la suppression des deux lignes MD_Update. Je t'ai mis le diff de etch "d'origine" ici si tu veux voir, il n'y a aucune activation particulière de purify.

http://zarb.org/~gc/t/openssl_0.9.8c-4etch1.diff.gz

- Premièrement les mainteneurs Debian ont demandés si c'était normal que le pool d'entropie ne soit pas initialisé à la création. Ce à quoi l'équipe OpenSSL a répondu que pour le debug ils pouvaient initialiser le pool.
- Deuxièmement les mainteneurs Debian ont ont retirés toute possibilité d'ajouter de l'entropie à ce pool (c'est à dire qu'il ne se sont pas contenter de l'initialiser, maisqu'ils l'ont vérouillé à une valeur connue), enlevant ainsi 99% de l'aléatoire dans la génération de clefs.


Je ne suis pas d'accord avec ton interprétation de la réponse et du patch. Relis bien tout le thread en question : le mainteneur Debian quote les deux lignes qu'il souhaite supprimer, et il est même très prudent : « But I have no idea what effect this
really has on the RNG ». Un des mecs de l'équipe de développement d'OpenSSL répond : « If it helps with debugging, I'm in favor of removing them. ». Il répond à la demande de suppression des deux lignes (ce qui deviendra exactement le patch), pas à la question en rapport avec la non initialisation du buffer. Donc à l'erreur consistant à supprimer toute entropie au pool. Il n'a pas vu l'erreur lui non plus !

Pour moi, le mainteneur Debian n'a rien à se reprocher quant à son comportement. Il a fait une énorme boulette, mais il l'a faite dans les règles de l'art : avec des doutes, et en demandant upstream. Si upstream dit que c'est bon, eh bien voilà, les torts sont largement partagés.

je ne sais pas vraiment s'il y a un intérêt pour le libre à fournir facilement une série de jeux libres pour Windows, qui seront en plus en moyenne de bien plus mauvaise facture que les jeux typiques pour Windows.. les utilisateurs les trouveront pas top, vont les confondre avec du shareware, et ne seront pas sensibilisés au libre et aux problèmes du monopole de Windows sur les PCs.

(après, on peut le faire sans intérêt pour le libre, bien sûr - mais du coup la pertinence d'une réjouissance linuxfrienne me semble plus limitée)

ce bug est énorme dans ses implications !

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

affecte Debian Etch, testing depuis un bon bout de temps (date de 2006-09-17 dans sid comme déjà dit) ; Ubuntu 7.04 (Feisty), 7.10 (Gutsy), 8.04 LTS (Hardy).

j'ai essayé de regarder rapidement la raison du bug ; appremment à l'origine, un bug a été ouvert pour faire taire valgrind sur l'utilisation de mémoire non initialisée :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516

ça a fini dans sid en septembre par :

-- openssl-0.9.8c.orig/crypto/rand/md_rand.c
+++ openssl-0.9.8c/crypto/rand/md_rand.c
@@ -271,7 +271,10 @@
        else
            MD_Update(&m,&(state[st_idx]),j);
            
+/*        
+ * Don't add uninitialised data.
        MD_Update(&m,buf,j);
+*/
        MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
        MD_Final(&m,local_md);
        md_c[1]++;
@@ -465,8 +468,10 @@
        MD_Update(&m,local_md,MD_DIGEST_LENGTH);
        MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
#ifndef PURIFY
+#if 0 /* Don't add uninitialised data. */
        MD_Update(&m,buf,j); /* purify complains */
#endif
+#endif
        k=(st_idx+MD_DIGEST_LENGTH/2)-st_num;
        if (k > 0)
            {

je ne comprends pas spécialement ce code, mais je soupçonne que ça a évité d'appeler MD_Update dans un cas où "buf" était non initialisé, mais *aussi* dans un cas où "buf" était initialisé avec du bon random, qui garantissait justement la sécurité des clés créées..

ce qui m'étonne c'est que le mainteneur Debian qui a commité ce patch est probablement quelqu'un avec de grandes connaissances en sécurité ; hors dans ce domaine, il faut faire très attention à la source de random pour garantir la sécurité.. quand on fait un changement dans ce domaine il faut faire très attention ; maintenant c'est beaucoup plus facile de le voir après coup.. ce devait être tout de même très subtil.

t'as un navigateur qui plante quand il ouvre des sites pourris.. ?

tu peux préciser le rapport avec GTK+2 ? et en particulier, ce que GTK+2 ne fait pas pour avoir du single window dans gimp ?

L'approche est différente. Dans pas mal de grosses boites, Linux et les logiciels libres en général sont toujours considérés comme pas sérieux par pas mal de vieux unixiens/oracliens. Dans ce cas-là, il peut s'agir qu'Alcatel montre à un de ses gros clients qu'ils utilisent Linux et que ça marche très bien, et ça peut faire avancer le schmilblick chez ce gros client.

Seul celui qui obtient (par achat par exemple) le produit peut demander les sources, et c'est seulement sur demande que le vendeur est obligé de fournir les sources.

Certes mais il faut aussi une mention claire qui indique que sur demande on a accès au code - "written offer for source code", ce qui n'est pas justement pas forcément le cas.

http://www.fsf.org/licensing/licenses/gpl-violation.html

Au lieu de se tordre l'esprit à faire un système de fichier minimisant les écritures, ce qui de toutes façons sera probablement une arlésienne pour la majorité des utilisations serveur (par exemple, par défaut PostgreSQL demande à l'OS de flusher toutes les écritures sur disque, pour minimiser les risques en cas de crash de la machine[1]), n'y a-t-il pas des perspectives d'augmentation du nombre de cycle d'écritures supportées par le hardware, potentiellement moyennant une augmentation raisonnable du prix ? Après tout, on n'en est qu'aux débuts de l'utilisation de cette technologie pour stocker des informations système et données "pérennes" (encore que ce soit un grand mot pour les disques durs, mais enfin, c'est plus pérenne que l'utilisation supposée d'origine des mémoires flash, un support de transport de données ou de stockage pour des périphériques dédiés comme des APN ou des baladeurs), l'utilisation d'une technologie peut couramment influer sur son évolution.

[1] http://www.postgresql.org/docs/8.3/interactive/runtime-confi(...)

> en comptant large, un test de clef par cycle

Ca me semble plutôt de l'impensable que du large. Il faudrait regarder l'algorithme nécessaire à tester la clef, mais un processeur ne fait pas grand chose de très complexe en un seul cycle...

Gimp ne sait pas traiter plus de 8 bits de profondeur par canal .
Pour la photographie, c'est d'autant plus important que l'on peut avoir une source echantillonnée a plus de 8 bits ( scanner ou raw de l'appareil photo ) .

Hum, les yeux ont du mal à différencier 7 bits de profondeur, sur le vert et dans les meilleures circonstances - et sachant que le vert est la couleur où les yeux ont la meilleure sensibilité[1]. Si on doit bien multiplier la sensibilité par 2 pour s'assurer de ne pas perdre de données dans les différentes manipulations informatiques qui sont de nature discrètes (donc arriver à 8 bits), l'augmenter encore me semble inutile. Y a-t'il une raison particulière pour avoir besoin de plus ?

[1] voir l'image que j'ai mise dans http://en.wikipedia.org/wiki/Highcolor#16-bit_highcolour