En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé.
Cette vulnérabilité touche Debian ainsi que toutes les distributions utilisant des paquets Debian (Ubuntu, Xandros...).
Pour prendre un exemple parlant, imaginez Securor, un fabricant de serrures qui seraient utilisées un peu partout sur la planète. Au bout de deux ans, alors que des millions de personnes ont installé des serrures pour protéger leur maison, on se rend compte qu'en fait il n'existe que 3 modèles uniques de clefs, les autres ne sont que des copies d'un des 3 modèles d'origine. Si bien qu'un voleur peut très facilement concevoir un trousseau contenant les 3 modèles de clefs, en ayant la certitude que toute serrure rencontrée pourra être ouverte avec l'une de ces clefs...
Concrètement, si vous utilisez une Debian, ou dérivée, vos VPN peuvent être cassés (adieu confidentialité des échanges), des faux certificats peuvent être signés (adieu confiance en votre système de PKI), votre serveur SSH ne filtre plus grand monde (adieu système sécurisé)...
Que faire ?
- Mettre à jour votre distribution Debian pour installer les nouveaux paquet.
- Vérifier sur tous vos systèmes qu'une clef faible n'est pas présente. Pour cela, un outil est disponible : dowkd.pl
Si une clef faible est présente, il sera nécessaire de la générer à nouveau, avec tous les impacts que cela peut avoir (fichiers authorized_keys & know_hosts obsolètes...). Même problème pour les certificats : j'espère que personne n'a mis en place de PKI sous Debian depuis 2006, il va falloir regénérer les certificats...
- lire le wiki Debian http://wiki.debian.org/SSLkeys qui vous guidera pas à pas en fonction des logiciels installés sur votre machine.
NdM : lire également les articles sur Planet Debian-Fr.
Aller plus loin
- Le Debian Security Advisory (57 clics)
- Dowkd.pl - A télécharger absolument en cas de doutes ! (31 clics)
- Metasploit a généré les clefs faibles (30 clics)
- Journal Linuxfr déja paru à ce sujet (56 clics)
- Wiki Debian :à lire si vous ne savez pas quoi faire (21 clics)
- ... (2 clics)
# Fiabilité de dowkd.pl ...
Posté par GnunuX (site web personnel) . Évalué à 10.
Je rappelle quand même ce que dit le wiki :
> Note that dowkd.pl produces many false positives and that the authors suggest
> that it may also produce false negatives. On that basis, you might decide that it is
> simply easier to regenerate your keys as described above.
En gros, il faut avoir autant de confiance en dowkd.pl qu'a l'ancienne version d'openssl. Bref, faut TOUT regénérer.
[^] # Re: Fiabilité de dowkd.pl ...
Posté par Romain Be. . Évalué à 4.
Enfin, un faux positif est jamais mauvais en soi, tandis que les faux négatifs sont simplement possibles, mais pas prouvés.
Bref, tout se joue à la parano.
A noter que les clefs générées sur un système pre-etch sont fiables. C'était le cas sur tous mes serveurs, qui dataient de sarge ou plus, et c'est surement aussi le cas pour d'autres..
# debian
Posté par maggic . Évalué à 10.
# Un peu d'humour
Posté par plusplus . Évalué à 8.
http://daniel.molkentin.de/blog/archives/118-On-the-topic-of(...)
# fail2ban
Posté par Putifuto . Évalué à 9.
des contres mesures genre fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page qui bloque l'accès après X tentatives échouées sont toujours intéressantes à mettre en place.
[^] # Re: fail2ban
Posté par Amaury . Évalué à 6.
Les attaques sur les VPN ou les PKI etc. ne seraient pas détectées par fail2ban (que j'apprécie beaucoup d'ailleurs).
# Debian ou dérivé
Posté par Romain . Évalué à 2.
En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé
Perdu comme ça au milieu d'un paragraphe hors sujet, je trouve ça insuffisant.
Avec ça, les utilisateurs des distributions telles que Ubuntu, Xandros (eeepc), et autres, ne vont pas prendre l'alerte au sérieux.
[^] # Re: Debian ou dérivé
Posté par nyquist . Évalué à 10.
Plus sérieusement, si il font les mises à jours de sécurité régulièrement leur clé sont déjà supprimé (avec tous les problèmes que ça peut engendrer).
Par contre je suis curieux de savoir quand Xandros corrigera le problème.
[^] # Re: Debian ou dérivé
Posté par brunus (site web personnel) . Évalué à 8.
Sur une Dapper Drake, la LTS 6.06, la version de openssl est 0.9.8a.
Hors sur l'advisory Debian : The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17
En tant que crétin d'utilisateur d'Ubuntu, ce que je comprend, c'est que ma LTS n'est pas affectée par ce bug, et que j'ai eu raison de ne pas immédiatement faire la mise à jour vers la nouvelle LTS.
J'ai bon ? On alors comme je suis un utilisateur d'Ubuntu je n'ai rien compris...
[^] # Re: Debian ou dérivé
Posté par case42 (site web personnel) . Évalué à 4.
est-ce que le Bug a été introduit dans Dapper par une mise a jour ulterieure de OpenSSL, ou en est-elle toujours exempt? Et si le Bug y est, as-tu généré des clefs après son introduction?
Mais si Dapper ne souffre pas de ce bug, un bon point pour la LTS d'Ubuntu...
[^] # Re: Debian ou dérivé
Posté par brunus (site web personnel) . Évalué à 3.
Mais je vais essayer de trouver l'info...j'ai vraiment besoin de savoir.
[^] # Re: Debian ou dérivé
Posté par nyquist . Évalué à 4.
J'ai bon ? On alors comme je suis un utilisateur d'Ubuntu je n'ai rien compris...
Tu as bon...
Maintenant ce pose à moi un dilemme, si les utilisateurs pas si crétins d'ubuntu comprennent, ça veut dire que c'est moi le crétin d'avoir dit ça...
Dur!
De toute façon je suis aussi un utilisateur d'ubuntu donc dans tous les cas je suis mal barré...
[^] # Re: Debian ou dérivé
Posté par brunus (site web personnel) . Évalué à 2.
Tout dépend...t'es tu empressé de mettre à jour tes LTS ou as tu sagement attendu la 8.04.1 ? ;-)
Je crois que c'est simplement de la chance...Dapper Drake est issue d'un freeze de Sid qui a eu lieu un an avant l'injection du bug dans Debian Unstable...that's all. Hazard des calendriers tout ça...
Si j'avais souhaité avoir un système bien plus sécurisé, qu'un dérivé de Debian, il y avait des solutions dans le libre...Je n'ai jamais considéré une Debian comme étant le summum de la sécurité...mais je crois qu'on en parle déjà dans d'autres commentaires, ce n'est pas la peine de lancer un second troll à tête multiples.
[^] # Re: Debian ou dérivé
Posté par DLFP est mort . Évalué à 0.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian ou dérivé
Posté par g0d0t . Évalué à 3.
# Mise en perspéctive
Posté par Romain Be. . Évalué à 10.
Attention à mettre en perspéctive ce genre d'affirmation.
Ce bug est important, voire très grave c'est clair.
Cependant, il en existe d'aussi important, voire peut-être plus, qui ne sont pas revélés et encore moins corriger (je ne citerai pas d'OS...).
Debian a choisi de communiquer intensément, dans la tradition d'"on ne cachera pas les problèmes". C'est aussi important que la faille soit fixée rapidement ainsi que publiquement expliquée, y compris sur les façon de s'en proteger.
Et pour cela, c'est positif il me semble.
[^] # Re: Mise en perspéctive
Posté par gc (site web personnel) . Évalué à 2.
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.
[^] # Re: Mise en perspéctive
Posté par Romain Be. . Évalué à 4.
[^] # Re: Mise en perspéctive
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Même la dernière faille vmsplice du kernel est 100 fois moins dangereuse !!
Et ce qui est assez scandaleux ici, c'est que ce n'est pas une faille du développement upstream, mais une faille béante apportée par un développeur externe, visiblement pas expert en cryptographie, au projet pour "corriger" un problème cosmétique de développement logiciel et intégré dans une distribution généraliste.
Ce qui me gène énormément dans cette histoire, c'est l'attitude devs Debian qui cherche à discréditer tout le monde (upstream et autres distributions) au lieu d'assumer simplement leur responsabilité et faire profil bas.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 4.
http://www.openoffice.org/news/index.html
Security update
Please note that OpenOffice.org version 2.4, released on 27th March, fixed a number of security vulnerabilities. To our knowledge, none of these has been exploited; however, in accordance with industry best practice, we recommend all users upgrade to 2.4.
This information was withheld intially to ensure that all the products derived from the OpenOffice.org codebase had time to include these security fixes before the public announcement of the vulnerabilities.
#Manipulated ODF text documents containing XForms can lead to heap overflows and arbitrary code execution
#Manipulated Quattro Pro files can lead to heap overflows and arbitrary code execution
#Manipulated EMF files can lead to heap overflows and arbitrary code execution
#Manipulated OLE files can lead to heap overflows and arbitrary code execution
ils n'ont pas annoncé ces soucis à la sortie de OpenOffice 2.4 mais bien bien après (à tort ou à raison mais ce n'est pas la question ici)
> Ce qui me gène énormément dans cette histoire, c'est l'attitude devs Debian qui cherche à discréditer tout le monde (upstream et autres distributions) au lieu d'assumer simplement leur responsabilité et faire profil bas.
je n'ai pas lu ça du tout.
[^] # Re: Mise en perspéctive
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
De plus, ce que tu cites ce sont des bugs dans le développement upstream corrigé en upstream et pas des bugs rajoutés par la distributions.
> je n'ai pas lu ça du tout.
Va sur planet.debian.org ... !!!
En vrac.
* C'est pas nous, c'est la faute aux dev upstream...
sauf que les devs upstream n'ont jamais intégré ce patch !!
* Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé.
Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
* Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves.
Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
Toi même, si tu te relis !
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 9.
et concernant planet.debian.org je
ah non stop, planet.debian.org a autant à voir avec Debian que le blog de ploum a à voir avec Ubuntu. lire ça ou les combats de pissotières sur Usenet, ça n'a d'intérêt que si on aime recevoir des éclaboussures. chacun son trip.
en vrac :
> * C'est pas nous, c'est la faute aux dev upstream...
> sauf que les devs upstream n'ont jamais intégré ce patch !!
je pense que les "upstreams" n'ont rien à voir là dedans mais ce n'est que mon opinion. au pire le dev upstream concerné a mal compris une question posée par un des gars de Debian.
> * Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé.
> Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
c'est quoi qui compte, qu'ils aient vite résolu le problème (et je pense pas que d'autres distributions responsables ou les BSDs auraient fait moins vite) ou des notions de honte ou de fierté dont on n'a absolument rien à foutre dès le lendemain ? si ce genre de gag reste isolé, je n'ai pas de raison sérieuse de leur retirer ma confiance.
> * Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves.
> Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
j'aimerais savoir comment une autre distribution ou d'autres utilisateurs de openssl aurait résolu la même gaffe sans une telle blacklist et prévenir le reste de la planète. c'est un peu se plaindre qu'on propose une liste de users et de passwords à ne pas utiliser (genre test/test) ou que passwd te crie après si tu mets un mot de passe trop court ou trop simple. oui, on peut s'en passer...
> Toi même, si tu te relis !
je ne sais pas ce que tu prends comme drogue mais tu devrais arrêter tout de suite. et d'ailleurs je ne suis pas "de Debian", et niveau utilisation des distributions je suis laaargement agnostique, j'ai connu Unix avant Windows et en fait presque avant DOS donc bref, si Debian accumulait ce genre de gags j'irais voir ailleurs sans me casser la tête.
tu demandes un exemple et j'en ai proposé un, tu ne le trouves pas pertinent certes ok, là dessus je te conseille une tisane si ça peut soigner tes délires de persécution.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 0.
Il y des failles de sécurité connues, mais connues d'un petit groupe (ceux en charge de la sécurité). Ses failles sont sous "embargos" tant qu'un correctif n'est pas réalisé ou que personne n'a rendu la faille public ou qu'il n'y a pas un exploit.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 3.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à -1.
Qu'es-ce tu racontes ?
Si t'es assez con de divulguer publiquement une faille non encore connue, ben fait le. Personne ne t'en empêche.
Mais il est d'usage, et intelligent, d'en informer que ceux qui s'occupe de la sécurité.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à -2.
bah écoute mon petit hein, c'est un vaste débat qui te dépasse largement et je te conseille de laisser ça aux personnes concernées (les white hats, on dira) qui jugeront au cas par cas ce qu'elles doivent faire. parce que, des fois, même prévenu personne corrige après 2 ou 6 mois, et d'autres personnes (les méchants) ont trouvé et utilisent la même faille. ou encore, des fois l'éditeur en question a tout simplement disparu.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 0.
Mais ça ne doit être que moi. Tes propos doivent être limpides pour tous les autres.
[^] # Re: Mise en perspéctive
Posté par fredix . Évalué à 5.
Or dans ce cas il est de bon ton de diffuser la faille afin de prévenir les usagers et faire bouger l'upstream...
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 1.
Comme il connait cette faille si elle n'est pas public ?
> Or dans ce cas il est de bon ton de diffuser la faille afin de prévenir les usagers et faire bouger l'upstream...
Mouaif.
[^] # Re: Mise en perspéctive
Posté par fredix . Évalué à 1.
man scriptkiddies
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 4.
Tu n'as pas mieux ?
Si le scriptkiddies la connais, alors la faille est public et même exploité.
On ne parle plus du tout de la même chose.
[^] # Re: Mise en perspéctive
Posté par fredix . Évalué à 3.
man brain
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à -2.
tu as pensé à le tester avant de le conseiller?
[^] # Re: Mise en perspéctive
Posté par wismerhill . Évalué à 5.
Tout simplement parce qu'il l'a constatée par hasard (ça arrive) ou suite à un audit de sécurité interne (ça arrive aussi) ou encore parce qu'il a constaté une intrusion/utilisation abusive de son serveur par un cracker qui aura découvert la faille à sa façon (ancien employé qui a introduit en douce une backdoor, vol de code).
Et là je ne parle que de logiciels fermés.
Pour du libre, tu peux faire un vrai audit du code (il y a des boîtes qui font ça) et tomber sur des trucs dont l'upstream ne s'était pas rendu compte.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à -3.
Dans ce cas la faille est public !
Même si elle n'est pas annoncé sur les tois, elle est public !
Dans les autres cas, c'est à celui qui a découvert la faille de décider s'il veut la rendre public ou seulement contacter les responsables de la sécurité.
L'usage (ce n'est pas un obligation) veut qu'on contacte uniquement les responsable de la sécurité. Il y aura un "embargo", mais on ne te demande pas de signer un accord pour ne pas divulguer la faille. On compte sur ton intelligence, ta "courtoisie", pour ne pas le faire.
[^] # Re: Mise en perspéctive
Posté par fredix . Évalué à 1.
Sinon pour le reste pas la peine de te répéter, on dirait que tu viens de découvrir le Net avant-hier et le hacking/cracking hier ...
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 1.
Manifestement tu n'as toujours pas compris.
[^] # Re: Mise en perspective
Posté par Yusei (Mastodon) . Évalué à 8.
Au début, tu dis qu'une faille peut être connue par un petit groupe de gens sans être publique. Mais maintenant, tu prétends que si un cracker la découvre, elle est publique.
[^] # Re: Mise en perspective
Posté par IsNotGood . Évalué à -1.
Si un cracker la connait, tu peux supposer que plusieurs crackers la connaissent, tu peux supposé qu'il n'a pas envis de coopérer à un embargo, etc.
Si un cracker la connait, tu peux supposé qu'elle est public (il peut la rendre public du jour au lendemain), que l'embargo à fourré, etc.
Si un cracker la connait (donc l'utilise), il faut prévenir les utilisateurs (désactiver sshd, réajuster les fichiers de configuration, etc). Prévenir les utilisateurs empêche tout embargo, donc la faille est public.
etc.
Mais c'est trop compliqué pour vous de réfléchir donc j'arrête ici.
[^] # Re: Mise en perspective
Posté par Yusei (Mastodon) . Évalué à 8.
- un cracker peut très bien décider d'exploiter une faille avant de la rendre publique, puisque la rendre publique revient à aider les gens à la faire disparaître
- il est difficile pour les mainteneurs de savoir si un cracker connait et exploite une faille. On ne peut donc pas raisonner en se disant "tant que je ne divulgue pas une faille, personne ne peut l'exploiter".
[^] # Re: Mise en perspective
Posté par IsNotGood . Évalué à -2.
Ou du moins, ce qui devrait être fait et n'est pas fait.
Parce que les "je coupe les cheveux en quatre pour casser un raisonnement", ça me brise les couilles.
[^] # Re: Mise en perspective
Posté par wismerhill . Évalué à 2.
(but you can leave your hat on)
[^] # Re: Mise en perspective
Posté par IsNotGood . Évalué à 2.
Très intéressant.
Et si tu laissais les "experts" avoir un avis en premier ?
Je suis neuneu quand ça touche à la sécurité.
Quand je trouve ce que je crois être un trou de sécurité, j'en informe les experts en privé. Je ne vais pas inventer dans mon coin ce que je crois être la meilleur solution pour gérer le problème.
Et toi ?
[^] # Re: Mise en perspective
Posté par wismerhill . Évalué à 2.
Si je trouve une grosse faille dans wuftpd (ok, l'exemple est facile), je vais surement en informer les développeurs, mais je vais aussi prévenir les gens que je connais de ne pas utiliser ça parce qu'il y a une faille dedans (pas besoin de dire laquelle).
[^] # Re: Mise en perspective
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Mise en perspective
Posté par fredix . Évalué à 3.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 2.
en l'occurrence je ne fais preuve d'aucun coup de gueule ni rien. vraiment. c'est pas que je m'en fous mais j'ai pas encore tout compris.
je n'ai pas compris toutes les implications de cette gaffe. et je peux vous affirmer que des experts reconnus de boites de sécus très sérieuses et largement à la pointe de ce domaine n'ont pas encore tout compris non plus.
[^] # Re: Mise en perspéctive
Posté par Pierre Carrier . Évalué à 2.
[^] # Re: Mise en perspéctive
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Ce n' est pas parceque tu ne remontes pas la faille aux concernés directement, que tu es "un con". Même un non expert peut voir qu' il y a d' autres moyens d' être utile à la correction de la faille que la remontée directe upstream.
(d' ailleurs, ce n' est pas une des raisons du traitement à part, non public, dans le bugzilla de redhat ? laisser le temps de la correction, mais aussi se laisser le temps de choisir... ). Premier point. non ?
Dans l' autre registre, l' attitude full disclosure se tiens aussi :
En rendant publique des "o days" ou quasi, on force à la correction.
Les manières peuvent être diverses.
non ?
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 2.
Lorsque tu fais un rapport de bug sur une faille de sécurité, il est proposé de mettre le bug en confidentiel. Tu accèptes ou non. Si tu n'accèptes pas de le mettre en confidentiel, il reste public (Red Hat n'y touche pas, il reste public).
Le bugzilla de Red Hat a aussi des rapports de bug de ses clients (via la hot line typiquement). Pour ses rapports de bug, la confidentialité est appliquée. Un client de Red Hat est libre d'utiliser directement http://bugzilla.redhat.com/ et de mettre le rapport de bug en public.
Les rapports de bug de sécurité sous "embargo" en sont pas publics jusqu'à la fin de l'"embargo". À la fin de l'embargo (ou si le bug a été publié), ils sont public.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 3.
Non. Tu mets seulement un vent de panique (chez les développeurs et les utilisateurs).
[^] # Re: Mise en perspéctive
Posté par wismerhill . Évalué à 2.
Par exemple pour un serveur ftp (qui est une faille en lui-même), tu peux tout simplement le couper, en installant éventuellement un autre si le service est critique.
Pour une faille du sous-système sftp de openssh tu pourrais simplement désactiver celui-ci le temps de la correction, scp (et fish) est toujours là pour les transferts de fichiers.
Il y a probablement beaucoup d'autres exemples où quelques mesures simples peuvent rendre une faille de sécurité sans gravité en attendant une vraie solution.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 3.
L'"embargo" est quelque chose pris très au sérieux. On peut trouver plein de rapports de bug de sécurité sur http://bugzilla.redhat.com/ ou le correctif est trouvé avant la fin de l'embargo. Et bien Red Hat attend la fin de l'embargo pour diffuser le correctif. C'est être "urbain" avec les autres utilisateurs/distributions.
Tant qu'on peut tenir l'embargo, ça donne du temps pour paufiner le correctif, ça donne du temps aux autres distributions, etc.
C'est quelque chose de très important. Et ce n'est pas obligatoire ! Ce n'est pas à confondre avec de la censure par exemple.
Enfin, on en voit pas des embargos se prolonger sans justification.
[^] # Re: Mise en perspéctive
Posté par pasBill pasGates . Évalué à 9.
C'est faire preuve d'une meconnaissance totale du fonctionnement d'une entreprise que de suggerer qqe chose de ce genre.
Meme avec un workaround, les societes mettent un temps non negligeable a l'implementer, car elles doivent le tester.
La realite, et elle est partagee par a peu pres tous les gens concernes, c'est qu'un zero day c'est Mal(TM) pour l'editeur, et pour les clients.
Pour etre tres tres simple, il n'y a aucune raison valide pour sortir publiquement un zero day. Si t'as pas confiance dans l'editeur, tu lui donnes X jours et tu fais ton annonce automatiquement apres le delai, methode tres simple, que bcp de gens utilisent.
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à 1.
En annonçant publiquement, on ne fait que donner des idées à des crackers supplémentaires.
En ne rendant pas public directement, on laisse à l'éditeur un laps de temps pour corriger la faille et ainsi éviter des dangers de grande ampleur. C'est simplement de la logique, du bon sens.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 4.
parce que dans la vraie vie, c'est pas toujours ça.
par exemple la politique d'autres éditeurs c'est de ne rien corriger et de te menacer d'un procès monstrueux si tu mouftes. pour les plus gentils. j'ai besoin de dire que d'autres sont liés à des intérêts douteux voir mafieux ?
oh toi tu peux te dire je m'en fous, je me suis aperçu du problème, je n'ai plus qu'à oublier ce produit et l'affaire est close.
sauf qu'en général tu n'es pas seul au monde et tu t'aperçois avec effroi que tes collègues, amis, famille etc utilisent le même logiciel, troué et activement exploité par des vilains de Russie ou de Roumanie tout ça tout ça qui se promènent sur leurs disques durs comme s'ils étaient chez eux.
tu fais quoi, là ?
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 1.
Arrête le délire, on n'a jamais vu ça dans le libre.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 2.
(et en passant, Adobe, Oracle ou Skype (enfin, eBay) sont des boites qui font des produits sous *nix. des produits très populaires. des produits souvent troués)
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 2.
- "il faudrait penser au fait qu'annoncer publiquement dès le zéro day n'apporte rien d'autre qu'une augmentation du danger si l'éditeur s'occupe généralement de règler les failles."
Puis toi :
- "ça c'est quand l'éditeur dit qu'il va la corriger"
Si la faille n'est pas public, il ne dit qu'il va la corriger. Par définition, ce n'est pas public.
> parce que dans la vraie vie, c'est pas toujours ça.
C'est par rapport à quoi ?
Par rapport au commentaire auquel tu réponds ?
Le cas des éditeurs qui ne s'occupent pas de règler les failles, le commentaire auquel tu réponds n'en parle pas.
Tu changes de sujet, voire les mélange, alors forcément on peut se prendre les pieds dans le tapis.
"La vraie vie" ne se résume à généraliser la caricature que tu as faite.
La vraie vie c'est aussi plein d'éditeur qui font correctement leur boulot.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 3.
ben si. quand l'éditeur répond à la personne qui lui a indiqué la faille.
des fois cette personne met des gens biens (tm) en copie, histoire de garder une trace, un historique, revenir à la charge si il n'y a aucune demande de précision, ou si l'éditeur fait le mort pendant 2 semaines puis 2 mois puis 6...
> La vraie vie c'est aussi plein d'éditeur qui font correctement leur boulot.
et que pleins d'autres ne le font pas ou alors en se faisant vraiment tirer l'oreille, car au final ça leur coute des sous, du temps, ça leur fait de la mauvaise publicité, etc etc
allez, zou, retourne dans ta cave, y'a mémé qui veut sortir du congélo.
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à 0.
Ce n'est pas parce qu'il existe des éditeurs avec des politiques douteuses, mais faut pas tout mélanger. Autant je n'adhère pas à la politique éditoriale de certains éditeurs, autant la grande majorité des éditeurs font leur boulot correctement.
Si tu n'as pas confiance en un éditeur, rien ne t'empêche de changer d'éditeur, sans forcément rentrer dans un rapport de force stupide. Parce que c'est bien ça le soucis: en balançant la faille publiquement, tu prends en otage l'éditeur ainsi que tous les utilisateurs de façon à "accélérer la réaction du dit éditeur". Hors, il faut bien se rendre compte que dans mon post, je partais de l'hypothèse que tu étais assez malin pour choisir d'utiliser des logiciels provenant d'éditeurs en qui tu as confiance (désolé, je n'ai pas forcément envie de me mettre à la place des masochistes qui choisissent d'utiliser des logiciels d'éditeurs en qui ils n'ont pas confiances). Dans ce cas, désolé mais ne pas laisser à l'éditeur un temps de recul est stupide parce que tu rends encore plus dangereuse la faille durant le laps de temps entre l'annonce publique et la correction (qui prend un temps certain en raison de la nécessité de ne pas balancer un patch à l'arrache).
Après, si tu ressens constamment le besoin d'un rapport de force avec l'éditeur pour croire que tu défends tes droits, tu as sûrement à te questionner sur ta façon d'appréhender la "vraie vie".
Personnellement, j'utilise Mandriva, et je fais confiance à l'éditeur. Dans ce cas, si je trouve une faille critique, je la renvoie à Mandriva, mais en privé, pour leur laisser le temps de régler le soucis sans mettre en danger tout le monde (surtout dans le cas d'un truc aussi sensible qu'OpenSSL).
Arrète d'être irrespectueux vis-à-vis de IsNotGood, il ne fait qu'expliquer son point de vue. Faudrait redescendre un peu de ton piédestal. Le fait d'agresser constemment comme tu le fais montre une certaine frustration qu'il te faudrait résoudre.
Dans la "Vraie Vie", les gens vivent en société et cherchent à collaborer autant que possible. Et un éditeur qui se respecte (et il y en a une majorité) cherche avant tout à conserver ses clients ; donc à ne pas les laisser dans une merde noire.
[^] # Re: Mise en perspéctive
Posté par Gniarf . Évalué à 3.
et qu'attends-tu donc pour te soigner ?
> la grande majorité des éditeurs font leur boulot correctement.
farpaitement, je n'ai jamais dit le contraire. et c'est indirectement parce que les autres se cachent ou ne sont pas vraiment considérés comme des éditeurs.
> en balançant la faille publiquement, tu prends en otage l'éditeur ainsi que tous les utilisateurs de façon à "accélérer la réaction du dit éditeur".
oh je te rassure, il y a des gros malins qui font ça alors même qu'ils n'utilisent pas ledit logiciel ou ne seront pas impactés. oui, ils sont cruels. c'est ça aussi, la Vraie Vie, il y a des salauds et des méchants. la méchanceté gratuite a quelque chose de jouissif. oui, ça se soigne. en général ils ne veulent pas.
j'ai eu une découverte récente de faille à mon actif et j'estime avoir fait les choses correctement et accessoirement proprement. je n'ai d'ailleurs pas utilisé le soft en question (un jeu) puisqu'il fallait s'inscrire et que c'était la procédure d'inscription qui était trouée... la flemme de m'inscrire ensuite
> Dans la "Vraie Vie", les gens vivent en société et cherchent à collaborer autant que possible. Et un éditeur qui se respecte (et il y en a une majorité) cherche avant tout à conserver ses clients ; donc à ne pas les laisser dans une merde noire.
je crains que ton expérience de la Vraie Vie se cantonne encore à un monde plein de poneys roses avec une crinière argentée et une étoile sur le derrière. il y a d'autres sociétés hors de notre petit cocon franco-européen de l'ouest. d'autres mentalités et d'autres systèmes de valeurs. limite d'autres civilisations. ailleurs on cherche surtout à t'exploiter, toi ou ta machine (enfin sa connexion internet à haut débit), et tant mieux si tu es loin, dans un autre pays. un peu comme Elf exploite les locaux en Birmanie, tu vois : ils comptent pour moins que rien.
agir de façon responsable (ce que tu sous-entends par 'vivre en société') n'est pas une loi de la nature ou une constante universelle. en fait c'est même limite contre-nature : à bien y réfléchir, tu peux gèner tes concurrents qui ont le même fournisseur que toi...
(sinon, faut arrêter d'être tout le temps désolé, ça se soigne aussi)
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à -2.
Pas toi ?
C'est triste.
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à 1.
Je préfère te laisser la première place, tu sembles en avoir plus besoin que moi.
[quote]farpaitement, je n'ai jamais dit le contraire. et c'est indirectement parce que les autres se cachent ou ne sont pas vraiment considérés comme des éditeurs.[/quote]
Ah non? Toi, quand tu penses à un éditeur, tu pars de ce principe:
[quote]ça c'est quand l'éditeur dit qu'il va la corriger et qu'il a un certain nombre de corrections effectuées à son actif, donc en gros que tu peux le croire.
parce que dans la vraie vie, c'est pas toujours ça.
par exemple la politique d'autres éditeurs c'est de ne rien corriger et de te menacer d'un procès monstrueux si tu mouftes. pour les plus gentils. j'ai besoin de dire que d'autres sont liés à des intérêts douteux voir mafieux ?[/quote]
Moi par contre, je te dis qu'il faut choisir un éditeur en qui tu as confiance et ainsi pouvoir conserver le temps de latence pendant lequel la faille n'est pas rendue publique pour éviter justement l'exemple suivant que tu as décrit:
[quote]u n'es pas seul au monde et tu t'aperçois avec effroi que tes collègues, amis, famille etc utilisent le même logiciel, troué et activement exploité par des vilains de Russie ou de Roumanie tout ça tout ça qui se promènent sur leurs disques durs comme s'ils étaient chez eux.[/quote]
D'ailleurs, au passage, tu peux aussi avoir des français, des américains, des anglais, des tout ce que tu veux dans ton ordinateur à partir du moment où la faille est rendue publique sans correction immédiate. D'où l'intérêt de se réserver ce fameux temps de latence.
[quote]tu fais quoi, là ?[/quote]
Je n'agrave pas la situation et fait confiance à ceux qui sont mieux placés que moi pour agir. Le mainteneur n'avait pas à modifier ce fichu paquet sans savoir ce qu'il faisait, il n'aurait jamais dû être seul sur un élément critique, et il y aurait dû avoir vérification. Mais surtout, je ne m'amuse pas à annoncer publiquement que ce type de faille existe pour "accélérer le mouvement". Parce que je n'évolue pas contre les éditeurs, mais bien en collaborant avec les gens dont j'ai choisi les services. Ou alors, si je ressents que je ne peux pas avoir une protection rapide pour mes données sans rentrer dans un rapport de force avec l'éditeur, je change d'éditeur.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 4.
Notons aussi que les distributions, lorsqu'il y a une faille de sécurité, informent cert-vendor. Donc toutes les distributions sont au courant (en privé) si c'est un problème upstream. Elles sont toutes dans le même bateau si tu envoyes le rapport de bug à "seulement" Mandriva. Ce rapport de bug, même qu'à une distribution, est suffisant et apprécié de tous.
Je trouve ceci vraiment excellent (mais c'est aussi le moindre) de voir que les distributions ne se tirent pas dans les pattes lorsqu'il sagit de sécurité.
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à 0.
En effet c'est le moindre.
[^] # Re: Mise en perspéctive
Posté par briaeros007 . Évalué à 6.
Désolé de dire ça, mais la paranoïa maladive, ça se soigne.
Désolé de dire ça, mais en sécurité informatique, il FAUT être paranoiaque.
Tiens exemple con : le pentagone cherche a virer TOUS les équipement réseau dont leur puce n'ont pas été concu et produit aux US.
Pourquoi ? Pour éviter une backdoor matérielle (presque)impossible à déceler.
Pour toi c'est de la paranoia maladive, pour les autres, c'est appliqué des normes de sécurité.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 1.
Et c'est toi qui le dit...
Ben Debian ne devrait pas être autorisé n'importe qui à patcher OpenSSL...
Il ne faut pas utiliser Debian/Ubuntu/etc.
Debian ne devrait pas utiliser Debian.
Etc.
Faire de la paranoïa la règle absolue est stupide et contre productif.
Il est d'autant plus marrant que tu dises "il FAUT être paranoiaque" alors que manifestement Debian ne l'a pas été et que tu n'arrêtes de chercher des excuses au mainteneur qui a fait la boulette alors qu'il ne l'a pas été non plus (et que tu ne trouves pas ça grave...).
[^] # Re: Mise en perspéctive
Posté par briaeros007 . Évalué à 2.
Oui c'est moi, et ca fait quoi si c'est moi qui le dis ?
Ah rien ... vu que j'ai reconnu que debian avait fait des bourdes, et j'ai aussi reconnu que si je voulais une garantie, j'aurais pris de la maintenance (avec contraintes financières) ...
Il ne faut pas utiliser Debian/Ubuntu/etc.
Si on veut être rigoureux et extrême,dans le etc il y a tout logiciels que tu n'a pas auditer, donc toutes les distribs a peu de choses près, donc fedora et redhat.
Ah tiens y'a pas que tes deux ennemis jurer (a t'en entendre parler).
Faire de la paranoïa la règle absolue est stupide et contre productif.
J'ai dis que c'était la règle absolue ?
j'ai dis qu'il le fallait.
Il la faut car il faut avoir à l'esprit les risques possibles et existants! Elle sert à ça la parano!
Par contre, Je n'ai pas dis qu'il ne fallait pas aussi savoir faire la part des choses.
Encore une supposition de ta part (un homme de paille).
Si quelqu'un utilise une règle qui peut sembler paranoiaque, et que c'est dans le cadre de la sécurité, alors cette règle lui convient tout a fait. Il n'y a pas de paranoia en sécurité, mais une prise de risque, qui doit etre fait en connaissance de cause (d'ou le "il faut etre paranoiaque").
Et vouloir faire croire le contraire est, excuse moi mais je n'ai pas d'autres mots, complètement idiot.
que tu n'arrêtes de chercher des excuses au mainteneur qui a fait la boulette alors qu'il ne l'a pas été non plus (et que tu ne trouves pas ça grave...).
Une phrase, deux affirmations, toutes les deux fausses.
Alors je t'apprendrais à lire, parce que je l'ai déja dis plusieurs fois clairement : je reconnais tout a fait que le mainteneur de debian a fait des erreurs.
Je reconnais aussi qu'il y a eu d'autres choses que juste "c'est la faute a une seule personne" dans cette affaire.
Contrairement a toi je ne suis pas obnubilé par le binaire. (suffit de voir le début de mon post d'ailleurs...)
Enfin je n'ai jamais dis que je ne trouvais pas ça grave. Si tu as compris ca d'une de mes phrases, j'ai du mal m'exprimer
bref, attaquons, attaquons, il en restera toujours quelquechose...
[^] # Re: Mise en perspéctive
Posté par Anonyme . Évalué à 4.
Justement, la parano, ca ne veut pas dire ne pas bien faire la part des choses ?
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 2.
Ben oui.
> Ah tiens y'a pas que tes deux ennemis jurer (a t'en entendre parler).
Je suis cohérent. Je ne dis pas qu'il FAUT être paranoïaque (donc je peux utiliser une Fedora, voire même une Debian si le risque me parait raisonnable). Toi tu dis qu'il FAUT être paranoïaque. Ben utilise rien.
> Il n'y a pas de paranoia en sécurité, mais une prise de risque, qui doit etre fait en connaissance de cause
C'est très différent de "il FAUT être paranoïaque". La prise de risque n'est pas le truc des paranos (t'avais remarqué ça ?).
> qui doit etre fait en connaissance de cause
Dans le cas de la sécurité, ce n'est pas vraiment ça.
Si je suis cascadeur, je vais prendre des risques. Je dois les faire en connaissance de cause. Je vais par exemple prendre plus de risque de d'habitude pour faire une belle cascade. Mais prendre des risques pour la sécurité n'est pas logique. Par contre même si je suis cascadeur, je peux avoir un conseillé sécurité qui va me dire de mettre un casque. Ce n'est pas le conseillé sécurité qui prend les risques, c'est moi. C'est moi qui doit être conscient des risques.
Pour la sécurité, je dois analyser les risques et faire pour en prendre le moins possible pour un contexte donné (par exemple ça ne veut pas dire qu'il faut annuler la belle cascade dangereuse, mais la rendre moins dangereuse).
> Et vouloir faire croire le contraire est, excuse moi mais je n'ai pas d'autres mots, complètement idiot.
Soit pas "idiot", reste parano, débranche toi d'Internet alors.
> Une phrase, deux affirmations, toutes les deux fausses.
OK, je m'excuse.
Mais au début, tes propos ce n'étaient pas vraiment ça...
[^] # Re: Mise en perspéctive
Posté par briaeros007 . Évalué à 0.
Ah bon, tu as concu ton propre réseau séparé par des tunnels optiques avec des protections quantiques sur des os EAL7?
Non ?
Ben alors tu as pris des risques.
Ce n'est pas le conseillé sécurité qui prend les risques, c'est moi. C'est moi qui doit être conscient des risques.
Et quand tu es sysadmin d'un parc, tu es a la fois conseiller en sécurité, et cascadeur.
Pour la sécurité, je dois analyser les risques et faire pour en prendre le moins possible pour un contexte donné
Et juste avant tu disais :
Mais prendre des risques pour la sécurité n'est pas logique.
Ou comment dire tout et son contraire dans le meme post...
[^] # Re: Mise en perspéctive
Posté par IsNotGood . Évalué à 3.
J'ai bien essayé de faire passer qu'il y a le responsable sécurité (ou l'expert sécurité) et le client. Tu n'as pas voulu remarquer la chose.
L'expert sécurité ne prend pas de risque. Si le client lui commande un treuil qui doit supporter 10 tonnes dans un environnement définit, le treuil doit supporter 10 tonnes et pas 9 car l'expert sécurité on a voulu faire des économies. Le responsable sécurité n'a pas à prendre de risque. S'il le fait, c'est une faute grave.
Le client peut prendre des risques (NB: on ne recommande évidemment pas qu'il en prenne). C'est au client d'avoir conscience des risques et de définir le niveau de sécurité qu'il veut. Si le client veut accrocher des poids de 12 tonnes à son treuil alors qu'il a commandé un treuil de 10 tonnes, c'est lui qui prend les risques, c'est lui qui est responsable s'il y a une catastrophe.
> Ah bon, tu as concu ton propre réseau séparé par des tunnels optiques avec des protections quantiques sur des os EAL7?
Non. Et alors ?
L'évaluation des risques tu la fais tout le temps.
Si tu demandes un risque proche de 0 à un expert sécurité automobile, il va proposer de brider les voitures à 10 km/h maxi. Mais le client (l'état, les citoyens) accèpte de prendre le risque de rouler à 130 km/h, accèpte d'avoir 5000 morts par an. L'expert n'a pas à prendre de risque ni les définir (il peut évidemment les évaluer). Le client peut en prendre (je répète encore...).
Pour un mirroir public, le client va dire, pour faire court, qu'il s'en fout des risques, et l'expert va proposer le minimum.
Ce n'est pas à l'expert de définir le risque à prendre ! Sinon on tombe dans la stupidité où l'expert se donne du boulot.
Le mainteneur d'OpenSSL est un expert sécurité (ou devrait l'être).
Le cas du développement d'un logiciel de sécurité (donc avec des bugs) n'est pas une prise de risque des experts. Ils doivent donner le niveau de sécurité (si c'est un logiciel beta, alors ça sera faible). C'est l'utilisateur, informé par l'expert, qui prendra le risque d'utiliser un logiciel en phase beta.
> Ben alors tu as pris des risques.
En tant que client/utilisateur oui. Mais ces mes oignons, c'est ma responsabilité.
Tu viens sur internet, tu prends des risques, c'est tes oignons.
> Ou comment dire tout et son contraire dans le meme post...
Et toi l'art de faire l'autruche.
[^] # Re: Mise en perspéctive
Posté par briaeros007 . Évalué à 1.
C'est bien ça, sur les grosses boites ou tu peux dissocier les deux fonctions.
Sur la pratique (la majorité amha des pme, tpe, et autre), ben le sysadmin il est à la fois conseiller en sécurité, et à la fois client.
Et il fait avec les différentes contraintes qu'il a (cout, sécurité, délai, ...)
Le client peut en prendre (je répète encore...).
Sauf que tu repars sur une optique ou les deux fonctions sont complètement dissocié, ou, dans le cadre de la sécu informatique, c'est relativement rare.
Pourquoi les gens font de la sécurité ? Pas pour se faire payer en tant que consultant (enfin certain si, mais pas la majorité de ceux qui la font), mais parce qu'ils doivent assurer la sécurité du systeme dont ils ont la charge.
Si ils ont la charge du systeme, ils ont aussi l'ensemble des contraintes qui s'y applique.
Enfin, ton aspect binaire est bien beau, mais oublie un point TRES important.
Le but d'un conseiller, ce n'est PAS de conseiller des trucs "trop top génial" en théorie mais innaplicable.
Ca en info, TOUT LE MONDE SAIT LE FAIRE : ON ETEIND LE PC !
Le but d'un conseiller est de proposer la MEILLEURE APPROCHE EN TENANT COMPTE DES CONTRAINTES.
Le cas du développement d'un logiciel de sécurité (donc avec des bugs) n'est pas une prise de risque des experts. Ils doivent donner le niveau de sécurité (si c'est un logiciel beta, alors ça sera faible). C'est l'utilisateur, informé par l'expert, qui prendra le risque d'utiliser un logiciel en phase beta.
Si tu souhaite le voir comme ça, c'est ton choix.
Mais ca tombe bien que tu le vois comme ça , regarde bien les licences BSD et GPL des logiciels utilisé.
L'UTILISATEUR FINAL SAVAIT QU'IL N'AVAIT AUCUNE GARANTIE.
(spécifié dans la licence).
Si tu veux un truc en sécu tel que tu le décris, tu demande une certif (EAL, FIPS, ...), et tu prend certainement pas un truc concu par un parfait incconu.
En tant que client/utilisateur oui. Mais ces mes oignons, c'est ma responsabilité.
Tu viens sur internet, tu prends des risques, c'est tes oignons.
On es donc d'accord, le mainteneur avait rien a dire : le client était conscient des risques en prenant un soft GPL/BSD/...
> Ou comment dire tout et son contraire dans le meme post...
Et toi l'art de faire l'autruche.
Je vois pas ou pointer tes contradictions c'est faire l'autruche, mais ca doit etre ta fameuse logique
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à 3.
Par exemple, on ne patch pas à la légère un logiciel critique. On ne rend pas publique une faille quand on peu gagner un peu de temps sans que trop de monde soit au courant et ne représente un danger.
Et non, pour moi, ce qu'à décidé le Pentagone n'est pas de la paranoïa maladive, puisque je trouve celà logique pour un service comme celui-là. Par contre je trouve extrêmement paranoïaque de partir du principe que l'éditeur de logiciels que tu as choisis ne corrigera pas la faille sauf si tu le mets en porte-à-faux.
Le coté paranoïaque maladif, c'est de céder à la panique en hurlant à la fin du monde pour déclencher une panique générale et augmenter la dangerosité de la faille en la rendant publique, pas d'être pragmatique en se prémunissant au maximum des risques.
[^] # Re: Mise en perspéctive
Posté par Sébastien FRADE . Évalué à 2.
Faudrait comprendre que je ne prends pas le cas d'un éditeur qui ne veut pas corriger, mais bien un éditeur en qui tu peux avoir confiance.
Si tu n'as pas confiance en un éditeur de logiciels libres, rien ne t'empèche de passer à un autre éditeur de logiciels libres.
Et arrète d'associer tout et n'importe quoi, à la fin.
[^] # Re: Mise en perspéctive
Posté par Thomas (site web personnel) . Évalué à 1.
Pour info le "o days" date d'un mois ou presque.
[^] # Re: Mise en perspéctive
Posté par Graveen . Évalué à 4.
Pour moi cette mésaventure montre les forces et les faiblesses du modèle de développement choisi, tout comme le propriétaire possède les siens.
Il est effectivement, sur certains projets, difficile de trouver des contributeurs, alors des contributeurs compétents....
C'est sûr, ca tombe mal, il y en a des centaines moins critiques, mais saluons la réactivité du libre.
Bref, tout ca pour dire que le terme 'scandaleux' me semble un peu dur :)
[^] # Re: Mise en perspéctive
Posté par thedidouille . Évalué à 6.
Sur un paquet aussi critique qu'OpenSSL, les mainteneurs ne devraient pas modifier le code d'origine, à moins de savoir vraiment ce qu'ils font, ça n'a rien à voir avec le modèle ou le nombre de contributeurs.
Le terme "scandaleux" me semble totalement approprié, je vois mal ce qui pourrait plus décridibiliser le libre que ça, on aurait tous préférer que ça n'arrive qu'a une petite distrib, pas utilisée pour héberger des services critiques et ignorée des entreprises.
[^] # Re: Mise en perspéctive
Posté par H_francis . Évalué à 2.
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
C'est pas ça le logiciel libre ?
[^] # Re: Mise en perspéctive
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: Mise en perspéctive
Posté par lejocelyn (site web personnel) . Évalué à 7.
Ah, un lecteur de PCinpact :).
# utilisation dowkd.pl
Posté par korm . Évalué à 1.
J'utilise pour mes serveurs une ubuntu dapper (je présume qu'elle est affectée par le bug). Je me demande comment utiliser correctement dowkd.pl, pour ne pas refaire toutes les clés.
J'ai installé openvpn et j'avais créé à l'époque des fichiers
.crt qui commencent par --- begin certificate --
.key qui commencent par --- begin rsa private key ---
j'ai pour le serveur apache2 plein de fichier .pem. J'avais créé les certificats avec apache2-ssl-certificates
Je me demandais quel genre de fichier dowkd.pl doit lire (les .pem, les .crt, les .key?). Je suppose que ce sont ceux en .key (avec la clé privée rsa),mais j'en suis pas sûr.
Merci.
Quentin
[^] # Re: utilisation dowkd.pl
Posté par lom (site web personnel) . Évalué à 2.
Pour ca il te faut extraires la cle publique de tes cles privees :
ssh-keygen -y -f fichier.key > id_sslpuis utiliser dowkd.pl sur le fichier id_ssl.
En tout cas, cest comme ca que ca marche pour ssh-vulnkey (installe par la mise a jour des paquest debain), et je crois me souvenir (lien que je ne retrouve plus) que c'est pareil pour dowd.pl.
# Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à -9.
Il n'y a pas si longtemps pendant un mois il n'y avait pas eu de mise à jour de sécurité, car le responsable n'était pas disponible.
Debian étant une distribution communautaire elle est dépendantes des bonnes volontés.
Dans le cas d'openSSL le mainteneur a fait plus par ignorance combiné avec un problème sérieux de communication que par mauvaise volonté une énorme bêtise.
La aussi Debian montre les limites du développement bénévole. Il n'y a visiblement pas la possibilité de mettre plusieurs mainteneurs sur des paquets dits "sensibles"
Les distributions commerciales dérivées de Debian sont encore plus coupables. Ayant plus de moyen surtout celles visant la clientèle professionnelle devraient contrôler les paquets sensibles pour la sécurité. Elles ne l'ont pas fait. J'espère pour elles que cela n'aura pas trop de conséquence sur leur avenir commercial
Pour finir aux tenant de la gratuité : la sécurité peut être libre mais ele n'est pas gratuite….
[^] # Re: Limite du développement bénévole
Posté par Corto . Évalué à 7.
[^] # Re: Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à -2.
[^] # Re: Limite du développement bénévole
Posté par Jeanuel (site web personnel) . Évalué à 1.
On ne peut pas savoir.
[^] # Re: Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à 2.
Etant une société commerciale ayant son fond de commerce dans le domaine des serveurs d'entreprises elles ne peut se permettre ce genre de bêtises. Ils testent donc soigneusement leur produits
@ceux qui me moinssent:
Je n'ai jamais dit ni ne pense que Debian est une "mauvaise" distribution mais du fait de sa structure bénévole aux ressources limitées n'est pas en mesure de garantir une sécurité nécessaire au monde de l'entreprise.
Cela dit je souhaite bien du courage aux Sysadmin de machines sous Debian et dérivées ils vont avoir du boulot.
[^] # Re: Limite du développement bénévole
Posté par Moonz . Évalué à 7.
En même temps, tu peux faire tous les tests du monde, une faille qui fait que le nombre de clefs générées ne soit plus "que" de 250000, va la mettre en évidence avec tes tests...
[^] # Re: Limite du développement bénévole
Posté par bubar🦥 (Mastodon) . Évalué à 2.
parceque le fait de parler de X quant Y a un problème revient quasiment à dire "X est mieux que Y parceque" ok, il y a un parceque.
Mais cela fait un peu "profiter d' une faiblesse temporaire de Y pour pousser X," donc "se tirer dans les pates" entre gens du libre. (/troll Ubt à l' habitude, okok)
Et les pates, je les préfère corbonara.
Blague à part, il m' a semblé lire à gauche à droite qu' il était nécessaire de sanctionner le mainteneur. "bouh c est un vilain, lynchons le". Bon ok c' est une bourde. (une énorme vue les impacts tant technique que chronophage, et qu impactant l' image) mais ceux criant au loup peuvent ils assurer que de leur main ils ne feront pas de bourdes ?
J' aurai envie de dire "ok le mainteneur à ch**** dans la colle mais pourquoi personne ne l' a vu et pourquoi pendant si longtemps ?". C' est bien, il me semble, un problème de contrôle, de relecture. Et dans le fond un problème de moyens. Humains. (la meilleure organisation de travail au monde ne peux remplacer le nombre de travailleurs). Donc il me semblerait juste de dire quelque chose comme "le mainteneur a suxé, l' équipe à suxé par absence de vérif, mais finalement nous suxons tous un peu" (surtout ceux qui passent trop de temps à moulefr-é... car ne serait ce qu' une petite page de doc permet à d' autres de faire un audit de plus de cod) Bref on est peut être tous un peu 'coupable', au moins de ne pas assez participer.
[^] # Re: Limite du développement bénévole
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Moi j'imagine que PLEIN de personnes ont vu ce patch. Mais comme aucune personne n'a les compétences en cryptographie pour dire que ce patch est bien ou non, personne n'a cru bon de palabrer sur la question publiquement tout simplement parce que si LE MAINTENEUR du paquet à appliqué ce patch, c'est que LUI, SAVAIT CE QU'IL FAISAIT.
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 2.
Ce "patch" est noyé dans d'autres patchs (le tout fait 3876 insertions(+), 722 deletions(-)).
[^] # Re: Limite du développement bénévole
Posté par Frédéric Péters (site web personnel) . Évalué à 2.
Restent 1280 lignes, un tas de changement dans le chemin de perl et ce sont là presque 200 lignes à supprimer, 1076 lignes qui restent. D'autres opérations faciles pourraient suivre (genre isoler le code pour PIC).
Ça minimise un peu ta mesure; même si de loin j'aurais préféré des patches bien isolés et à la fonction précisément documentée.
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 5.
Oui.
Mais pour information, Red Hat emploie Mark J. Cox qui est un des quatres "core team" d'OpenSSL.
> On ne peut pas savoir.
On peut le savoir (après coup). Red Hat publie tous les infos. En voici un résumé (par Mack J. Cox :-)) :
http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)
Il serait bien que les autres distributions fassent de même.
[^] # Re: Limite du développement bénévole
Posté par Cédric Chevalier (site web personnel) . Évalué à 8.
Forcément, là ça change tout. Il utilise quelle distrib Chuck Norris, histoire d'avoir un truc vraiment secure ?
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 4.
Je n'ai pas dit que ça changait tout. Et j'ai dit que Red Hat n'était pas à l'abris d'une telle mésaventure.
> Il utilise quelle distrib Chuck Norris, histoire d'avoir un truc vraiment secure ?
http://www.vtech-jouets.com/index.php?art=54&th=384
[^] # Re: Limite du développement bénévole
Posté par pampryl . Évalué à 5.
Mandriva et RH font aussi des annonces en matières de sécurité, de vulnérabilité et elles font aussi des erreurs dans la maintenance de certains paquets.
D'ailleurs debian est très utilisé en entreprise malgré l'absence de support proche du développement car la communauté est jugée mure et le travail sérieux. ça n'empêche pas des boulettes...
D'ailleurs, dans une distribution maintenue par une société, qu'elle est la garantie que le contenu des paquets est vérifié par d'autres personnes que le mainteneurs? Ah bon il n'y en a pas? Ben mince alors... j'ai payé donc je pensais que...
D'ailleurs, avec une distribution non liée à une entreprise, il y a surement plus de chances que les choses soient clairement signalées. (Les autres auraient plus tendance peut être à garder ça dans un cadre limité... histoire de pas effrayer les clients...)
Enfin, c'est ma vision... je peux me tromper.
[^] # Re: Limite du développement bénévole
Posté par brunus (site web personnel) . Évalué à -2.
Bon ce n'était que des périphériques flingués, ça n'affecte pas la sécurité d'un serveur, d'un réseau ou de données...mais c'est tout de même bien gras comme boulette !
[^] # Re: Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à -2.
Pour info : un lecteur détruit coute dans les 100 € montage compris. Le boulot des sysadmin dans le cas de la boulette de Debian ne va pas seulement se résumer à apt-get update apt-get upgrade mais à la regénération de toutes les clés de leurs systèmes. Cela prend du temps et si debian est gratuit, les Sysadmins ne sont pas des esclaves de dernière catégories mais ont un coût horaire qui dépasse largement le prix d'un peu de matériel détruit.
[^] # Re: Limite du développement bénévole
Posté par ohnoes . Évalué à 10.
C'est une boulette de LG, qui fait du matériel de merde.
[^] # Re: Limite du développement bénévole
Posté par modr123 . Évalué à 6.
lg a merdé pas mandrake
[^] # Re: Limite du développement bénévole
Posté par Julien Borrel . Évalué à -4.
[^] # Re: Limite du développement bénévole
Posté par Charles-Victor DUCOLLET . Évalué à 0.
[^] # Re: Limite du développement bénévole
Posté par Gniarf . Évalué à 3.
[^] # Re: Limite du développement bénévole
Posté par BAud (site web personnel) . Évalué à 9.
- le problème est lié initialement à LG qui a reconnu le non respect des normes (utilisation d'une commande de flush pour "réinitialiser" leur firmware : d'où perte du firmware rendant inutilisable le lecteur). LG a par la suite fourni une manipulation et un firmware permettant de récupérer les lecteur et flasher un firmware corrigé
- la commande en cause était envoyé lors du boot du kernel 2.4.22, conformément aux normes cela permettait d'initialiser le lecteur pour ceux respectant la norme (mais virait le firmware pour les lecteurs LG)
- le kernel 2.4.22 était fourni avec Mandrake 9.2, Suse 9.2 (iirc) et d'autres distributions ont été aussi touchées (voir leurs bugtracking respectifs, il y avait quelques développeurs qui y avaient laissé leur lecteur et racheté un pour 20 € pensant qu'il était trop ancien et avait lâché), simplement c'est Mandrake dont le planning de sortie était en premier qui a mis le problème en évidence, de plus en plus de monde étant touchés dans les forums et il a bien fallu se rendre compte qu'il y avait un bug quelque part (mais en fait pas dans le kernel hein, ni dans Mandrake)
- donc bon le matériel défectueux ça arrive, le non respect des normes ce n'est pas la bonne manière de faire, certains l'ont appris à leurs dépends (et aux dépends de leurs clients, ce qui est déjà plus dommageable)
- sur cet épisode, LG a reconnu ses torts et Mandrakesoft avait publié un avertissement dans les errata et notes de version, ce qui est la bonne manière de réagir en communiquant sur le souci et indiquant une résolution
vala, j'espère que c'est bien clair ? quelques infos complémentaires sur http://www.pcinpact.com/actu/news/Lecteurs_LG_Mandrake_92_Re(...) et http://www.zdnet.fr/actualites/informatique/0,39040745,39128(...)
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 9.
Certes, mais ça peut arriver. Le 0 risque n'existe pas.
Debian est un projet basé sur le volontariat, ça a ses limites. Le proprio a aussi ses limites.
Ce n'est pas la connerie du mainteneur qui pose question. C'est-à-dire d'avoir virer une ligne de code alors qu'il ne fallait pas. Tout le monde peut ajouter des conneries (par "bêtise" (et ça touche tout le monde) ou simplement par inattention).
Ce qui pose question, c'est d'avoir une faille d'un patch spécifique durant presque 2 ans ! Où est l'audite ?
Ce qui pose question, c'est que les paquets Debian sont assez "obscures". Un gros patch (108 files changed, 3876 insertions(+), 722 deletions(-)) au-lieu de séparer les patchs. Les autres distributions (non basées sur Debian) séparent les patchs, ça facilite grandement l'audit et les remontés upstream.
Ce qui pose question, est que Debian veut faire de la sécurité et se prétend meilleur que les projets upstreams (voire par exemple le débat avec Mozilla/Firefox où Debian voulait faire les patchs de sécurité et n'aimait pas que Mozilla audite ses patchs). Dans le domaine de la sécurité, c'est l'upstream qui faut absolument privilégier.
Ce qui pose question aussi, c'est Canonical. Ça la fout mal pour sa crédibilité en entreprise (genre "on vous vend un truc, mais on audite rien").
Je pense qu'il serait bien bête de mener le mainteneur au bucher. Debian est sur la base du volontariat, si quelqu'un peut faire mieux, qu'il donne un coup de main au mainteneur. Beaucoup apprécient cet esprit de Debian et en connaissent les atouts et faiblesses.
[^] # Re: Limite du développement bénévole
Posté par Romain Be. . Évalué à 5.
Là c'est plutot faux en général.
La politique générale de packaging depuis un moment est justement de séparer les patches sur les sources upstream et de les appliquer à la compilation.
Les paquets avec un gros patch debian/ + upstream n'existent quasiment plus, et un format de paquet dit "wig and pen" et à l'étude, où le dossier debian/ serait carrément distribué séparement, forcant les patch upstream a etre séparé des modifs de packaging.
Ce qui pose question, est que Debian veut faire de la sécurité et se prétend meilleur que les projets upstreams (voire par exemple le débat avec Mozilla/Firefox où Debian voulait faire les patchs de sécurité et n'aimait pas que Mozilla audite ses patchs). Dans le domaine de la sécurité, c'est l'upstream qui faut absolument privilégier.
Oui et non.
Tout dépend de ce que tu entends par "faire de la sécurité". En particulier, upstream ne se soucie en général pas des interactions de son programme avec le reste de la distribution, ce que debian gère. De ce point de vue là, debian peux avoir à modifier des programmes sans qu'upstream se sente concerné.
Ce qui pose question aussi, c'est Canonical. Ça la fout mal pour sa crédibilité en entreprise (genre "on vous vend un truc, mais on audite rien").
C'est valable pour énormément de paquets des multiverse, universe et compagnie. Cela montre aussi l'énorme dépendance de Ubuntu envers le packaging Debian.
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 1.
J'ai regardé pour iceweasel (2.0.0.14), ça ne semble toujours pas le cas :-)
J'ai manqué de chance ?
Je dis que ça ne semble pas le cas, car je n'en suis pas sûr.
En passant, alors que iceweasel n'est pas audité par Mozilla, il est plus patché que celui de F8 :-) (même version).
Notons aussi comme il est étrange de voir Debian qui gueule après OpenSSL qui n'a pas audité ses patchs, alors que Debian ne voulait pas que Mozilla les audites ou n'a pas fait (encore ?) ce qu'a demandé Mozilla pour les auditer.
> C'est valable pour énormément de paquets des multiverse, universe et compagnie.
Certe. Mais openssl/gnupg/etc font partit des programmes hypra sensibles (ça n'a rien à voir avec la connerie de LG).
[^] # Re: Limite du développement bénévole
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
C’est un problème dans la façon dont le paquet est distribué sur les miroirs, mais en interne les mainteneurs utilisent git et tous les patches sont correctement séparés dans la version distribuée sur git.debian.org.
Notons aussi comme il est étrange de voir Debian qui gueule après OpenSSL qui n'a pas audité ses patchs, alors que Debian ne voulait pas que Mozilla les audites ou n'a pas fait (encore ?) ce qu'a demandé Mozilla pour les auditer.
Personne n’a rien contre de l’audit de patches, au contraire. Par contre, une licence qui empêche de publier lesdits patches avant qu’ils aient été audités par une entité sur laquelle tu n’as aucun contrôle, ça c’est un problème.
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 1.
Apparament pas pour iceweasel :
http://svn.debian.org/viewsvn/pkg-mozilla/iceweasel/
> Par contre, une licence qui empêche de publier lesdits patches avant qu’ils aient été audités par une entité sur laquelle tu n’as aucun contrôle, ça c’est un problème.
C'est faux.
Si les patchs ne sont pas audités (et validés) alors tu ne peux pas utiliser le nom Firefox. Mais tu peux publier les patchs faire iceweasel, etc. Tout ce que tu ne peux pas faire, c'est utiliser le nom Firefox et ses logos (ce qui est le cas par défaut, et il faut activer une option pour les utiliser).
[^] # Re: Limite du développement bénévole
Posté par nyquist . Évalué à 2.
C'est faux.
C'est vrai.
C'est d'ailleurs pour ça que debian utilise iceweasel et non pas Firefox. Après si la Fondation Mozilla veut auditer le code des patchs de iceweasel rien ne l'en empêche (même pas les Dev Debian qui ronchonne dans leur coin).
Maintenant quand on vois la qualité des patchs Debian, on comprends la position de la MoFo...
extrait de la MPL :
6.3. Derivative Works
If You create or use a modified version of this License (which you may only do in order to apply it to code which is not already Covered Code governed by this License), You must (a) rename Your license so that the phrases "Mozilla", "MOZILLAPL", "MOZPL", "Netscape", "MPL", "NPL" or any confusingly similar phrase do not appear in your license (except to note that your license differs from this License) and (b) otherwise make it clear that Your version of the license contains terms which differ from the Mozilla Public License and Netscape Public License. (Filling in the name of the Initial Developer, Original Code or Contributor in the notice described in Exhibit A shall not of themselves be deemed to be modifications of this License.)
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 1.
Ce que manifestement tu ne veux pas comprendre, c'est que Debian n'est pas obligé d'utiliser tout le temps le nom Firefox !
Le "Firefox" dans Rawhide (Fedora) est souvent nommé Minefield (le nom donné automatiquement lorsqu'on ne demande pas explicitement Firefox). C'est Minefield si un patch n'a pas été édité, si c'est une version béta (pour FF3 beta 5 c'est OK), etc.
Et ça ne dérange personne chez Fedora.
Si vous ne voulez/pouvez pas utiliser le nom Firefox (et ses logos), c'est qu'une options à virer. Les autres le font sans problème. Mais virer une option pour Debian devient insurmontable...
Franchement, c'est être tête de mule.
[^] # Re: Limite du développement bénévole
Posté par buju . Évalué à 2.
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à 2.
Ce n'est pas le cas, et de loins :
http://blog.orebokech.com/2008/05/some-diffgz-statistics.htm(...)
One of the issues under discussion is that some Debian packages don't use a patch system and ship all their modifications unseparated in the Debian .diff.gz, which makes it harder or impossible to extract patches later on and to understand why some changes were made.
...
Out of curiosity, I did a quick scan of my local mirror to see how many packages ship changes outside debian/ in their .diff.gz, and I was surprised to see that 4803 source packages out of 11853 (40%) do so!
[^] # Re: Limite du développement bénévole
Posté par totoenstr (site web personnel) . Évalué à 4.
Pourquoi ces distributions n'ont pas ete touchees par la faille de vmsplice ?
Ubuntu est developpe par une societe commerciale ce qui ne l'a pas empeche de reprendre le paquet touche par cette faille.
Des benevoles participent egalement aux developpements ou en tout cas aux packing des distributions cites au-dessus. Je ne vois pas en quoi elles sont plus a l'abris que Debian de rencontrer des problemes similaires... Sachant que Debian a un systeme de qualite pousse pour ses paquets.
Pour finir ma reference en matiere de securite est OpenBSD qui n'est pourtant pas une societe ....
[^] # Re: Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à -3.
Ubuntu est certe une société commerciale mais visiblement pas de niveau professionnel. Dans le cas d'openSSL ils n'ont visiblement rien contrôlé......
Des benevoles participent egalement aux developpements...
Certe et c'est tant mieux pour eux, mais ces distributions ont un service de contôle de qualité et si cela coince ils peuvent engager des professionnels car ces sociétes ont des moyens financiers conséquents.
Sachant que Debian a un systeme de qualite pousse pour ses paquets.
Il reste à espèrer que le mainteneur d'openSSL est un cas unique dans son genre, parce que sinon bonjour l'angoisse ......
[^] # Re: Limite du développement bénévole
Posté par wismerhill . Évalué à 3.
[^] # Re: Limite du développement bénévole
Posté par Anonyme . Évalué à 3.
N'importe quoi. L'erreur est humaine, et c'est pas par ce que tu es payé que tu n'es plus humain. Une personne employée par une societé aurait très bien pu faire ce genre d'erreur, et on trouve par exemple egalement des failles très importantes dans les logiciels de MS.
Ce que ca montre peu etre, c'est qu'il y a sans doute des procedures à ameliorer chez Debian pour tenter eviter ce genre d'erreur, mais ca n'a rien à voir avec le fait que le développement soit bénévole.
[^] # Re: Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à -4.
En pratique c'est l'organisation du système des mainteneurs de Debian qui est en cause. Vont-ils changer quelque chose, seul l'avenir le dira !
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . Évalué à -2.
Si le mainteneur n'avait fait que le minimum (en respectant sa mission de base évidemment), il n'y aurait pas eu problème.
[^] # Re: Limite du développement bénévole
Posté par Unixfix le Gaulois . Évalué à -4.
Cependant à l'avenir, du moins si Debian ne veut pas perdre son crédit, il convient de changer leur système de mainteneurs. Il est évident que confier à un seul homme la responsabilité de paquets essentiels pour la sécurité est non seulement trop léger pour ne pas dire coupable.
Debian est une association de bénévoles offrant leur temps libre. Vu la taille de la distribution il n'est pas rare qu'un mainteneur soit responsable de plusieurs paquets.
Il est donc facile de comprendre, que Debian manque de moyens humains, donc dans leur cas de bénévoles....
[^] # Re: Limite du développement bénévole
Posté par Christophe Merlet (site web personnel) . Évalué à 8.
La communauté Debian qui se félicitait d'être un bon millier explique maintenant qu'ils ne sont pas assez nombreux !!
Pour info, maintenir une distribution est un boulot faisable par une seule personne pour autant qu'elle se limite à packager et intégrer les paquets upstream sans s'amuser à vouloir modifier le code.
Slackware le fait.
Moi même je l'ai fait pour ma pomme pendant 3/4 ans pour une distrib plutôt complète de 700 paquets sources sur mon temps libre en plus des traductions GNOME.
http://ftp.redfoxcenter.org/pub/RedFox/MyRPMs/
Le problème de certains packagers et de maintenir dans les faits un fork du paquet upstream sans prendre la peine de faire valider ses patchs par qui que se soit. On comprend pourquoi certains développeurs refuse de voir distribuer leur soft patché avec le même nom, surtout quand ces patchs ne leur amènent que des plaintes d'utilisateurs.
# Le problème OpenSSL dans Debian et ses dérivés vu par Roland Mas
Posté par GeneralZod . Évalué à 2.
Bonne lecture !
http://roland.entierement.nu/blog/2008/05/15/branle-bas-sshs(...)
[^] # Re: Le problème OpenSSL dans Debian et ses dérivés vu par Roland Mas
Posté par lamiricore . Évalué à 1.
D'ailleurs Roland Mas évoque un problème pour toutes les clés utilisées sur un système debian ou dérivées et non pas seulement pour les clés générées sur un tel système.
Ce ne sont pourtant pas les mêmes conséquences. L'avis de sécurité de Debian n'évoque pourtant pas ce problème. Donc je vois pas trop où il chope cette info?
[^] # Re: Le problème OpenSSL dans Debian et ses dérivés vu par Roland Mas
Posté par Ozz . Évalué à 1.
Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.
[^] # Re: Le problème OpenSSL dans Debian et ses dérivés vu par Roland Mas
Posté par Alban Crequy (site web personnel) . Évalué à 1.
Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.
# Liste des clés possibles
Posté par Olivier Tétard (site web personnel) . Évalué à 10.
Résultat des courses : le générateur de nombre aléatoires, composant critique de nombreux systèmes de chiffrements, n'est au final pas si aléatoire que ça, voire carrément prévisible.En effet, c'est carrément prévisible, le seul bout d'aléa étant le numéro du processus (qui est codé sur 15 bits), cela fait 32 767 clés possibilités... Ce qui s'avère très peu.
Les clés possibles de 1024, 2048 et 4096 ont été générés par H D Moore : [http://metasploit.com/users/hdm/tools/debian-openssl/]. Il ne reste donc plus qu'à tester toutes les clés.
À lire aussi, mais en anglais : http://blog.drinsama.de/erich/en/linux/2008051401-consequenc(...)
Olivier;
[^] # Re: Liste des clés possibles
Posté par rouby (site web personnel) . Évalué à 2.
[^] # Re: Liste des clés possibles
Posté par Florian Hatat . Évalué à 1.
[^] # Re: Liste des clés possibles
Posté par Beretta_Vexee . Évalué à 3.
Il y a donc matière a optimisation quand au cassage des clés, en triant les clés des plus probables au moins probable, et non uniquement en fonction de la taille.
# Est-ce que quelqu'un saurait pourquoi
Posté par Thomas Maurin (site web personnel) . Évalué à 3.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par IsNotGood . Évalué à -7.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Thomas Maurin (site web personnel) . Évalué à 2.
Or, à part quelqu'un qui, trois posts après dit : "parce que ça doit aussi marcher sur windows ?", je n'ai vu personne d'autre y réagir.
Alors que ça m'intéresserait sérieusement de savoir pourquoi ; si y'a une explication (comme effectivement, la portabilité du code)...
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par IsNotGood . Évalué à 2.
Notons que beaucoup d'OS n'ont pas un générateur de nombres aléatoires de qualité.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Thomas Maurin (site web personnel) . Évalué à 2.
Je viens de trouver et de lire ce que disait le mainteneur en 2006 sur la liste d'OpenSSL[1] et je crois comprendre un peu mieux comment ça fonctionne...
Par contre je me demande toujours pourquoi son patch causait une telle perte d'entropie.
[1] http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par IsNotGood . Évalué à 3.
Ce patch ne pause pas de problème. Mais ce n'est pas ce patch qui a été appliqué, mais celui ci (je le réécris) :
/* MD_Update(&m,buf,j);*/
...
#ifndef PURIFY
MD_Update(&m,buf,j); /* purify complains */
#endif
Oui, le premier MD_Update a été mis en commentaire. Or c'est lui qui ajoute de l'entropie.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par allcolor (site web personnel) . Évalué à 1.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Thomas Maurin (site web personnel) . Évalué à 1.
Those unitialised values are generated in the random number generator.
http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
Mais je ne comprends pas en quoi l'initialisation réduit l'entropie (fonctionnement de /dev/random ?).
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par herodiade . Évalué à 3.
Mais effectivement, ce n'est qu'un car particulier et non nécessaire : même si le buffer passé à openssl est non initialisé et remplis de 0 par l'OS, l'aléas retourné par openssl est suffisamment bon. Les devs d'openssl auraient pu décider de se passer de ce petit plus d'aléas potentiel sans grande perte.
ps: et, encore une fois, ce n'est pas le fait de virer l'utilisation de mémoire non initialisée qui pause problème, en soi, c'est le fait d'enlever au passage l'appel à la fonction qui mixe cette zone de mémoire avec du vrais aléas.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Gniarf . Évalué à 5.
manque de pot, le patch idiot de y'a 2 ans fait que ce bloc est initialisé à zéro (ou une valeur constante genre A5, on s'en fout), du coup ce même générateur de nombres aléatoires est initialisé avec seulement 2^15 valeurs possibles (les valeurs possibles du pid du processus) et c'est tout petit, 32768
du coup au lieu d'avoir des tas de clés possibles tu en avais juste 32768 possibles (car avec deux valeurs identiques données à srand(), tu tireras toujours les mêmes séquences de nombres aléatoires)
si tu préfères, ce patch faisait retourner seulement 32768 séquences possibles (et prévisibles) de nombres au lieu de plusieurs multilolilliards de séquences, enfin de clées, possibles.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
manque de pot, le patch idiot de y'a 2 ans fait que ce bloc est initialisé à zéro (ou une valeur constante genre A5, on s'en fout),
J'espère que ce n'est pas aussi simple que ça, parce que si la sécurité d'openssl repose sur la valeur d'un bloc mémoire non initialisé, ben pour le coup j'ai encore plus peur.
Sinon, qu'elle est la taille du SEED ? Dépend-elle aussi de la taille de la clé ?
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Philippe F (site web personnel) . Évalué à 1.
Tu as raison d'avoir peur, toutes les distrib debian depuis 2006 utilisent une version d'OpenSSL qui n'utilise presque pas d'entropie.
Maintenant OpenSSL lui-même fonctionne correctement.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par brunus (site web personnel) . Évalué à 3.
Le paquet incriminé à été injecté dans Debian Unstable le 17.09.2006 :
"The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17"
La Ubuntu Dapper Drake, donc la LTS 6.06 a donc été épargnée...elle est basée sur un freeze de Sid en novembre ou Décembre 2005...le paquet incriminé est en version 0.9.8a dans cette distribution (j'ai vérifié), qui est toujours maintenue puisque le support est de 3 ans pour la verison desktop et de 5 ans pour la version serveur.
La Ubuntu Edgy Eft, 6.10, est basée sur un freeze de Sid en Juillet 2006...la version du paquet openssl est la 0.9.8b (je n'ai pas vérifié je n'ai plus de Ubuntu dans cette version).
Ces deux versions de Ubuntu devrait donc être épargnées bien qu'elles soient sorties en 2006.
Je ne pense pas que les mainteneurs des paquets aient patché leurs ces deux versions en injectant en même temps le bug au moment de la mise à jour sur Sid.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par gc (site web personnel) . Évalué à 3.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par gallenza . Évalué à -1.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Cédric Chevalier (site web personnel) . Évalué à -1.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Anonyme . Évalué à 3.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Troy McClure (site web personnel) . Évalué à 7.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par IsNotGood . Évalué à 2.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par benoar . Évalué à 2.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par IsNotGood . Évalué à 3.
OpenSSL utilise /dev/random (sous Linux), c'est le patch de Debian qui empêche OpenSSL d'utiliser /dev/random.
# Une réaction sur Debian Planet en français
Posté par Amaury . Évalué à 10.
Je lis sur http://planet-fr.debian.net/ un post de Roland Mas intitulé "Branle-bas SSH/SSL" publié le 15 mai. Ce message, assez clair par ailleurs sur le fait que les conséquences de cette vulnérabilité dépassent largement le cadre de la simple distribution Debian (et dérivées) puisque les clefs et certificats pourris ont pu être copiés un peu partout ailleurs, ce message donc est présenté comme un rectificatif des informations incorrectes ayant pu être publiées ci et là.
Et il présente donc fort à propos l'origine du problème de la façon suivante : "Le cœur du problème : pour des raisons tout-à-fait légitimes, et suite à une mauvaise communication avec les auteurs amont d'OpenSSL, les versions d'OpenSSL (...) utilisaient un générateur de nombres pseudo-aléatoires (...) absolument pas aléatoire."
Soit j'ai mal compris la phrase ci-dessus, soit Roland est en train de nous expliquer qu'une faille de sécurité majeure, impliquant l'un des systèmes de sécurité les plus utilisées au monde (SSH, PKI, VPN), qui risque de mettre gravement en cause la crédibilité du logiciel libre aux yeux de pas mal de monde, et accessoirement qui va me faire perdre mon week-end à mettre à jour les nombreuses machines dont j'ai la charge, cette faille de sécurité donc a été introduite pour des raisons tout à fait légitimes.
Vous verrez, dans 2 jours il va nous sortir qu'en fait "it's not a bug, it's a feature".
J'ai du mal à voir les "raisons légitimes" qui justifieraient qu'un contributeur touche à un composant critique au petit bonheur la chance pour faire plaisir au debuggeur et que personne n'y trouve rien à redire.
[^] # Re: Une réaction sur Debian Planet en français
Posté par Kerro . Évalué à 2.
Mais ce n'est qu'une bourde. Enorme, soit. Gigantesque même, mais voilà, ce mainteneur est aussi imparfait que toi et moi.
On peut par exemple imaginer que sur 1000 corrections qu'il a fait, 950 sont parfaitement bonnes, 29 sont moyennes, 10 sont erronées... et 1 est la pourriture que nous avons là. Ca fait du 1% d'erreur, et 0.1% de grosse erreur. Ca m'emxxxxx vraiment beaucoup beaucoup (j'ai environ 60 machines à bricoler, toutes en production) mais bon ce n'est pas pire que la précédente grosse faille dans le noyau.
[^] # Re: Une réaction sur Debian Planet en français
Posté par Ozz . Évalué à 0.
Ce fiasco montre plusieurs disfonctionnements dans le developpement de Debian, faut arreter avec les "ça peut arriver à tout le monde", "l'erreur est humaine". C'est vraiment l'excuse qui évite de la remise en question alors qu'elle me semble indispensable.
En l'occurence le problème le plus frappant est l'absence d'évaluation de la pertinence d'introduire un patch, de manière général et encore plus sur des paquets critiques comme openssl.
Comment la disproportion entre l'interet réel du patch et ses conséquences peut échapper à Roland Mas.
Viennent ensuite les problèmes de reviews par l'upstream (la demande et la pseudo confirmation sur la liste openssl-dev, c'est bien dans l'intention, mais ça a été fait un peu à la légère) , et la review interne, là je ne sais pas comment ça se passe chez Debian, les patchs n'ont pas l'air d'être contre signé - par des teams de reviews par catégorie (exemple au hasard, sécurité, qui vérifierait sérieusement les patch passé sur des paquets comme openssl ) ça serait probablement une bonne idée, si ce n'est pas déjà en place.
J'adore Debian, mais il me faut un peu plus qu'"un désolé on a merdé", j'espère une sérieuse reflexion sur toute la chaine de validation et voir apparaitre une politique de patch des logiciels upstream qui prenne en compte cet incident.
[^] # Re: Une réaction sur Debian Planet en français
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
> merdé", j'espère une sérieuse reflexion sur
J'aimerais savoir combien de développeur d'OpenSSH utilisent debian comme poste de travail ?
S'ils sont plusieurs, eux non plus n'auraient pas regarder leur propre code ni vu l'erreur...
Sinon, y a pas moyen de faire un md5sum des clefs et de regarder la répartition de ces clefs dans un espace pour voir la bonne équi-répartition ? Certes, debian a merdé, mais comme beaucoup le disent, OpenSSL et OpenSSH n'ont pas de programme de vérification /a posteriori/ ?
Lorsque je programmais plus, on considérait que le code était valide s'il passait tous les cas tests. Si un codeur n'était pas content parce qu'on lui cassait une fonctionalité, on le renvoyait à l'écriture d'un cas test ;-)
Avoir des patch signé, reviewé, co-signé... C'est bien mais tout cela reste bien humain et parfois cela n'empêche de faire des grosses conneries. Il suffit de voir le nombre de personnes travaillant par exemple autour des ministres et d'entendre parfoit les grosses bourdes qu'ils font... (autre exemple, l'hélice du Charles de Gaule)
Mesurer l'aléa sur des programmes de crytographie me semble faisable et une distribution pourrait lancer le test avant de sortir une version stable de sa distribution. Un peu comme les tests ACID et autres pour les navigateurs.
Bref, pour prendre exprès le contrepied de certaines opinions qui se sont exprimés ici, développer un programme comme openssl ou openssh sans avoir un environnement permettant de valider de manière automatique (ou semi auto) la solidité de l'implémentation me semble peu cohérent.
Je précise pour finir que je ne sais pas du tout comment sont développé openssl et openssh en pratique.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 1.
0 manifestement.
Si les patchs ne sont pas remontés upstream, c'est un signe qui ne trompe pas.
[^] # Re: Une réaction sur Debian Planet en français
Posté par wismerhill . Évalué à 2.
Tu en génère 1e15 et tu vérifie qu'il n'en a pas généré plus d'une ou deux d'identiques?
[^] # Re: Une réaction sur Debian Planet en français
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Enfin, tout cela existe déjà pour mesurer la qualité d'un générateur de nombre aléatoire.
J'ai pas l'impression de demander la lune en me posant la question de la qualité de l'aléa /a posteriori/ dans ce genre de programme. Je serais même très surpris qu'il n'y en ai pas déjà ?
Comment veut-tu que les développeurs améliorent la qualité des algorithmes s'ils n'ont pas les moyens de faire de mesures ? Ou alors, ils se basent sur des algorithmes publiés par des scientifiques mais ne vérifient pas par eux-mêmes de l'implémentation ?
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 2.
Les brute-force n'ont des chances de réussir que si on connait déjà une faille...
Ça se mord la queue.
[^] # Re: Une réaction sur Debian Planet en français
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
> une faille...
Ou si l'algorithme n'est pas bon...
Comment vérifie-tu ton algo si tu n'as pas de cas test ?
De plus en plus, on met de l'aléa dans le coeur des systèmes pour ne pas faire des choses prévisibles qui se révèlent dangeureuses en cas de bogue (inévitable) : adresse ELF variable dans le noyau lors du chargement de bibliothèque, séquence IP aléatoire, numéro de PID aléatoire...
Mais du coup, avec ces aléas, cela devient très difficiles pour un humain de voir s'il y a un problème à ce niveau la. C'est normal, cela a été fait pour !
Donc il faut bien vérifier la qualité de ces aléas via des mesures statistiques ET automatiques.
Les brutes forces ont aussi des chances de réussir si on n'est pas capable de certifier la qualité de son aléa.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 2.
Avec ssl il te faut des siècles pour faire toutes les combinaisons.
> Donc il faut bien vérifier la qualité de ces aléas via des mesures statistiques ET automatiques.
Ça semble tout à faire mesurable pour les adresses variables, PID, etc.
Pour des trucs de 1024 bits, à moins d'une "catastrophe" comme ici, ça doit être un sacré défi.
> Les brutes forces ont aussi des chances de réussir si on n'est pas capable de certifier la qualité de son aléa.
Pas vraiment. Si tu ne sais pas qu'openssl a une faille, la tentative de brute force peut prendre des plombes (comprendre siècle).
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 1.
comme disais Sytoka Modon , il y a des moyens pour tester un générateur aléatoire et sa répartition (il me vient à l'esprit la méthode du khi², mais ca ne doit pas être la seule)
Et les stats nous informe qu'on a pas besoin de tester tout l'ensemble des possibilité pour avoir une idée du générateur.
Alors je dis pas que ca se fait en claquant des mains, mais ca reste faisable, et a mon avis , techniquement calculatoire dans un délai raisonnable (moins d'une semaine) meme pour des nombres de 1024 bits.
[^] # Re: Une réaction sur Debian Planet en français
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Les graphiques sont bluffants !
http://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 2.
Je ne suis pas un mathématicien, et je suis peut-être dans l'erreur.
M'enfin, il n'y a une différence entre tester si du 32 bits est alétoire et le qualifier ; et si du 1024 bits (voire plus) est alétoire et évaluer sa qualité.
Juste pour vérifier si "seulement" 512 bits sont alétoires...
> Et les stats nous informe qu'on a pas besoin de tester tout l'ensemble des possibilité pour avoir une idée du générateur.
Les stats nous enseignent aussi que pour avoir une bonne présition, ben il faut beaucoup d'échantillons.
> Alors je dis pas que ca se fait en claquant des mains, mais ca reste faisable, et a mon avis , techniquement calculatoire dans un délai raisonnable (moins d'une semaine) meme pour des nombres de 1024 bits.
la racine carrée de la racine carrée de racine carrée de la racine raccée de 1024 bits donne seulement 18 milliard de milliard de combinaison.
Prenons (soyons fou) 1 milliard de combinaison par seconde, il faut seulement 585 années...
[^] # Re: Une réaction sur Debian Planet en français
Posté par khivapia . Évalué à 2.
ici, la faille d'OpenSSL concerne l'initialisation du générateur aléatoire.
Donc une fois qu'il est initialisé, on peut espérer qu'il soit bon. Ici, la faille ne provient pas du générateur lui-même, du fait que sur 32000 et des brouettes personnes qui utilisent OpenSSL, 2 ont exactement la même suite aléatoire.
Pour déceler ce genre de faille en testant, il ne fallait pas tester le générateur aléatoire à partir d'une session, mais tester uniquement les premiers bits aléatoires, par exemple 1024 pour se donner une marge énorme sur la probabilité des collisions, fournis par chaque session OpenSSL. Autant dire qu'il fallait imaginer assez précisément la faille.
Concernant les tests des générateurs aléatoires, le problème est simple : étant donné n bits, est-ce que ils "ressemblent" à une suite aléatoire ? Plus précisément, on va lui faire passer une batterie de tests, et estimer la probabilité qu'il soit dans telle zone de résultat du test.
Par exemple, sur une suite parfaitement aléatoire de 10 000 bits, il y a une probabilité énorme d'avoir des séquences de 100 bits constants. Si la suite ne vérifie pas ce test, ni d'autres, c'est qu'elle est très particulière. On en tire alors une autre du même générateur, si beaucoup de ces suites ratent des tests, il y a des chances que le générateur soit troué.
[^] # Re: Une réaction sur Debian Planet en français
Posté par TeXitoi (site web personnel) . Évalué à 2.
> et des brouettes personnes qui utilisent OpenSSL, 2 ont exactement la
> même suite aléatoire.
Pas du tout, efface... http://fr.wikipedia.org/wiki/Paradoxe_des_anniversaires
tu peux être sur que sur 32000 clef, au moins 2 on la même, mais la proba que sur 100 personnes, au moins deux aient la même clef est élevé...
[^] # Re: Une réaction sur Debian Planet en français
Posté par TeXitoi (site web personnel) . Évalué à 5.
> comme poste de travail ?
0, OpenSSH est développé dans le CVS d'OpenBSD, donc sous OpenBSD. En effet, il est développé directement pour OpenBSD, et en parallèle, une version portable est réaliser. Voir http://openssh.org/portable.html
OpenSSH n'a pas de faille, c'est OpenSSL qui cause le problème, et uniquement la version d'origine Debian. OpenSSL est un autre projet, qui n'a rien à voir avec OpenSSH ni OpenBSD (à part son utilisation, et que la version OpenSSL d'OpenBSD est patché).
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 1.
Propose ton aide, ils l'accepteront avec grand plaisir. C'est ca l'avantage de l'open source
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 3.
Les deux sont vrais.
Debian a merdé, mais ça peut arriver à tout le monde.
Ce qui est agaçant c'est le :
- "ça peut arriver à tout le monde" DONC "Debian n'a rien à se repprocher".
Ceci est faux.
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 2.
Les dev d'openssl ont un poil la responsabilité vu la superbe documentation du code incriminé, et le fait que valgrind gueule bien.
on dit "la sécu c'est génial faut faire super attention", c'est sur, (ie les dvp de debian ont tort dans une certaine mesure) mais si derrière les parties cryptiques, faut tout deviner tout seul, ca devient encore plus dur.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 4.
Donc le mainteneur ne savait pas ce qu'il fesait, mais il a bien de le faire...
Tu m'expliques ?
> et le fait que valgrind gueule bien.
Garde l'ancien OpenSSL de debian alors...
Oui, un code bien documenté c'est mieux qu'un code mal documenté.
Oui un programme qui passe Valgrind c'est mieux qu'un programme qui fout des tonnes de warning.
Mais un patch qui fout le bordel, c'est pire et de très loin des maux que tu cites.
C'est très bien d'expliquer ce qui c'est passé. Il est clair que le mainteneur Debian n'est pas un demeuré.
M'enfin, c'est de sa faute. Les excuses de code mal documenté, etc ne tiennent pas.
Et ça serait quoi un code bien documenté ?
Un code dans ce goût :
/* NB : ne pas supprimer cette ligne.
Elle n'est pas là pour rien. */
MD_Update(&m,buf,j);
Si le mainteneur pense que la ligne est la pour rien, ben il envoye un patch en upstream et il attend que le patch soit upstream. Pour une chose aussi sensible qu'OpenSSL, ça devrait être fait. Que le code soit mal documenté, qu'il passe mal valgrind, etc.
Si le patch est ignoré durant plus d'un mois, ben il l'envoie à nouveau en poussant gueulante et en demandant des explications.
Il a parfaitement le droit de le faire dans ce cas, car en envoyant un patch il devient un contributeur.
[^] # Re: Une réaction sur Debian Planet en français
Posté par Octabrain . Évalué à 4.
Certains disent même : "If the implementation is hard to explain, it's a bad idea."
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 0.
Et ça serait quoi un code bien documenté ?
Un code dans ce goût :
/* NB : ne pas supprimer cette ligne.
Elle n'est pas là pour rien. */
MD_Update(&m,buf,j);
Si t'es un codeur, je t'embauche pas ...
(d'autant plus qu'une des lignes était bien la pour rien XD)
Donc le mainteneur ne savait pas ce qu'il fesait, mais il a bien de le faire...
Il sait ce qu'il faisait, il a meme demandé conseil à la mailing list, et a pointé les problemes existant.
Mais désolé pour toi, quand tu as un code avec
/*Just use some garbage to add a little entropy*/
MD_UPDATE(...)
[...]
/*We use all the entropy available from /dev/random*/
MD_UPDATE(...)
bizarrement, le risque d'erreur (virer les deux lignes plutot qu'une seule, ...) en faisant le patch est ENORMEMENT diminué.
mais on a déja eu constation de ta mauvaise foi légendaire, tu nous en offre qu'un autre (triste?) exemple.
Si le mainteneur pense que la ligne est la pour rien, ben il envoye un patch en upstream et il attend que le patch soit upstream.
A chaque fois que tu ose faire une modif, tu l'envoie en upstream, tu attend qu'elle revienne (si elle revient!), puis tu continue a travailler (les autres modifs peuvent dépendre de la premiere)? Tu dois pas etre très efficient.
Encore une fois, j'admet tout a fait que le dvp de debian a commis des erreurs (suppressions d'une ligne en trop, pas d'envoie du patch final en upstream , ...)
C'est pas une raison pour le diaboliser, et raconter n'importe quoi.
C'est pas parce qu'il ne vient pas de RH que ca permet de dire franchement n'importe quoi sur son sérieux et sa méthode de travail.
Si le patch est ignoré durant plus d'un mois, ben il l'envoie à nouveau en poussant gueulante et en demandant des explications.
On rapelle que tu demande la modification d'une seule ligne là
Si a chaque fois que tu dois modifier une seule ligne dans openssl, tu dois envoyer un patch (malgré l'accord, quiproquoeste, précédent de la mailing list) avant de continuer ton boulot, l'efficacité, sans vouloir etre vexant, va s'en ressentir.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 1.
Et comme MD_Update() est utilisé 16 fois dans le même fichier source...
Et comme il n'y a pas que MD_Update qu'il ne faut pas virer...
Bref, tu finis par avoir plus de commentaires que de code.
Si tu veux virer une fonction et ne sait pas ce quel fait, ben tu lis le code de la fonction (ou sa doc). Et même s'il y a un commentaire, tu le fais.
Ça se retrouve une fonction :-)
Pour MD_Update, c'est un poil compliqué, mais c'est "int HASH_UPDATE ..." du fichier crypto/md32_common.h.
M'enfin, s'il voulait débugguer, le débuggueur te montre ça en deux cliques. Et un bon débuggueur (comme DDD) ne montre les variables modifiées durant l'appel de la fonction.
Et cette fonction fait clairement des choses (inutile dévoir un débuggueur). Certe je ne sais pas exactement ce que ça fait, mais ça le fait et pas qu'en lecture seule.
Sachant que la fonction modifie ses paramètres d'appel et que ces derniers sont utilisés ailleurs, la conclusion est toute trouvée : Ne pas y toucher !
> bizarrement, le risque d'erreur (virer les deux lignes plutot qu'une seule, ...) en faisant le patch est ENORMEMENT diminué.
Ben il te reste à le faire pour 1 ligne sur 2 d'OpenSSL.
Il y a seulement un peut plus de 440 000 lignes de codes.
Bon plaisir à toi.
Et tu dois le faire le faire puisque tu trouves normale qu'un développeur vire une ligne s'il n'y a pas un commentaire qui dit qu'elle est indispensable.
J'espère ne pas tomber sur ton code.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 3.
Si tu ne le fais pas, t'assume.
Tu ne viens pas pleurnicher après avoir fait ta connerie.
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 0.
Personne.
Ah si tous les anti debian qui viennent dire "deb sapux" sans meme comprendre ce qu'ils disent
(Au rythme de 1 ligne par moi, je confirme, tu n'es pas très efficient pour les corrections de bugs).
[^] # Re: Une réaction sur Debian Planet en français
Posté par Thomas (site web personnel) . Évalué à 1.
> Personne.
Ca te ferais marrer toi de perdre ton temps a regenerer et verifier des centaines de cles/certificats ?
> (Au rythme de 1 ligne par moi, je confirme, tu n'es pas très efficient pour les corrections de bugs).
Au rythme d'une connerie par ligne tu ne l'es pas non plus !
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 2.
J'ai du le faire (et ca peut s'automatiser)
Mais je suis pas venu pleurnicher. J'utilise le libre en sachant qu'il n'y a aucune garantie d'aucune sorte.
Maintenant si tu estime que vu que tu es un client, tout t'es dut et tu peux aller pleurnicher tout le temps je te conseille de prendre un contrat de maintenance, ca ira mieux avec ta philosphie.
Au rythme d'une connerie par ligne tu ne l'es pas non plus !
ca c'est de largumentation objective. On voit la reflexion poussé a son comble.
Quand ca te gene et que tu sais pas répliqué, parce que tu as dis une "connerie" comme tu dis si bien, hop tu attaque et tu dis que ce sont les autres qui sortent les conneries.
On est plus à la maternelle isnotgood, le "c'est celui qui dis qui est", ca fait un moment que personne ne prend ça au sérieux.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 1.
Automatiser ?
...
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 0.
La recherche des clés faibles peut s'automatiser, y compris a travers plusieurs postes. Ensuite y'a qu'a lire le rapport (enfin le log quoi).
La création de nouvelle clés idem.
La distribution de même (suivant les modèles choisis initialement).
Alors il y a toujours une phase manuelle a faire (script, vérification, cas particulier, ...), mais croire que tu dois générer chaque clé à la mimine n'est pas forcément réaliste.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 1.
Et comment tu automatiques la création de clés que tu as été obligé d'anuler ?
Surtout si les clés ne sont pas à toi....
Tu définis les passphrase puis tu les envois par mail... Automatiquement...
Ça fait peur.
> mais croire que tu dois générer chaque clé à la mimine n'est pas forcément réaliste.
Tu devrais. Les clés c'est précieux. Ça ne doit pas se faire à la chaine.
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 0.
{Tu regarde les clés que tu dois annuler ou pas, et tu pese le pour et le contre de "tout regenerer ou juste celles qui vont pas}.
Surtout si les clés ne sont pas à toi....
{
La c'est pas mal ... moi je génèrerais une clé pas a moi ? C'est quoi l'intérêt là ?
Si je dois la signer je signe la clé publique, pas besoin de générer moi meme la clé , pour du vpn par ex.
Et si je la génère moi même pour qqu'un d'autre, j'ai jamais dis que je la mettrais pas à la mimine si les conditions de sécu ne sont pas satisfaisante pour le faire automatiquement.
}
Tu définis les passphrase puis tu les envois par mail... Automatiquement...
Tu sais que les clés ne sont pas utilisé seulement sur des postes clients ? (par exemple sur des serveurs...)
Tu sais qu'il y a d'autres moyens, chiffré, que le mail, pour envoyer des documents sur des serveurs dont on a la main ?
visiblement non.
comme tu dis "Ça fait peur." ... autant de mauvaise foi.
Tu devrais. Les clés c'est précieux. Ça ne doit pas se faire à la chaine.
mais oui c'est ca ... retourne sur ton poste bureautique.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à 2.
Tu dis que je suis de mauvaise fois...
T'es culotté.
Toi tu dis que pour le "merdier" fait par Debian tu peux tout automatiser.
Foutaise !
http://www.debian.org/security/key-rollover/
http://wiki.debian.org/SSLkeys
Juste un petit passage :
OpenSSH (both server and user keys)
Tu vas regénérer automatiquement les clés des utilisateurs ?
T'es balaise toi. A oui, j'oubliais que tu as fait plein de truc ronflant et blink blink EAL7 optique tunnel et toussa.
Si on te confie la réalisation de la machine infernale, tu nous la garantiras sûr à 100 % ...
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 3.
Mauvaise foi détecté.
J'ai dis que ca pouvait s'automatiser.
J'ai jamais dis que tout pouvait s'automatiser, j'ai meme précisé que certaines phases étaient forcément manuelle.(je me cite
Alors il y a toujours une phase manuelle a faire (script, vérification, cas particulier, ...),)
Tu vas regénérer automatiquement les clés des utilisateurs ?
L'utilisateur est responsable de par chez nous. Tout comme on lui fait pas chier avec un mdp de 12 chiffres, 15 lettre 45 caractères spéciaux qui change tous les 2 semaines.
On l'informe des risques, comment y remédier.
Maintenant si il décide de s'en foutre, on est pas derrière le dos de tout le monde. Idem si il partage son mdp avec un collègue.
On vérifie que chaque personne n'impacte ni les autres, ni le système, ni l'extérieur (dépendant des politiques de sécu dans la boite).
Mais on va pas l'empecher de faire un rm -rf ~ si ca l'amuse, ni un kill -9 -1.
Enfin, même ca ca peut s'automatiser :
tu vérifie les clés (tu es root , tu peux ...
si tu peux pas être root, tu as rien a foutre sur ce poste!).
Si elles sont faibles, hop tu avertis l'utilisateur que sa clé est faible, et que (par exemple , ca peut etre plein de trucs) elle sera effacé d'ici 15 jours si elle n'est pas changé..
Et ca ca s'automatisme très bien.
Si tu administre un serveur apache, tu génère la clé des clients ?
pas moi.
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 1.
[^] # Re: Une réaction sur Debian Planet en français
Posté par pasBill pasGates . Évalué à 5.
Si a chaque fois que tu dois modifier une seule ligne dans openssl, tu dois envoyer un patch (malgré l'accord, quiproquoeste, précédent de la mailing list) avant de continuer ton boulot, l'efficacité, sans vouloir etre vexant, va s'en ressentir.
Une ligne ou dix c'est pas le probleme.
Le probleme c'est le suivant :
a) Le composant est un element critique : la securite de bcp de choses en depend
b) Le composant est largement repandu et utilise
c) La version modifiee va etre installee par enormement de gens
d) La personne faisant la modification ne comprend pas vraiment ce que le code fait
e) Le code modifie n'est clairement pas un truc banal genre interface graphique ou lecture d'un fichier de config, c'est le moteur meme du composant
Partant de la, il est plus qu'evident qu'il faut porter une attention particuliere au changement.
C'est qqe chose qu'on fait ici meme, nos devs de l'equipe de maintenance envoient constamment les patchs pour revue par les devs qui ont pondu le composant, pour la simple raison que ces devs ont beau etre des gens competents, ils n'ont pas forcement une comprehension totale du composant, des differents raisonnements qui ont suivi, etc...
C'est certainement pas une solution a toute epreuve, mais ca reduit enormement les risques, au prix d'un petit ralentissement, et perso je consideres que ca en vaut largement la peine.
[^] # Re: Une réaction sur Debian Planet en français
Posté par briaeros007 . Évalué à 4.
Elle a tellement pas compris qu'elle a demandé à la liste de dvp , et a bien pointé les problèmes qui existaient...
Oui elle a merdé dans sa correction, mais il faut rester un minimum objectif et voir aussi ce qu'elle a fait.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . Évalué à -1.
Quoique...
Si on cratte dans le détail, ça fait peur.
[^] # Re: Une réaction sur Debian Planet en français
Posté par ciol . Évalué à -4.
Alors là tu peux rêver. Ils doivent patcher c'est marquer dans leur FAQ. "C'est écrit, c'est écrit". On changera RIEN. Ils veulent persister à intégrer parfaitement 20000 paquets et les figer pour des années. Ca donne un immense chateau de carte, et si ya le moindre pépin ça s'écroule. En plus, ça fait moins de développeurs pour s'occuper des choses essentielles, quand on considère un jeu à l'égal du kernel.
Tu crois qu'ils vont remettre ça en cause ? Ben non, c'est écrit. J'aurais aimé qu'ils se remettent en question : j'ai préféré changer de distrib au lieu de faire une dépression.
# Tous ces commentaires sont désolants ...
Posté par Michel Rodriguez . Évalué à -3.
1) le zéro défaut, c'est un mythe. Voire : plus c'est gros, plus ça passe. Rappelez-vous un certain Jérome K
2) Vous trouvez Debian nulle ? Utilisez Windows et bouclez-là.
3) Que ceux qui ont déjà remonté un patch (digne de ce nom) à Debian dans ce forum lèvent le doigt les autres, voir le point 2)
4) Pour les plus paranos : quoi ? vous avez installé sur vos serveurs chéris un paquet que vous n'avez pas personnellement testé ? c'est suspect...
Très franchement, c'est fatiguant. Imaginez ce qui trotte dans la tête des DD aujourd'hui : "Je suis une grosse merde...". Bossant à la SG, je suis passé par là, j'imagine ce qu'ils ressentent.
Allez plutôt les soutenir de la manière qui vous paraît la plus appropriée pour vous, ça leur fera du bien.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par Unixfix le Gaulois . Évalué à 0.
2) Debian n'est pas nulle, simplement inadaptée à une utilisation professionnelle. Et en passant il y a d'autres distributions que Debian
3) Non et apès tout j'ai abandonné Debian quand Sarge n'en finissait pas de ne pas sortir....
4) Et oui personne n'est parfait. Mais aprés tout je ne suis pas responsable d'une distribution.
Enfin je plains les sysadmins ayant choisi Debian ou dérivés ils vont se faire remonter les bretelles et avoir un week-end chargé. Avec le beau temps qui s'annonce c'est dommage....
[^] # Re: Tous ces commentaires sont désolants ...
Posté par briaeros007 . Évalué à 2.
C'est LEUR distrib. Ils font ce qu'ils veulent.
C'est pas eux qui se prennent pour la "référence des distributions". Contrairement à d'autres tu as pas en homepage "seulement 2 failles dans l'install par défaut depuis 10 ans".
2) Debian n'est pas nulle, simplement inadaptée à une utilisation professionnelle.
aucune distribution ne l'est ... mais toute le son.
En utilisation professionnelle,
il y a 3 choses qui compte
- le support.
Si tu as une merde, il faut qu'elle soit réparé (tu vois c'est différent de "ne pas avoir de merde", car tout le monde sait que c'est impossible).
- la fiabilité
il faut un minimum d'interruption de service lors de l'utilisation dudit service (dépend de l'os, et du hard).
- la sécurité
(tu sais qu'il y a des serveurs sous du windows...)
Si tu as une SS2I qui te fait un support 24/24 7/7 sur une ubuntu , suis la sécu dessus, elle peut être adapté en env professionnel, .
Ca pose pas de probleme.
Enfin je plains les sysadmins ayant choisi Debian ou dérivés ils vont se faire remonter les bretelles et avoir un week-end chargé.
Et quand windows à un probleme de sécu "Critique" , il se fait remonter les bretelle le sysadmin ?
[^] # Re: Tous ces commentaires sont désolants ...
Posté par fredix . Évalué à 1.
Chez Debian on peut attendre 1 an et plus pour entrer comme DD, mais ensuite on peut faire une faute aussi énorme et y trouver des excuses ?
En somme c'est logique, développement communautaire, responsabilité, heu, communautaire... S'il fallait trouver une faille à cette perfection, la voilà.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par briaeros007 . Évalué à -1.
mais ensuite on peut faire une faute aussi énorme et y trouver des excuses ?
Encore un amateur de "les torts ne sont jamais partagées. Vision binaire de base".
En somme c'est logique, développement communautaire, responsabilité, heu, communautaire... S'il fallait trouver une faille à cette perfection, la voilà.
Ca s'apelle le libre.
Maintenant si tu veux des assurances, trouve et paie un OS EAL7...
[^] # Re: Tous ces commentaires sont désolants ...
Posté par fredix . Évalué à 4.
Je retire, il a bien discuté upstream, donc les torts semblent en effet partagé.
Les DD sont des salariés payé comme JK ?
Justement non. Donc la comparaison avec Jérôme K n'est pas viable, car ce qu'il a fait été intentionnel et en tant que salarié il risquait à juste titre des sanctions.
Ca s'apelle le libre.
Non ca s'appelle une distrib communautaire. Demain je peux coder du libre mais recevoir un avertissement disciplinaire ou un blâme si je suis salarié.
Maintenant si tu veux des assurances, trouve et paie un OS EAL7... Ou simplement une Mandriva ? :)
[^] # Re: Tous ces commentaires sont désolants ...
Posté par fredix . Évalué à 1.
En fait je vois pas pourquoi les dev d'openssl prendraient sur eux la responsabilité qu'à le DD sur une lib aussi critique.... Et dans le doute il peut en discuter avec les packageurs des autres distribs hein, bref.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par Romain Be. . Évalué à 1.
Justement non. Donc la comparaison avec Jérôme K n'est pas viable, car ce qu'il a fait été intentionnel et en tant que salarié il risquait à juste titre des sanctions.
Tiens c'est marrant moi je pensais plutot qu'il avait fait ça pour le bénéfice qu'il, salarié, allait en tirer..
[^] # Re: Tous ces commentaires sont désolants ...
Posté par briaeros007 . Évalué à 1.
C'était pas juste EAL5 mandriva ?
D'ailleur ça en est où cette histoire ?
[^] # Re: Tous ces commentaires sont désolants ...
Posté par Julien . Évalué à 2.
Eheh, non, il me semble au contraire qu'il est aussi difficile de se faire virer de la SG que de debian ;)
Pour la petite histoire, je crois qu'il était spécifié dans le contrat de Jérôme K. qu'un renvoi doit être précédé par un entretient avec sa hiérarchie ... Oui, sauf qu'il a justement l'interdiction légale d'avoir des contacts avec sa hiérarchie ou toute autre personne liée à l'affaire pendant l'enquête.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par dab . Évalué à 2.
Il me semble que tout licenciement doit être précédé d'un entretien avec sa hiérarchie, cela fait partie du code du travail et n'a pas besoin de figurer dans le contrat.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par khivapia . Évalué à 2.
Bon par contre l'entretien n'est obligatoire en cas de faute lourde, qui justifie un licenciement immédiat, sans préavis, et sans indemnités.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par folliked . Évalué à 0.
le problème, ce n'est pas la bourde, mais le fait que vous vantiez tout le temps votre élitisme, clamez partout que votre distribution est la plus "secure" et la plus professionnelle, cette façon arrogante de mener le projet debian fait que vous êtiez incapable de vous remettre en question
La différence avec le J. K. est que vous êtes une communauté, vous n'êtes pas sensé travailler dans votre coin, tout seul. De plus, il est fortement soupçonné que la direction le savait et qu'ils l'ont laissé faire !!!!
On ne mélange pas les torchons et les serviettes !
2) Vous trouvez Debian nulle ? Utilisez Windows et bouclez-là.
quoi? y'a que debian comme GNU/LINUX ? si on veut être un(e) vrai linuxien(ne) faut installer une debian ? mdr , foutage de gueule !!! même Linus lui même n'utilise pas votre distribution en permanence et va voir ailleurs ce qui se passe. Votre distribution n'est pas la distribution "ultime" comme vous le prétendez. C'est une distribution parmi tant d'autres qui a sa propre éthique
Faut que les debianeux se fassent psychanalyser, parce que franchement, j'ai jamais vu ça dans les autres communautés. Autant de mauvaise foi et d'aveuglement, ça tourne à la secte ... D'ailleurs, j'ai remarqué beaucoup de comportement sectaire dans les attitudes des utilisateurs (un manque d'ouverture non négligeable, tournant parfois presque au racisme envers les autres communautés) et les différents blog qu'on l'on puisse lire.
3) Que ceux qui ont déjà remonté un patch (digne de ce nom) à Debian dans ce forum lèvent le doigt les autres, voir le point 2)
parce que il n'y a que les packageurs qui ont le droit de critiquer ? c'est pas un peu immature comme propos et non professionnel ?
4) Pour les plus paranos : quoi ? vous avez installé sur vos serveurs chéris un paquet que vous n'avez pas personnellement testé ? c'est suspect...
aaaaaaaah mais non !!! debian c'est l'élite pourquoi je ne leur ferais pas une confiance aveugle ??? (comportement typique du debianeux qui me saoule en protestant que c'est la meilleure distri du monde entier et que je lui ricane au nez qu'un scandale va bientot arriver, je devrais me faire voyante, appelez moi IRMA)
Vous ferez mieux d'etre plus humble, d'avoir plus d'humilité, plus modeste et discret, on en ferait pas un plat des énormes bourdes qui sont faites ...
... Je ne suis même pas sure que la communauté debian est capable de se remettre grandement en question !!! par contre les entreprises vont réfléchir et remettre en question les choix qu'ils ont porté sur votre distri
Perso, le gars ne doit pas être viré mais rétrogradé car il n'est pas le seul responsable (ce n'est que mon humble avi). Et que les dirigeants revoient leur organisation, sans ça, ça se reproduira un jour ou l'autre ... (puis faut revoir tous les autres packages parce que toute façon, hein, faut pas se leurrer, il doit y avoir d'autres conneries comme ça ailleurs)
[^] # Re: Tous ces commentaires sont désolants ...
Posté par Geoffrey Gouez (site web personnel) . Évalué à -1.
Pour avoir utiliser debian pendant longtemps, je lui reproche surtout son manque d'ouverture vers le monde "professionnel".
Bien que ce soit la philosophie d'interdire tout contenu copyrighter, j'estime que virer firefox des paquets officiels a cause d'un logo temoigne de la perversion de la philosophie.
Personnellement, j'ai quitté debian pour fedora : la communauté est plus ouverte et surtout plus professionnelle, dû à la proximité du monde RedHat.
Pour ce qui est du bug d'OpenSSL : tout le monde fait des erreurs. Celle-ci se solde par une baisse de la securité des réseaux, un patch, et c'est resolu. Il y a des choses plus graves dans la vie. Il s'agit d'une simple erreur d'inattention...
Le genre d'erreur qui peut tuer des gens sur la route, certes, mais qu'il faut affronter avec philosophie.
Au lieu de s'affronter, les communautés devraient s'entraider.
Dire "Debian, ça rox", ok, mais pourquoi ?
Dire "Mandriva, ça dechire sa race !", ok, mais pourquoi ?
[^] # Re: Tous ces commentaires sont désolants ...
Posté par patrick_g (site web personnel) . Évalué à 4.
Combien de fois faudra-il répéter que le problème ne se pose pas tant au sujet du logo qu'au sujet de la liberté de patcher Firefox librement (ce que Debian veut faire) et de garder ensuite le logo.
Ce n'est pas du tout la même chose.
[^] # Re: Tous ces commentaires sont désolants ...
Posté par folliked . Évalué à 1.
D'autres logiciels subissent les mêmes choses (modif du logo tout ça tout ça pour un repackaging du logiciel), et pourtant on n'en fait pas un patacaisse. C'est le jeu du libre. Justement, c'est parce que les raisons ne sont pas aussi controversées que pour debian avec firefox.
# Difficulté de créer un bon générateur de nombres aléatoires (ou pas
Posté par Victor STINNER (site web personnel) . Évalué à 2.
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.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par fredix . Évalué à 3.
Mais il s'agit pas ici d'un développeur mais du mainteneur d'un paquet qui vire du code du développeur .. Ca n'a *rien* à voir. Et même si le mainteneur se prend pour un Dieu du code, la moindre des choses est de demander ET obtenir l'aval upstream avant de commenter/supprimer du code.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par briaeros007 . Évalué à 2.
En tout cas c'est un peu ce que donne comme idée ton message.
la moindre des choses est de demander ET obtenir l'aval upstream avant de commenter/supprimer du code.
Ce qu'il a fait, et obtenue (quiproquo pe ?)
Mais bon, faut mieux calomnier que se renseigner, hein ...
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par fredix . Évalué à 3.
Quant à le traiter de sous merde c'est pas du tout le message de mon post. Pour la calomnie c'est juste un commentaire dans un forum hein :)
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par IsNotGood . Évalué à 3.
Si c'est simple.
On lui a dit de virer les lignes qu'il pointait *que* pour Valgrind, pour débugguer. Ce qu'il a fait pour un MD_Update() (avec "#ifndef PURIFY"). Mais il en a virée aussi pour la version en production. Pour la version de production il n'a pas utilisé "#ifndef PURIFY", il a simplement mis la ligne en commentaire...
La mise en commentaire de cette ligne n'a pas été proposé sur la mailing openssl-dev et c'est elle qui pose problème.
Il n'a pas eu de patch proposé.
Il a dit "voila, j'ai ça, vous en passé en quoi ?". Puis a un appliqué autre chose que ce qu'il a montré sur openssl-dev (il n'a pas montré qu'il allait inconditionnellement virer un MD_Update).
Suffit de comparer le mail qu'il a envoyé à openssl-dev et le svn.
> Quant à le traiter de sous merde
Non, il ne faut pas le traité de sous merde.
Mais il a merdé et il faudrait arrêter de dire qu'il n'a pas merdé.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par IsNotGood . Évalué à 3.
Index: debian/changelog
===================================================================
--- debian/changelog (révision 140)
+++ debian/changelog (révision 141)
@@ -23,6 +23,9 @@
- Make use of invoke-rc.d
* Add comment to README.Debian that rc5, mdc2 and idea have been
disabled (since 0.9.6b-3) (Closes: #362754)
+ * Don't add uninitialised data to the random number generator. This stop
+ valgrind from giving error messages in unrelated code.
+ (Closes: #363516)
-- Kurt Roeckx <kurt@roeckx.be> Thu, 6 Apr 2006 20:34:07 +0200
Index: rand/md_rand.c
===================================================================
--- rand/md_rand.c (révision 140)
+++ rand/md_rand.c (révision 141)
@@ -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,7 +468,10 @@
MD_Update(&m,local_md,MD_DIGEST_LENGTH);
MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
#ifndef PURIFY
+/*
+ * Don't add uninitialised data.
MD_Update(&m,buf,j); /* purify complains */
+*/
#endif
k=(st_idx+MD_DIGEST_LENGTH/2)-st_num;
if (k > 0)
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par IsNotGood . Évalué à 2.
Index: md_rand.c===================================================================
--- md_rand.c (.../rand/md_rand.c) (révision 164)
+++ md_rand.c (.../crypto/rand/md_rand.c) (révision 173)
@@ -468,11 +468,10 @@
MD_Update(&m,local_md,MD_DIGEST_LENGTH);
MD_Update(&m,(unsigned char *)&(md_c[0]),sizeof(md_c));
#ifndef PURIFY
-/*
- * Don't add uninitialised data.
+#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)
{
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par Romain Be. . Évalué à -1.
A noter que les versions pristines upstream compilées avec -DPURIFY sont *aussi* vulnérables.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par IsNotGood . Évalué à 1.
Oui mais on s'en fout car ce ne sont pas des versions de productions diffusées à des millions d'exemplaires.
Pitier, me dit pas que le mainteneur est capable de compiler par défaut avec -DPURIFY ?
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par Anonyme . Évalué à 3.
Le problème n'est pas d'avoir retiré cet appel de fonction avec une variable non initialisée (ce que permet de retirer -DPURIFY), ca ce n'est pas genant. Le problème c'est d'avoir retiré une autre ligne similaire dans une autre fonction, qui elle était très importante (et qui n'est pas supprimé par -DPURIFY).
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par fredix . Évalué à 2.
Mais il a merdé et il faudrait arrêter de dire qu'il n'a pas merdé.
Bah c'est bien ce que je dis. Et bon faut pas déconner quand on est DD sur une lib aussi critique il y a un minimum de responsabilités à assumer, et là elles sont grandes, bénévole ou pas elles sont là ...
Si demain c'est le DD de gnupg qui merde, on dira : "bou, personne n'est à l'abri d'un bug, blabla" ?
du coup je dl fedora pour voir :P /o\
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par Romain Be. . Évalué à 3.
Salut !
Bah c'est bien ce que je dis. Et bon faut pas déconner quand on est DD sur une lib aussi critique il y a un minimum de responsabilités à assumer, et là elles sont grandes, bénévole ou pas elles sont là ...
Bah, tu sais chez ubuntu, ya tout un tas de truc qu'ils releasent aussi sans rien tester du tout, il comptent sur debian. Sauf qu'ils font une release tous les 6 mois. Et des backports. Plein dans tous les sens...
Du coup je donnerai pas cher d'un audit d'ubuntu sur pas mal de paquets, à commencer par toutes les webapps pour ce qui est de la version serveur.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par GeneralZod . Évalué à 2.
C'est ce qui est arrivé avec le problème concernant le laptop-mode-tools dans Ubuntu, ils ont récupéré le paquet Debian sans vraiment regarder ce qu'il y avait dedans.
Mais comme tu dis, le problème est connu depuis longtemps mais aucune action concrète n'a été prise pour améliorer ce point.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par fredix . Évalué à 2.
Je sais bien que Ubuntu s'appuie sur Debian, c'est bien pour ca que je vais tester Fedora ;)
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par fredix . Évalué à 0.
[^] # Re: Difficulté de créer un bon générateur de nombres aléatoires (ou
Posté par briaeros007 . Évalué à 1.
On en a déja discuté mainte fois, et je vois que même en contre-argumentant ce que tu dis de façon raisonné, comme ca vient pas de fedora, tu reste sur une position "c'est qu'un gros naze" (pour la faire courte).
Je ne me fatiguerais pas à continuer ce dialogue de sourd, et j'inviterais donc les lecteurs souhaitant avoir une vision peut etre un peu moins "simpliste" du probleme de regarder les commentaires et liens des autres journaux. (comme par exemple ce lien :
http://blog.drinsama.de/erich/en/linux/2008051401-debian-ope(...)
)
Mais il a merdé et il faudrait arrêter de dire qu'il n'a pas merdé.
Ou j'ai dis qu'il avait pas merdé ?
j'avais dis danstte dépeche les dvp de debian ont tort dans une certaine mesure
Je reconnais bien qu'ils ont merdé, non ? (le certaine mesure est la uniquement pour contrebalance le "ils sont responsable de toute la misère du monde")
(et c'est loin d'être la seule foi que je le dis, entre autre sur les journaux traitant du sujet).
Ah mais faut mieux raconter n'importe quoi plutot que de faire un ctrl+f , hein isnotgood
# Discussion avec upstream sur la suppression des lignes incriminées
Posté par François B. . Évalué à 1.
http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
Le message a été posté sur openssl-dev, et contient à la fin, après avoir exposé ses découvertes avec Valgrind et les deux lignes incriminées (l'emphase est de moi) :
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy. But on the other hand, I'm not even
sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?
Donc, contrairement à ce que je peux entendre un peu partout, le développeur savait qu'il y avait un impact sur l'entropie du générateur. Mais bon, je vous laisse parcourir le fil de discussion, il n'y a eu que trois réponses qui sont également en faveur de la suppression (mise en commentaire ou compilation conditionnelle) des deux lignes.
[^] # Re: Discussion avec upstream sur la suppression des lignes incriminées
Posté par herodiade . Évalué à 6.
1- Comme l'indique Ben Laurie, cette liste est de fait surtout utilisée par les développeurs d'applications basées sur openssl, et pas vraiment par les gens qui développent openssl. Ce qui change la façon d'interpréter les mails qui y sont soumis (cf. ci-dessous).
2- Kurt commence son email par "When debbuging applications that make use of openssl using valgrind [...]", et les devs ont clairement pensé qu'il voulait simplement une astuce / un hack lui permettant débugguer/valgrind localement une application utilisant openssl (cf. la réponse du dev openssl : "If it helps with debugging, I'm in favor of removing them."). L'intention de Kurt (patcher un openssl utilisée en prod, et distribué massivement cette version) n'était absolument pas discernable.
3- Son email à la forme d'une simple question, et n'envoie pas son code sous forme de patch proposé pour intégration dans openssl. S'il avait envoyé un patch pour intégration upstream, les développeurs l'aurait lu attentivement et refusé (comme ils l'ont fait à chaque fois qu'un patch pour "corriger MD_Update pour valgrind" leur est présenté, ce qui était déjà arrivé avant le mail de Kurt, y compris dans le bugtracker d'openssl, et ce dernier aurait du googler), ce qui lui aurait permis de comprendre que c'est une mauvaise idée.
4- Il ne s'est pas présenté comme "mainteneur du paquet Debian", et il a encore moins annoncé son intention de balancer cette modif pour tout les utilisateurs d'openssl chez Debian et Ubuntu (on en revient au point 2).
Bref, "remonter ses modifications upstream", c'est ouvrir une entrée dans le bugtracker et y attacher sa modification sous forme de patch, et annoncer son statut et son intention de distribuer le patch.
[^] # Re: Discussion avec upstream sur la suppression des lignes incriminées
Posté par briaeros007 . Évalué à 2.
Sauf que c'est faux.
1°) le site d'openssl indique que openssl-dev est pour la librairie et pas les applis
2°) la majorité des messages concernent des messages propre à la librairie.
Ah ben oui c'est dur de vérifier les sources, faut savoir lire une mailing list
3°) ben laurie indique comme mailing list openssl-team. Petit hic, cette mailing list n'est pas indiqué sur le site. Et un google me sors que 63 réponse, face à plus de 12000 pour openssl-dev.
4°) Ben laurie invoque l'excuse qu'il avait pas vu ce qu'avait dit le dvp parce qu'il "n'a pas suffisament de bande passante". Sauf qu'il y a des interfaces web pour effectuer des recherches directement. interface web qui sont moins lourde que son blog. Pourtant il arrive a recharger son blog et à répondre dessus.
L'intention de Kurt (patcher un openssl utilisée en prod, et distribué massivement cette version) n'était absolument pas discernable.
Il était question de debugger openssl, et d'aider au debug des AUTRES applications (cf un mail ou quelqu'un indique le nombre d'erreur qu'il a en utilisant openssl vanilla (et a cause de lui) pour debugger une autre appli. (ca reste bien un probleme propre à openssl, vu que les erreurs sont provoqué par lui).
Quand tu debug une application, tu vas pas t'amuser a prendre la version de debug de libc6...
Sur les autres points je suis d'accord.
[^] # Re: Discussion avec upstream sur la suppression des lignes incriminées
Posté par herodiade . Évalué à 3.
Oui, je l'avais indiqué dans un post précédent mais j'aurais du le rappeller dans celui-ci aussi. Cest aussi ce qui est écrit dans le README des sources de la lib :
« If you would like to submit a patch, send it to openssl-dev@openssl.org with the string "[PATCH]" in the subject. Please be sure to include a textual explanation of what your patch does. »
La remarque de Damien Miller semble la plus pertinente : selon lui, la meilleur façon de s'adresse à upstream en étant lu (et qu'upstream sache qu'on s'adresse à lui, pas qu'on cherche du support end-user), ça reste le patch (diff -u) dans le bugtracker. Ce qui, dans le cas présent, aurait peut-être même permis au développeur Debian d'y trouver la précédente discussion sur le sujet.
# Premiers cas de collisions de clés...
Posté par snt . Évalué à 4.
-> Traduction à l'arrache : Nous avons identifiés plusieurs cas où différents utilisateurs ( ne se connaissant pas ) ont généré les memes clés publiques. Nous les avons informés et révoqué les clés. Les clés incriminées ont été générées avec Ubuntu.
http://github.com/blog/63-ssh-keys-generated-on-debian-ubunt(...)
# Dilbert
Posté par IsNotGood . Évalué à 2.
http://dilbert.com/strips/comic/2001-10-25/
# Feature ! blink blink !!
Posté par IsNotGood . Évalué à 7.
http://blog.drinsama.de/erich/en/linux/2008051401-consequenc(...)
In fact, if your server is running Debian and you installed the Debian security update for openssh, it will be much more secure than the RedHat server. Because the Debian server has a blacklist of keys that are too common. The other-Linux server who doesn't have this blacklist doesn't know that a certain 'weak' key is not trustworthy.
Mais qu'elles sont nulles les autres distributions.
[^] # Re: Feature ! blink blink !!
Posté par dyno partouzeur de drouate . Évalué à 5.
Je vais créer une distribution qui blackliste toutes les clefs DSA, ce sera la plus sûre au monde !
LOL, comme dirait ploum.
[^] # Re: Feature ! blink blink !!
Posté par nullisimo . Évalué à 3.
[^] # Re: Feature ! blink blink !!
Posté par Thomas (site web personnel) . Évalué à -1.
Alors pretendre que les autres distribs qui n'ont pas cette feature ne sont pas secure ...
[^] # Re: Feature ! blink blink !!
Posté par IsNotGood . Évalué à 4.
MS va te dire qu'un anti-virus est une feature. La vrai feature est d'avoir un OS qui n'a pas besoin d'anti-virus.
Une connerie (un OS virus friendly) créé une "feature" => les anti-virus.
C'est pareil pour la connerie de Debian.
[^] # Re: Feature ! blink blink !!
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Cette "fonctionnalité" a t'elle un intérêt hormis tenter de limiter la prolifération de clé faible Debian ?
[^] # Re: Feature ! blink blink !!
Posté par IsNotGood . Évalué à 2.
Aucune idée.
Je trouve ça con d'intégrer cette "fonctionnalité" et en même ça a un côté necéssaire.
Aucune idée.
> Cette "fonctionnalité" a t'elle un intérêt hormis tenter de limiter la prolifération de clé faible Debian ?
La prolifération des clés faibles Debian/etc est un problème de sécurité. Donc ça doit être upstream. Mais c'est con de mettre cette fonctionnalité en upstream.
Aucune idée (je l'ai déjà dit je crois :-)).
[^] # Re: Feature ! blink blink !!
Posté par imalip . Évalué à 3.
# 1 minute (pas plus) de compassion
Posté par oops (site web personnel) . Évalué à 8.
# Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'est
Posté par herodiade . Évalué à 10.
un '#ifdef PURIFY' est totalement facultatif. Donc :
1) contrairement à ce qui a été écrit plus haut par iZnogood, un openssl
standard compilé avec -DPURIFY ne pause aucun problème . Et
2) on peut aisément comprendre qu'une lecture rapide/superficielle du code
ou du patch conduise à croire que le premier appel à MD_Update(), dans le
même fichier, puisse être traité de la même manière (ce qui n'est en fait pas le cas).
* Kurt (le développeur Debian à l'origine du patch problématique) a soumis son
patch pour revue sur la liste de diffusion openssl-dev[1], ce qui n'a pas
suscité de mise en gardes (mais l'upstream n'a pas choisi d'intégrer ce
patch, et pour cause). Cette façon d'échanger avec l'upstream présentait
cependant plusieurs graves défauts, comme le signale d'ailleurs Damien Miller
(le développeur principal d'OpenSSH)[1] :
1) openssl-dev est en pratique une liste d'utilisateur d'openssl (ou de
développeurs d'applications utilisant openssl), et pas la liste des
développeurs de la lib openssl (openssl-team), et encore moins le bugtracker.
Seulement la description de la liste sur le site d'openssl ne reflète pas ce
fait.
2) Il n'a pas du tout précisé qu'il était mainteneur du paquet debian et
qu'il comptait y intégrer ce patch et le distribuer à tout les utilisateurs.
Vu que son mail parle seulement de problème avec valgrind (utilisation de la
lib en condition de debug), et sur une m-l pour les devs de programmes
utilisateurs, son messsage a vraissemblablement été interprété comme
"salut, je n'arrive pas à valgrinder mon appli sur mon poste perso parce
qu'elle utilise openssl, est-ce que ce quick hack peut me tirer d'affaire ?"
3) Ce qu'il a envoyé sur la mailing-list n'est pas un patch, mais une
question (ce qui n'aidait pas à deviner ses réelles intentions).
4) S'il s'était donné la peine de googler "valgrind openssl", ou simplement
de chercher dans le bugtracker d'openssl, il aurait vu, des tonnes de fois,
la réponse des devs à ce problème[3].
* Certains (cf. par ex. Sytoka Modon plus haut) semblent avoir mal compris
pourquoi cette fonction peut utiliser de la mémoire non initialisée. Si
openssl fait brailler valgrind, ce n'est pas que leur code est sale. Et non,
openssl ne compte pas sur cette zone de mémoire pour vraiment contenir un
aléas solide et suffisant. La fonction :
"static void ssleay_rand_add(const void *buf, int num, double add)" ,
celle dont les appels à "MD_Update(&m,buf,j);" ont été commentés par Debian,
est une fonction interne d'openssl appellée par la fonction "publique"
(documentée et exposée aux utilisateurs de la lib) :
"int RAND_bytes(unsigned char *buf, int num);".
La page de man de RAND_bytes(3ssl) explique clairement :
"The contents of buf is mixed into the entropy pool before retrieving the
new pseudo-random bytes unless disabled at compile time (see FAQ)."
Bref, c'est un comportement parfaitement documenté, le buffer "buf" (transmis
depuis l'application utilisatrice jusqu'à MD_Update()) sera accédé en
lecture, et pas seulement en écriture.
Si l'utilisateur le souhaite, il peut "pré-remplir" le buffer "buf" avec des
données venant de /dev/random, ou autre, avant d'appeler RAND_bytes(), et ainsi
augmenter à souhait l'entropie du système tout en faisant taire valgrind. Le cas
échéant, openssl lit quand même la zone mémoire "buf" (parce que MD_Update()
ne sait pas si elle a été initialisée de la sorte, et parce que même si elle
ne l'a pas été, elle peut contenir n'importe quoi, ce qui est toujours un
petit poil d'aléas bon à prendre même si non vital). Ensuite, le MD_Update()
mixe le contenu de "buf" avec du vrai aléas obtenu de façon dépendante de la
plateforme (/dev/urandom /dev/arc4random, etc.) : on ne dépend pas du fait
que le contenu, initialisé ou pas, dans "buf" soit réellement aléatoire ou pas.
Mais on dépend du fait que l'appel à MD_Update() soit bien éffectué, sinon
ce mélange de buf et de vrai aléas n'a pas lieu. Ceci explique pourquoi une
solution telle que : "memset(buf, 0, sizeof buf); MD_Update(&m,buf,j);",
qui aurait fait taire valgrind, aurait plutôt diminué la qualité du code
et de l'entropie. Le probleme ici est que le développeur Debian a purement
et simplement enlevé l'appel à MD_Update().
* Debian et Ubuntu distribuent désormais une versions d'openssh patchée pour
rejeter les clefs fragiles, et contenant un nouvel outil (ssh-vulnkeys)
censé aider à trouver les clefs fragiles sur le système. Il sera
malheureusement nécéssaire que les autres distribs (et les *BSD, et Solaris,
etc.) fassent de même *très rapidement*. Et il serait de bon ton de la part de
ces deux distributions responsables d'y aider, et aussi de distribuer l'openssh
patché pour Sarge et Ubuntu 6.06 LTS (arrétons l'hypocrisie et les résolutions
psychorigides : même si ces deux distribs ne sont plus officiellement supportées
depuis peu (un ou deux mois), elles sont encore utilisées).
* Complètement ahurissant et irresponsable : le correctif sécurité Debian a été
commité, publiquement 5 jours avant la publication de l'advisory ![4]
Pourtant, même la doc officielle pour les développeurs Debian rappelle
l'évidence, qu'il ne faut pas faire ça.[5]
### Aussi, pour éviter que ça se reproduise, on peux facilement en déduire que :
* Les mainteneurs de paquets dans les distributions devraient toujours
soumettre leurs patchs à l'upstream, *en n'omettant pas d'indiquer qu'ils
sont maiteneurs du paquet et ce qu'ils comptent faire du patch* (qu'ils
comptent l'intégrer dans le paquet, qu'il ne s'agit pas d'un simple
quick hack sur leur poste perso pour pouvoir mieux débugguer une appli
en cours de développment avec valgrind).
* Comme le rappelle Ben Laurie[6] (dev openssl), un mainteneur de paquet ne
devrait jamais distribuer sa correction d'un problème qu'il ne comprends pas
(une résolution "à tatons") ou dans un segment de code qu'il ne comprends
pas. Surtout si ce patch touche une composant central d'une bibliothèque
vitale pour la sécurité de l'OS et très utilisée.
* Les outils automatiques de fiabilisation (de valgrind à SELinux en passant
par snort ou gcc -fstack-protector) ne peuvent rien pour prévenir ce type de
bourdes ou leurs conséquences. Autrement dit, retenons qu'ils ne remplaceront
jamais la nécessité d'une relecture et validation humaine systématique du code
par un pair "expert". Le bon vieux modèle "audit et relecture systématique par
un ancien" à la façon OpenBSD a du bon (ce qui ne signifie pas que le modèle
"prévention automatisée à la SELinux/Red Hat est moins bon, mais le premier
reste nécessaire). Debian devrait imposer la validation des patchs, au moins
sur les composants critiques.
* Le problème aurait aussi été évité si le développeur Debian avait regardé le
bugtracker d'openssl (où il a déjà été question de son problème) - et je
considère que regarder ce bugtracker est son boulot ; il aurait aussi été
évité si les développeurs openssl suivaient les "vendor patchs" dans les
distros, ou simplement les bugtrackrs des distros. Il y a de grosses marges
de progrès là (et des "meta" bugtrackers pourraient aider).
* Documenter les pièges de ce genre dans la code (un simple commentaire...) ne
mange pas de pain. Même si c'est documenté dans la page de man, le
bugtracker et sur la mailing-list (via goole).
[1] Post de Kurt sur openssl-dev : http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
[2] Remarque de Damien Miller : http://marc.info/?l=openbsd-misc&m=121088162320794&w(...)
[3] Par exemple ici, en 2003 http://rt.openssl.org/Ticket/Display.html?id=521&user=gu(...)
[4] http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/cryp(...)
[5] http://www.debian.org/doc/developers-reference/ch-pkgs.en.ht(...)
[6] Ben Laurie : http://www.links.org/?p=327
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par IsNotGood . Évalué à 2.
Je l'ai dit qu'une fois. Mais t'as raison.
M'enfin, c'est limite un coup de chance.
En tout cas, un développeur ne doit pas penser que c'est pour une version de production. Faire cette erreur est grave. C'est valable pour DEBUG, etc sauf s'il est clairement indiqué dans la doc que c'est supporté.
> Kurt (le développeur Debian à l'origine du patch problématique) a soumis son
patch pour revue sur la liste de diffusion openssl-dev[1]
Non.
Il a soumis ça :
247:
MD_Update(&m,buf,j);
467:
#ifndef PURIFY
MD_Update(&m,buf,j); /* purify complains */
#endif
Ce n'est pas son patch.
Ceci dit, ton commentaire est excellent.
Il aurait dû être la dépêche :-)
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Julien . Évalué à 3.
> M'enfin, c'est limite un coup de chance.
Je crois que ces deux lignes suffisent à appréhender la suffisance du personnage.
Surtout après avoir passé une page de commentaires à détruire le mainteneur debian, parce qu'il a fait une erreur et c'est impardonnable et ça arriverait pas chez ...
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par IsNotGood . Évalué à 3.
T'es aussi d'une belle suffisance, j'ai écris plein de fois que ça peut arriver à n'importe qui.
M'enfin, continue ta lecture sélective.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par IsNotGood . Évalué à 3.
L'avis d'un membre du directoire de Fedora (chercher spaleta) :
http://www.informationweek.com/blog/main/archives/2008/05/ha(...)
As a Fedora Board member, I want to take a moment to make sure you understand something critical.
The openssl issue could have happened to us. I'm not going to take false praise for our project dodging this bullet.
Je pense la même chose.
Mais comme c'est un type de chez Fedora, tu vas penser qu'il est d'une suffisance insupportable.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Julien . Évalué à 1.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par IsNotGood . Évalué à 2.
Pour te prévenir. Comme on pense souvent la même chose, tu vas le trouver imbu de sa personne.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par IsNotGood . Évalué à 3.
commité, publiquement 5 jours avant la publication de l'advisory !
Heureusement que c'est passsé inaperçu, l'exploit a été publié le lendemain de l'advisory (à 2 heure du mat).
Sinon je vous raconte pas la catastrophe entre des mains mal intentionnées.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par brunus (site web personnel) . Évalué à 3.
La Ubuntu Dapper Drake, aka LTS 6.06 sera supportée jusqu'en 2009 pour la version desktop et 2011 pour la version serveur. J'ai moi même fais des mises à jour de ma version serveur cette semaine.
Voici le changelog du paquet openssh de Dapper Drake :
http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/(...)
Et le changelog du paquet openssl de Dapper Drake :
http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/(...)
Quels paquets devraient être patchés et pourquoi ?
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par herodiade . Évalué à 3.
Au temps pour moi. Cela dit, aux vues du changelog que tu présente :
> Quels paquets devraient être patchés et pourquoi ?
Le paquet openssh-server (et l'ajout d'une dépendance sur le nouveau paquet openssh-blacklist). Pour que ce serveur refuse l'authentification avec une clef connue comme compromise, comme le font désormais les OpenSSH de Etch et celui de Hardy. Et accessoirement, pour disposer de l'outil ssh-vulnkeys (mais c'est moins urgent).
Encore une fois : ce n'est pas parce qu'une machine utilise une distribution qui n'est pas une dérivée Debian, ou n'a pas inclus la version saccagée d'openssl, que cette machine est à l'abri. Il suffit qu'un utilisateur de la machine y ai placé une clef ssh vérolée (générée sur une Gutsy, par exemple) pour que la machine soit compromise.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par brunus (site web personnel) . Évalué à 2.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Yannick . Évalué à 4.
En fait, si j'ai bien compris, c'est l'inverse.
Si une paire de clefs DSA a été générée sur une machine saine mais que la clef privée a été utilisée sur une machine avec l'openssl impacté, alors cette clef et vulnérable.
En effet, l'algorithme de DSA utilise des nombres aléatoires pour la signature et avec plusieurs messages signés avec l'openssl impacté il y a un risque de pouvoir retrouver la clef privé.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
> compris pourquoi cette fonction peut utiliser de la mémoire non
> initialisée.
Désolé mais je n'ai pas du tout dis cela. J'ai dis que je n'y connaissais rien au fonctionnement interne. Moi ce qui me surprends en lisant les commentaires, c'est que ca a l'air vachement compliqué d'utilisé la bibliothèque OpenSSL puiqu'on retrouve cet appel a MD_Update() plusieurs fois dans le code. Si on veut du code sur, j'ai l'impression que le mieux est d'avoir une API simple ?
Comme tout le monde va de sa proposition et tu en fait des bonnes, j'y suis allé de la mienne sur un thème peu évoqué ici du contrôle par cas test /a posteriori/.
Le contrôle par cas test est à la charge du concepteur de l'application et permet de s'assurer, en plus des autres contrôles, une certaine stabilité de l'application, et cela de manière relativement automatique.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par herodiade . Évalué à 4.
« Les dev d'openssl ont un poil la responsabilité vu la superbe documentation
du code incriminé, et le fait que valgrind gueule bien. »
Toutes mes exkiouzes.
# Mesures qui seront prises ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 3.
On peut très souvent lire des commentaires du genre, l'erreur est humaine (ce qui est vrai) leurs réponses ainsi que des explications permettant de détecter les mauvaises clés.
Moi, en tant qu'utilisateur Debian, ce qui m'intéresse c'est de savoir ce que Debian compte faire pour éviter que cela se reproduise. Je pense que vu le seuil critique qu'a atteint cette erreur, la confiance (en tout cas pour moi) envers Debian se trouve au moins en partie ébranlée (dans le genre, on pourrait se dire que si cela arrive avec OpenSSL, pourquoi pas avec GnuPG ou le kernel).
Donc ce que moi j'aimerai savoir (et c'est pour ça que je poste, si quelqu'un a une réponse) c'est ce que Debian compte faire, des restructurations par exemple. On pourrait imaginer crée un tag pour les paquets critiques du système et que les patchs de ces paquets doivent obligatoirement être relu par une autre team (Quality Assurance ?) avant d'être inclut dans la prochaine version stable. Je me doute que cela peut représenter beaucoup de travail et je ne sais pas si c'est réalisable, c'est juste une idée.
J'ai regardé les tags pour OpenSSL, il y a security:cryptography (entre autre), mais ça ne le différencie pas d'un paquet comme kgpg qui est aussi taggé security:cryptography donc il faudrait autre chose.
Enfin bref, moi ce qui m'intéresse le plus c'est de savoir ce que Debian compte faire pour minimiser le risque que cela se reproduise.
Si quelqu'un a des informations là-dessus, ce serait bien d'en parler.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à 1.
Ils n'ont pas assez de développeurs pour faire ce que tu demandes. Et ils ne peuvent pas attirer assez de nouveaux développeurs non plus, puisque leur cible principale sont les administrateurs de parc informatique, très peu enclin à utiliser -unstable.
Ce qu'il faudrait, c'est revoir le modèle de développement, mais dès que quelqu'un fait des propositions dans ce sens sur les ML, ça ne rate jamais : un administrateur de parc informatique réplique "ah mais moi Debian je la trouve très bien comme ça, c'est stable, pas cher, ça se met à jour facilement surtout ne changez rien", ce qui conforte les devs Debian dans l'idée qu'il ne faut rien changer.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 4.
Mouaif.
Disons que c'est le discours officiel aujourd'hui.
L'affaire est trop chaude pour réfléchir à des évolutions. On attend que la poussière retombe.
Je ne crois pas que Debian restera sans rien faire. Ce problème d'OpenSSL est hypra grave car il impacte toutes les distributions (pas seulement les dérivées de Debian). Tout le monde va maintenant vérifier s'il y a pas des clés "made in Debian/etc" dans sa bécane.
Il y a un problème de confiance entre Debian et les autres qui va se poser. J'ai beaucoup de mal à croire que Debian ne va rien faire. Si Debian ne faire rien, c'est très très grave.
[^] # Re: Mesures qui seront prises ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
Personnellement si je ne vois pas une prise de position satisfaisante je songe sérieusement à utiliser Fedora pour mes desktop et Red Hat sur serveur et je pense que je ne doit pas être le seul à envisager cela.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -5.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -4.
Heu ça je ne pense pas, pas de sitôt. Debian est imbattable si on veut quelque chose d'administrable facilement et gratuitement.
Et puis même, la QA de Debian est déjà je pense la meilleure que l'on puisse trouver. Red Hat ne fait pas mieux : elle a moins de testeurs, et elle est soumise à des contraintes d'entreprises parfois incompatibles avec la QA.
Ce que je reproche à Debian (qui encore une fois est la meilleure en terme d'assurance qualité), c'est de ne pas être encore meilleure.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 3.
Il y en aura. Évidemment pas 30 % des utilisateurs Debian actuels.
Mais ceux qui hésitaient, ne vont plus hésiter.
> Et puis même, la QA de Debian est déjà je pense la meilleure que l'on puisse trouver.
QA pour Quality Assurance ?
Tu plaisantes ?
Oui tu plaisantes.
[^] # Re: Mesures qui seront prises ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
A ma connaissance, Red Hat est d'abord la distribution la plus utilisée et ensuite elle n'as pas de telle bourde à son actif.
Pour Debian, elle a des avantages c'est clair, mais il y a ce *gros* problème, et aussi celui-ci[0] pour rappel. Alors moi j'attend de voire ce qu'ils comptent changer et je ne crois pas qu'un administrateur système professionnel qui soit un peu censé soit insensible à ce genre de problème (sauf si ça le dérange pas de travailler la nuit/le week-end personnellement c'est pas mon cas).
[0]http://linuxfr.org/2005/06/29/19218.html
[^] # Re: Mesures qui seront prises ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
1) soit quitter Debian et s'illusionner sur la QA de RH (parce que forcément quand on a moins de testeurs on voit moins de bogues)
2) soit arrêter de faire sa sangsue.
[^] # Re: Mesures qui seront prises ?
Posté par ohnoes . Évalué à 2.
RHEL
Administrable facilement : pas besoin de changer d'OS pendant 7 ans si la machine ne sert qu'à faire tourner une appli précise.
(Et après y'en a pour dire que le bénévolat n'est pas sans ses limites. Ben tiens. Red Hat arrive à maintenir un grand nombre de distributions simultanément, RHEL 2.1, 3, 4 et 5.
RHEL2.1 est sortie la même année que la Debian Woody et arrivera pourtant en fin de maintenance en.. 2009.
A coté de ça, ils paient des développeurs pour maintenir deux Fedora et la branche de développement Rawhide. )
http://www.redhat.com/security/updates/errata/
Gratuité : on peut retrouver des rebuilds de RHEL comme CentOS gratuitement, qui fournissent exactement la même chose à partir des sources RHEL.
Quant au QA soyons réalistes deux secondes, Red Hat embauche trois tonnes de développeurs upstream, que ça soit sur gcc, glibc, kernel, samba, gnome.. jusqu'à un des quatre membres de la core team OpenSSL. Ce même bonhomme écrit des articles sur la sécurité chez Red Hat :
http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -3.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Si c'est pour faire tourner Oracle, ta RHEL2.1 conviendra très bien mais dans d'autres registres, on ne peut malheureusement pas tenir 7 ans sans mettre à jour certains composants du système. Même dans le logiciel propriétaire, on maintient un système mais on ne le garde pas en l'état aussi longtemps : il évolue nécessairement, ne serait-ce que pour appliquer des suites de correctifs.
Alors oui, RedHat maintient encore RHEL2.1 mais sans doute parce qu'il a encore des clients qui en font la demande, de la même manière que Microsoft a longtemps maintenu NT4 et va maintenir encore XP.
En fait, on n'utilise pas encore RHEL2.1 : on utilise toujours Oracle*. Il y a là une grande nuance : peu importe au final quel système fait tourner l'application unique tant qu'elle tourne.
Ensuite, l'administration est aisée tant que les RHEL sont enregistrées auprès du RHN. Depuis que les RHEL sont passées à yum, on peut sans doute passer par un dépôt tiers plus facilement (sans enregistrement) mais j'ai souvent vu des RHEL qui n'étaient pas enregistrées et crois-le ou non, pour administrer ça, c'est la croix et la bannière.
Et pourquoi pas des CentOS ? Parce que le client/décideur, il veut du RedHat, mon bon môssieur, pardi. Mais il veut pas acheter une licence en plus... En fait, bien souvent, il en a rien à carrer des mises à jour : il veut que tu installes l'application X ou Y et puis c'est marre pour 3 ou 5 ans. Comme quoi, qu'il y ait davantage de RHEL ne veut rien dire.
*: ou autre application qui a bien besoin d'un système dédié.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
Ce n'est pas vrai :-)
Depuis RHEL 3, RHEL support les dépôts yum.
Donc il suffit, par exemple, d'utiliser des dépôts CentOS.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Parce que vouis-tu, mon petit IsNotGood, j'avais déjà essayé et sans aucun succès. Oui l'outil up2date de RHEL3 supporte les dépôt de yum mais il faut l'enregistrer pour pouvoir s'en servir.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
Il y a aussi apt et yum pour RHEL 3.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Qu'en est-il de yum sous RHEL à présent qu'ils ont changé d'outil ?
Quand tu as le bonheur de travailler pour une SSII, le client t'impose souvent le système sur lequel tu vas travailler. Manque de bol*, c'est une RHEL3. Et là, vas expliquer au client qu'il faut installer apt/yum pour pouvoir bénéficier de dépôts tiers afin d'installer l'application qu'il désire ? Et qui va assurer la maintenance du système ? RedHat ? Non, c'est la SSII, donc moi.
*: ça pourrait être pire : Windows.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
Non, je le confirme pas.
Mais je confirme qu'il faut être brelle pour ne pas arriver à administrer une RHEL 3.
> Qu'en est-il de yum sous RHEL à présent qu'ils ont changé d'outil ?
Il y a yum par défaut dans RHEL 5.
Rhn est pris en charge par un plugin de yum (plugin qu'on peut retirer).
> Manque de bol*, c'est une RHEL3. Et là, vas expliquer au client qu'il faut installer apt/yum pour pouvoir bénéficier de dépôts tiers afin d'installer l'application qu'il désire ?
Je comprend très bien ça.
> Et qui va assurer la maintenance du système ? RedHat ? Non, c'est la SSII, donc moi.
Rassureme moi, on te paye pour ça ?
Ben Red Hat demande la même chose.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Tu n'es pas capable de confirmer parce que tu ne le sais sans doute pas.
C'est quand même plus facile d'insulter les autres que d'admettre que tu ne peux pas répondre à une simple question.
Administrer une RHEL3 sans RHN, c'est la croix et la bannière, point.
Qu'on puisse installer et utiliser apt/yum, c'est bien gentil mais autant installer directement une CentOS.
Tu devrais aller voir le nombre de RHEL qui ne sont pas enregistrées.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
Non, je n'ai pas de RHEL 3 sous le coude.
> Tu n'es pas capable de confirmer parce que tu ne le sais sans doute pas.
OK, admettons que j'ai tout faux.
Je te présente mes plus plates excuses.
M'enfin, ça ne doit pas être compliqué de trouvé apt ou yum pour RHEL 3. Et ces derniers existent. Pas de doute.
> C'est quand même plus facile d'insulter les autres
J'ai dit que tu faisais preuve de mauvaise volontés.
Alors peut-être que ton client ne t'a donné que 2 heures et c'est court pour s'immerger dans RHEL3, trouver apt/yum/que-sais-je, etc.
> Administrer une RHEL3 sans RHN, c'est la croix et la bannière, point.
Ne le fait plus.
> Tu devrais aller voir le nombre de RHEL qui ne sont pas enregistrées.
C'est bien la preuve que beaucoup se démmerdent sans rhn. Mais pas toi.
> autant installer directement une CentOS.
Fait comme ça.
Mais il est stupide de vomir sur RHEL et trouver CentOS génial. Les deux sont à 99,999 % la même chose.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Je ne vomis pas sur RHEL : des personnes ont simplement eu encore beaucoup de mal à comprendre que CentOS ~= RHEL. Pour beaucoup de gens, la marque prime d'abord (malheureusement).
Si on avait pu imposer autre chose que RedHat, on aurait sans doute choisi CentOS ou Debian ou une autre distribution pour laquelle on aurait eu droit à des mises à jour de façon simple.
Surtout que c'était pour installer des logiciels qui ne sont de toutes façons pas fournis par RedHat (va comprendre...).
M'immerger dans RHEL3, c'est une chose, m'immerger dans le protocole SNMP aussi mais la priorité, c'était surtout de réaliser la prestation le plus vite possible.
À l'époque, j'avais sans doute du mal à comprendre pourquoi le client ne voulait pas nécessairement s'enregistrer au RHN tout en voulant une *RedHat*, payer le support, etc..
La question se pose moins aujourd'hui car on dispose de notre propre offre de support. Il suffit que le responsable d'avant-vente puisse le caler avec l'offre de services. Après, si le client ne veut pas payer de support, c'est différent.
Le problème, c'est que ce n'est pas lui qui se paluche l'installation !
[^] # Re: Mesures qui seront prises ?
Posté par ohnoes . Évalué à 2.
Appliquer des correctifs n'a pas les mêmes implications qu'une mise à jour majeure de distro. Si tu veux écrire une appli et ne pas avoir à la maintenir constamment sur les changements d'APIs, t'installes une RHEL et tu t'en soucies plus, ses libs sont figées.
Alors oui, RedHat maintient encore RHEL2.1 mais sans doute parce qu'il a encore des clients qui en font la demande
Captain Obvious to the rescue !
Moi qui croyais que Red Hat faisait de la charité. Mes croyances en Saint Red Hat sont maintenant brisées.
Bien sûr qu'ils le font parce qu'il y a de la demande, c'est justement pour ça que le bénévolat a ses limites et qu'il ne réponds pas à tous les besoins. Sarge a été déclaré EOL il y a deux mois :
http://wiki.debian.org/DebianSarge
Soit avant même que etch n'ai de successeur. Ca parait évident que le modèle bénévole ne fait pas toujours le poids contre le modèle commercial.
Et pourquoi pas des CentOS ? Parce que le client/décideur, il veut du RedHat, mon bon môssieur, pardi. Mais il veut pas acheter une licence en plus...
Pas la faute à RedHat si le client est un idiot lunatique.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Mesures qui seront prises ?
Posté par herodiade . Évalué à 10.
Clairement. Je suis aussi un amateur de Debian, adminsys (avec environ 100 serveurs sous Debian a auditer dans l'urgence, youpi ...), et je vais aussi passer à RHEL/Centos/Fedora. La coupe est pleine :
* En novembre 2003, la clef d'un développeur Debian a été compromise, des serveurs Debian ont été piratés. Gros problème. Mais rien n'a changé.
* En juin 2005, plus de mises à jour de sécurité pendant plusieurs semaines (alors que des failles dans spamassassin et sudo couraient), tout ça parceque la security "team" (Martin Schulze) était occupé au LinuxTag et que la nomenclatura Debian (ftp-masters, security team) n'aime pas déléguer ou partager leur pouvoir. Outre les mises à jour, même les annonces de problèmes n'étaient plus faites. Gros problème. Mais rien n'a changé.
* En mai 2008, on apprend cette nouvelle affaire.
* Une intégration très à la traine (parfois inexistante) des technologies de fiabilisation modernes, au moins dans la dernière version dite stable : support SELinux moins que sommaire, pas d'Exec-Shield, pas encore de version intégralement recompilée avec -fstack-protector, pas de FORTIFY_SOURCE, pas de compilation intégrale de l'archive avec -fPIE -pie (Position Independant Executables), pas de restrictions de l'accès à /dev/mem, pas de ELF Data Hardening systématique (ld -z relro), pas de support de la glibc pour les mots de passes chiffré plus sérieusement que DES/MD5, bref, toutes ces bonnes choses dont Red Hat, SuSE et Gentoo disposent depuis un bon moment déjà... chez Debian, la sécurité est la 4em roue de la charrette. Si seulement le suivi des problèmes de sécurité chez Debian était si bon qu'il permetait de se passer de tout ça...
L'erreur est humaine, et ce sont des bénévoles, mais cette liste se concentre uniquement sur les problèmes d'organisation et leurs conséquences, pas le manque de travail : incapacité à décider (ie. forcer l'augmentation da secu team, forcer la compilation avec -fstack-protector, ne pas accépter de packager des progs trop mal codés, ne pas avoir pris de résolution drastique après les deux précédents énormes fiascos, etc) et de laxisme à l'égard de la sécurité, et on voit qu'ils sont énormes. J'adore la souplesse de Debian, j'adore apt, j'adore le fait qu'elle supporte autant de paquets et d'architectures, mais au bout du compte cette distro n'est pas faite pour moi : pour mes besoins, la sécurité compte plus que le reste, et ce n'est donc pas un bon choix de distro.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -5.
Clairement. Je suis aussi un amateur de Debian, adminsys (avec environ 100 serveurs sous Debian a auditer dans l'urgence, youpi ...), et je vais aussi passer à RHEL/Centos/Fedora
J'hallucine ! Vous vous plaignez, alors que c'est les gens comme vous - les administrateurs systèmes fainéants, radins et pressés - qui ont fait du lobbying pour que Debian reste telle quelle est pendant des années !!
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
J'adore la plaisanterie !
Mais là... c'est le bordel.
> pour que Debian reste telle quelle est pendant des années !!
L'objectif de Debian n'est pas d'être troué de partout.
C'est d'être un système libre, libre aussi de contraites commerciales. Sur ce point c'est OK.
Mais par manque de décision, à vouloir trop contenter tout le monde, on flirte avec le fisco. Les moyens ne manquent pas vraiment (en tout cas c'est mon impression), mais ils sont mal utilisés/canalisés et le projet dans son ensemble en souffre.
Il me semble que c'est que c'est quelque chose comme ça qu'a voulu dire herodiade. Je ne pense pas que herodiade est devenu est dingue des distributions "commercialement" sponsorisé. Il y va "résigné".
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
Debian, aimez là ou bien quittez là.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
[^] # Re: Mesures qui seront prises ?
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 3.
Je suis consient que le fait de crée une nouvelle structure (ou appellez ça comme vous voulez) ça va prendre du temps et c'est ce que j'aimerai voire, une nouvelle structure.
Et évidemment je pense que tout utilisateur Debian veut éviter d'en arriver là mais, dans le pire des cas, si Debian ne fait rien (peut probable) c'est ce qui risque d'arriver (des changements de décisions/d'orientation).
Donc on attend de voire et pour l'instant je voulais juste me renseigné pour savoir si quelques pistes avaient déjà été sugérées.
[^] # Re: Mesures qui seront prises ?
Posté par brunus (site web personnel) . Évalué à 2.
http://www.viruslist.com/en/viruslist.html?id=4150
Vous l'avez oublié ou quoi la Lion Worm ?
[^] # Re: Mesures qui seront prises ?
Posté par fredix . Évalué à 2.
Blague à part dans la réalité on peut pas demander à des bénévoles qui ne bossent pas à plein temps sur Debian la même réactivité qu'une boite qui paye des gars à faire ça toute la journée.
On a tous cru que c'était possible, mais il faut bien admettre que ce n'est pas un acquis.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
C'est possible, il faut juste un modèle de développement qui transcende les foules et qui donne envie de s'impliquer.
[^] # Re: Mesures qui seront prises ?
Posté par fredix . Évalué à 2.
Il y a bien un moment où tu dois aller bosser histoire de bouffer..
Sérieusement, entre un passionné qui passe au mieux 70% de son temps libre sur Debian (et donc célibataire hein) et un autre passionné qui passe 100% de son temps pro et voir 20% de son temps libre sur une distrib, lequel sera le plus efficace ?
Le modèle 100% communautaire a ses limites et apparemment Ubuntu n'a pas l'air d'y remédier ...
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Oui et non.
Ce n'est pas un problème de "réactivité".
C'est un problème de gestion, de leader fort.
Fedora fait des trucs, ça sucks, le driver NVidia explose en vole, mais on continue. Le "sacrifice" de l'évolution est assumé.
Avec Debian c'est "j'avance pas car il y ci, j'avance pas car il y a ça, j'avance pas car j'ai 56 cpu à supporter, etc".
Évidemment le problème des moyens se pose toujours (et aussi pour Fedora et tous les distributions).
Mais si ton objectif c'est de ne jamais rien casser, ben tu n'avances pas.
Le choix de Debian est respectable. Mais ces problèmes ne sont pas, à mon avis, des problèmes de moyens. Sûr avec des moyens infini tu viens à bout de tout. Mais les moyens infinis ça n'existe pas.
Un mail de Jeff Spaleta sur "Idea Storm" :
http://www.redhat.com/archives/fedora-devel-list/2008-May/ms(...)
Ben oui, Fedora n'a pas les moyens de cette idée...
C'est une politique d'utilisation des moyens qu'on voit ici. Debian, à mon avis, les utilise mal.
Chez Fedora : "on ne peut pas faire => on ne fait pas"
Chez Debian : "je ne sais pas si je vais réussir à le faire => je le fais quand même"
C'est l'idée globale qu'il faut retenir ici.
[^] # Re: Mesures qui seront prises ?
Posté par fredix . Évalué à 3.
Je vois pas trop le rapport avec la choucroot là. Un DD a merdé et c'est resté en l'état 2 ans.
On peut expliquer ça par un manque de moyen, de temps, de rendre aucun compte à rendre à personne (je commente le code et c'est plié).
Bref une QA a besoin de tout ça et un problème plus ou moins similaire pourrait sans doute aussi arriver à Fedora un jour ou l'autre je suppose. A moins que RH y apporte quelques soutiens.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 3.
Tu peux ramener tous les problèmes de Debian à un manque de moyen.
Tu peux aussi dire que les objectifs (être mignon avec tout le monde et 56 architecture) sont foireux.
> Bref une QA a besoin de tout ça et un problème plus ou moins similaire pourrait sans doute aussi arriver à Fedora un jour ou l'autre je suppose.
Oui, ça peut arriver (j'ai du mal à croire que ça arrivera de façon aussi grossière).
> A moins que RH y apporte quelques soutiens.
Il n'y a "que" 40 employés Red Hat à plein temps sur Fedora (estimation non officielle).
La différence n'est pas sur les moyens, mais sur l'utilisation des moyens.
Sûr que plein de monde voudrait des Fedora LTS un Fedora backport au-lieu que Fedora monte en version et casse la compatibilité, etc. Mais Fedora n'a pas les moyens, donc Fedora ne fait pas. Idem pour OpenSuSE etc.
Debian a "seulement" trois branches en parallèle + la vieille Sarge le tout pour 11 architecture. 2 des branches sont supportées (avec patchs de "sécurité"). Il faut pouvoir mixer du stable avec du testing avec du unstable, etc.
Après Debian sous-endent "on n'a pas les moyens d'auditer correctement OpenSSL". Franchement, c'est une blague.
Debian ne se donne pas les moyens.
[^] # Re: Mesures qui seront prises ?
Posté par fredix . Évalué à 3.
Désolé mais ça change pas mal de choses avec une distrib ou il n'y a aucun employé à plein temps (modulo les retours de Ubuntu mais bon apparemment Debian c'est plein du peu de retours justement).
[^] # Re: Mesures qui seront prises ?
Posté par herodiade . Évalué à 5.
Les ressources techniques et humaines motivées ne manquent que rarement chez Debian. Le support des archis exotiques ne devrait plus être un frein non plus (celle qui ne suivent pas sont déclassées). Le plus clair de l'efficacité et de la belle énergie de Debian est absorbé par la lourdeur bureaucratique et l'effet de groupe (inertie "conservatrice", résistance au changement).
Il est juste impossible de prendre une grande décision qui implique de vastes changements « parce que c'est toujours mieux à vent » , et qu'après avoir proposé un tel changement sur une mailing-list, avoir débatus des mois sur des mailing-lists, retoqué son projet parce qu'il impliquerai un changement de la constitution debian ou autre formalité administrative, on déclencherai une grande bataille généralisée par mailing-list interposée, jusqu'à ce qu'épuisement s'ensuive. L'aspect administratif et bureaucratique a aussi préséance sur l'aspect méritocratie (quelqu'un d'hyper compétent ne peut pas prendre une décision importante dans son domaine, ou presque). Exemple facile : décider de compiler toute (ou presque) l'archive avec "-fstack-protector" demanderait qu'une personne puisse prendre la décision, et on s'y tient ; mais chez Debian la seule option pour arriver à ça serait d'engager un très long débat sur m-l, essayer de convaincre tout le monde, s'engueuler, peut-être lancer un vote, ...
Aussi, tu peux être certain que le problème révélé cette semaine n'aboutira à aucun changement structurel (et surtout pas une décision du type : tout commit sur les logiciels a, b et c doivent être audités, revues et approuvés par un groupe de relecteurs qualifiés). Ca continuera comme avant.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Mouaif.
Tu es plus spécifique (voire plus). Et probablement plus dans le vrai.
Mais ma description peut être une conséquence visible du problème que tu donnes.
> Aussi, tu peux être certain que le problème révélé cette semaine n'aboutira à aucun changement structurel
J'ai parcouru rapidement la liste devel de Debian. J'ai tendance à te donner raison.
Ça oublie souvent l'essentiel pour verser dans les trucs accessoires.
Avant de définir ce qu'il faut, ça commence par discuter sur comment le faire (git, guild, etc), etc.
Si quelqu'un dit que la règle doit être de renvoyer les patchs upstream, t'en a 10 qui disent que non car certains projets sont morts, etc. Ça oublie que les règles ont des exceptions...
Je caricature, mais c'est l'impression que ça donne.
Effectivement, on peut s'intéroger s'il sortira quelque chose de tout ça.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Un message après un très long thread :
http://lists.debian.org/debian-devel/2008/05/msg00681.html
Ah, interesting. We are not trying to solve the same problem, which
might explain why it's so hard to converge to a single solution.
The problem I am interested in solving is:
It is currently difficult for people not involved in Debian
development (upstream, other distros, users) to know which patches we
applied, the reason for the patch, and whether they should be
interested in that patch or not.
C'est "marrant". Parce que le problème, même s'il est recentré, n'est pas principalement ici (même si le problème décrit n'est pas à négliger). Le problème est de remonter les patchs upstream. Les développeurs upstream ne vont pas regarder les patchs de Gentoo, de Mandriva, de Red Hat, de Novell, Fedora, Ubuntu, Mepis, etc.
Ils ne l'ont pas fait pour cette faille...
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamS(...)
All patches in Fedora spec files SHOULD have a comment above them about their upstream status. Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch. For example:
# http://bugzilla.gnome.org/show_bug.cgi?id=12345Patch0: gnome-panel-fix-frobnicator.patch
Ça vient d'être approuvé par le FESCo.
Notons que Fedora a toujours insisté pour bosser en upstream :
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
Il y a une réflexion pour mettre certains paquets critiques dans une catégorie spéciale.
Pour Debian ?
Ben j'imagine que ça doit encore parlementer.
[^] # Re: Mesures qui seront prises ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Pour ta gouverne, non seulement supporter plein d’architectures ne représente quasiment rien en temps pour les mainteneurs (ça occupe surtout les porteurs), mais cela permet un travail de QA et de nettoyage du code qui n’aurait jamais lieu sinon.
Par exemple, un bug magnifique trouvé dans XPCOM pas plus tard qu’aujourd’hui : https://bugzilla.mozilla.org/show_bug.cgi?id=434190
De manière générale, je ne sais pas d’où tu sors ta vision du monde du libre, mais tes commentaires sont tout simplement pathétiques.
[^] # Re: Mesures qui seront prises ?
Posté par ohnoes . Évalué à 2.
Pour ta gouverne, non seulement supporter plein d’architectures ne représente quasiment rien en temps pour les mainteneurs (ça occupe surtout les porteurs)
Allez, un exemple tout récent sur la version d'xorg livrée par Fedora 9 qui a fait peur à des gens parce qu'elle n'est pas en version finale :
https://www.redhat.com/archives/fedora-devel-list/2008-May/m(...)
Somehow I doubt its important for us to slip a major component like
xorg-server over something like an alpha architecture compiling bug
which isn't relevant to Fedora's ability to ship a usable xorg-server
to our users...at all.
Quand on se permets de dire "on s'en fout" à des architectures, on peut sortir le produit plus tôt.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
C'est très bien les gens qui font des efforts pour supporter une architecture. C'est très très respectable. Mais bloquer tout le reste (98 % des utilisateurs) à cause d'une architecture...
[^] # Re: Mesures qui seront prises ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Les problèmes liés au support de nombreuses architectures provoquent ponctuellement des problèmes avec testing, qui n’ont pas d’impact sur le développement dans unstable. Donc dire que ça retarde les releases, c’est vrai dans une faible mesure, mais dire que ça retarde l’inclusion de fonctionnalités, c’est juste étaler ton ignorance.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 0.
Mais c'est le nombre d'architecture, le fait d'avoir stable/testing/unstable/backport/que-sais-je-encore , de maintenir des patchs en local au-lieux de les envoyer en upstream, de vouloir sa propre branche Firefox, etc.
C'est un problème globale.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Évidemment, ce ne sont pas forcément les plus attirants...
[^] # Re: Mesures qui seront prises ?
Posté par fredix . Évalué à 2.
Si c'est pas attirant et en plus tu n'es pas payé pour et qu'en plus ça prend du temps sur ton temps libre, le problème risque de ne pas être résolu avant longtemps ...
En même temps Debian n'a pas de clients, au sens commercial du terme, et même s'il y a plus que les DD à l'utiliser ça ne changera pas grand chose pour eux.
A mon avis des entreprises qui se base sur Debian, comme Ubuntu, devraient embaucher des gens à faire ce type de travail... Ca serait la moindre des choses.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
Évidemment, ce ne sont pas forcément les plus attirants...
Mais vous comprenez rien !
Ce ne sont pas ces postes qui ne sont pas attirants, c'est le modèle de développement.
tuomov a écrit l'essentiel, cherchez "megafreeze delopment model is broken" sur google.
Ce sont des postes très attirant aux contraires, et je m'y dévouerai corps et âme si seulement debian se souciait des utilisateurs comme Béranger, tuomov, Gniarf et moi. Il y a un sérieux problème parmi les distros actuelles. C'est soit noir, soit blanc. Soit stable et obsolète, soit à jour et instable, soit debian -stable, soit Arch Linux.
MOI je sais ce qu'il faut à Debian. Ce n'est pas un leader fort comme l'autre dit, je l'ai déjà prouvé sur linux.debat
Ce qu'il faut à Debian, c'est son identité technique. Son identité morale, on la connait elle est résumé dans les DFSG et ça prouve que quand on écrit les choses clairement ça transcende. Mais techniquement, Debian c'est à la fois le paquet X quelconque dont on a rien a cirer mais aussi open ssl.
J'ai pas envie de me répéter, je copie colle :
--------------------
stable a une raison d'être.
Mais ce n'est pas la priorité.
stable aurait dû être traitée comme debian kfreebsd : un projet en plus,
parce qu'on peut se le permettre.
Un OS c'est deux choses :
- une philosophie
- une (petite) base stable : kernel + X + un windows/desktop manager.
Le reste découle de là.
Windows possède un tiret. Debian l'autre.
-----------------
Thierry B. wrote:
> --{ ciol a plopé ceci: }--
>> Un OS c'est deux choses :
>> - une philosophie
>> - une (petite) base stable : kernel + X + un windows/desktop manager.
> C'est marrant, mais c'est exactement ce que permet de faire Debian,
> tout comme plein d'autres OS libres.
Votre remarque est pertinente. Il y a un effet de bord qui donne l'effet
escompté, certes. Mais ça marche pas. Il faut que ce soit écrit. Vous
imaginez ce que serait Debian sans les DFSG (règles) écrites ?
-> rien.
Des tas d'autres OS libres permettent des tas de choses en théorie.
PCLinuxOS, Foresight Linux, Fedora, etc... Mais leurs modèles de
développement n'est pas écrit. C'est tout simplement stressant.
Pour moi, ces distributions sont amputées d'un bras.
J'aime savoir où va un projet avant de le rejoindre.
------------------
J'énumère encore une fois ici les différents types de distribution
proposée à l'utilisateur :
* Les distributions stables mais complètement obsolète -> [Debian stable]
* Les distributions parfaites mais où on passe des heures à compiler (en
fait c'est surtout que mon PC chauffe énormément, et quand bien même,
passer à une distribution source serait un aveux de défaite, un
renoncement total au binaire et au passé des vieux PCs avec un hardware
insuffisant, je me comprends) -> [Gentoo]
* Les distributions instables pour un utilisateur non confirmés, et qui,
même pour un utilisateur confirmé, sont stressantes -> [Arch Linux]
* Les distributions batardes de type [Ubuntu] : cycle de vie trop court
pour être stable, trop long pour ne pas être obsolète.
* Les distributions batardes de type [Fedora] : mélange de Ubuntu et de
Arch Linux.
* Les distributions qui ont une base stable, et tout le reste à jour. Ça
pourrait être parfait, sauf que : la base est trop petite (j'ai prouvé
qu'il fallait au moins un gestionnaire de fenêtre, et donc bien sûr X),
et toutes les bibliothèques, même si elles ne font pas parties de la
base, sont traitées de la même façon que les applications tierces (alors
qu'il faut aussi les figer, mais d'une façon plus subtile que la base)
-> [Draco Linux].
Il me manque encore un thread que je croyais avoir envoyé sur debian.devel.french mais qui a disparu !!
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
Pour comprendre, il faut se poser des questions.
À la question "qui est Debian ?", vous pouvez répondre seulement :
"c'est un projet communautaire relativement porté sur le libre".
Mais techniquement, vous ne pouvez rien affirmer. Techniquement, c'est
un projet susceptible de devenir tout et son contraire.
La différence entre vous et moi, est dans les mots :
- vous : "ce que permet de faire debian"
- moi : "ce qui *est* debian"
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
> Ce qu'il faut à Debian, c'est son identité technique. Son identité morale
Les deux sont liés.
Paul Frields est le nouveau "boss" de Fedora. Il est fort car les fondamentaux de Fedora sont forts.
Mark S. a du carisme, mais quand tu dis des conneries, le carismes ne suffit plus.
Être un leader fort, ce n'est pas seulement avoir du carisme.
> on la connait elle est résumé dans les DFSG
C'est un peu maigre (ou trop vaste).
L'identité de Fedora (que je me permet de résumer en deux liens) :
http://fedoraproject.org/wiki/Objectives
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> Des tas d'autres OS libres permettent des tas de choses en théorie. PCLinuxOS, Foresight Linux, Fedora, etc... Mais leurs modèles de développement n'est pas écrit.
Ce nest pas vrai pour Fedora.
Je suis bien d'accord avec l'importance de l'identité.
Mais des identités Debian tu en trouvera 50 interprétations si tu résumes l'identité de Debian à DFSG.
Fedora n'a pas fait la "bêtise" de résumer son identité à "c'est du libre".
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -3.
> C'est un peu maigre (ou trop vaste).
Oui, il y a aussi le contrat social Debian : http://www.debian.org/social_contract
> > Des tas d'autres OS libres permettent des tas de choses en théorie. PCLinuxOS, Foresight Linux, Fedora, etc... Mais leurs modèles de développement n'est pas écrit.
> Ce nest pas vrai pour Fedora.
Si. Ce n'est *vraiment* pas clair. Qu'est-ce qui est considéré comme critique et qui ne bougera quasiment pas ? Qu'est-ce qui pourra être updaté sans risque ? Tout ça n'est pas écrit. Fedora n'est pas un OS comme je l'entends. C'est une distribution comme beaucoup d'autres, sans squelette comme possède FreeBSD ou Windows.
De toute façon, Fedora n'est pas comparable à Debian. C'est une distribution à la botte de RH, qui a un cycle de release de 6 mois totalement artificiel.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Rien. S'il y a des raisons techniques de faire un changement ben il est fait. Évidemment, il faut vérifier les moyens pour parvenir, etc.
> Qu'est-ce qui pourra être updaté sans risque ?
Rien. On peut casser la compatibilité etc.
M'enfin, il faut être con pour le faire toutes les semaines. Fedora sait que ça emmerde l'utilisateur, donc c'est fait au cas par cas.
Ici tu parles d'appréciations ou gestions techniques. Il y a le FESCo (Fedora Engineering Steering Committee) pour arbitrer.
Les limites, sont Red Hat. Par exemple Red Hat paye des employés pour bosser sur ext3/ext4, donc le système de fichier par défaut est ext3/ext4. C'est assez annexe.
> Tout ça n'est pas écrit.
Beaucoup est écrit :
http://fedoraproject.org/wiki/
Ce n'est peut-être pas assez, mais beaucoup est écrit.
> qui a un cycle de release de 6 mois totalement artificiel.
Totalement artificiel ?
Es-ce que Fedora a des impératifs commerciaux ?
Es-ce le cycle de 6 mois de Gnome est artificiel ?
C'est pour des raisons techniques et pour permettre les développements. Je ne vais pas l'expliquer encore ici pour la 100ième fois.
> C'est une distribution à la botte de RH
Red Hat est diabolique...
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -3.
Non, mais si j'ai quitté Windows, c'est pas pour utiliser un autre OS géré par une entreprise. Je sais trop ce qu'elles sont capables de faire pour survivre.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 1.
T'as oublié d'ajouter un qualificatif pittoresque. Comme "ces enculés".
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à 0.
C'est facile de me faire passer pour un communiste de base. Je dis seulement que quitte à avoir le choix, je préfère une distribution totalement communautaire. Ni plus, ni moins.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Mais Fedora n'est pas à la botte de RH.
Fedora c'est aussi des développeurs bénévoles et ils ne sont pas à la botte de RH.
Tu pourrais les respecter même si tu ne veux pas d'une Fedora.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -3.
Si. Est-ce que Fedora peut utiliser un noyau BSD au lieu de Linux ? dpkg au lieu de RPM ? Non. Ce sont des exemples extrêmes, mais je suis sûr qu'on doit pouvoir trouver des exemples moins triviaux.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Oui, mais Fedora n'a aucune raison de le faire.
En passant, l'objectif de Fedora n'est pas d'avoir 50 noyaux, 12 toolchain et supporter 73 architectures qui sucks plus les unes que les autres.
> je suis sûr qu'on doit pouvoir trouver des exemples moins triviaux.
Juste comme petit exemple, apt/synaptic/etc est dans Fedora depuis le début de Fedora (ils y sont toujours).
T'as envis d'ajouter urpmi ?
Vas y. Si le boulot est de qualité, ça sera accèpté.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -1.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
Bien.
> Je n'en veux pas pour moi, c'est tout.
Pas de problème, amuses toi avec ce que tu préfères/conviens/etc.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Mesures qui seront prises ?
Posté par Gniarf . Évalué à 4.
[^] # Re: Mesures qui seront prises ?
Posté par dab . Évalué à 5.
Pourquoi finir cette phrase de cette manière ?
Tes propos peuvent être intéressants, mais ces quelques mots ajoutés à la fin ne font que les desservir.
Pourquoi parler de 73 architectures qui sucksent au lieu de simplement dire que Fedora ne supporte pas 73 architectures.
Préciser que le but de Fedora n'est pas de supporter de nombreuses architectures est pertinent, dire qu'elles sucksent n'a pas d'intérêt.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . Évalué à 2.
OK, je retire, c'était totalement naze.
Désolé.
[^] # Re: Mesures qui seront prises ?
Posté par Anonyme . Évalué à 2.
[^] # Re: Mesures qui seront prises ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Si le modèle de développement n'était pas attirant, il n'y aurait pas autant de DD pour le projet Debian. C'est bien un problème de poste dont la tâche est assez ingrate. La plupart des DD s'occupent avant tout de leurs paquets et c'est déjà assez heureux.
> Un OS c'est deux choses :
> - une philosophie
> - une (petite) base stable : kernel + X + un windows/desktop manager.
Amusant, ça me rappelle une distribution. Attends voir, ça commence par U et ça finit par buntu.
> * Les distributions batardes de type [Ubuntu] : cycle de vie trop court
pour être stable, trop long pour ne pas être obsolète.
Dommage, c'était la seule qui semblait correspondre aux premiers critères.
Dis-moi, ciol, quand est-ce que tu vas nous sortir enfin ta distribution parfaite ? Entre 2 à 3 ans et 6 mois, je veux bien, mais si 6 mois, c'est à la fois pas assez mais déjà trop, je ne vois pas ce qu'il te faut.
Commence déjà par définir des limites claires entre la « base » et les « applications » et on en reparle (tu le mets où, Firefox ?).
[^] # Re: Mesures qui seront prises ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Merci pour ce moment de franche rigolade, ça fait du bien.
[^] # Re: Mesures qui seront prises ?
Posté par Tonton Th (Mastodon) . Évalué à 2.
Tant qu'a faire tu aurais peut-être pu donner quelques Message-Id: que les gens puissent aller voir le troll par eux-mêmes, plutôt que d'avoir ta vision probablement tronquée...
[^] # Re: Mesures qui seront prises ?
Posté par dinomasque . Évalué à 2.
Je pense qu'il peut arriver à n'importe qui et n'importe quand de faire une erreur, même aux meilleurs.
J'aurais perdu confiance en une organisation qui ne serait pas consciente de ses propres déficiences, en une organisation qui s'excuserait lamentablement en disant "je ne comprend pas comment cela a pu se produire", en une organisation qui chercherait un bouc émissaire (toute ressemblance avec une très estimable société de banque française ...).
Mais avec cette mésaventure Debian a montré que son mode d'organisation est transparent et parfaitement auditable.
C'est le premier pas pour rebondir et réfléchir sereinement à ce qu'il est nécessaire de changer ou pas pour (re)devenir un modèle de vertu et de sécurité dans le monde des systèmes d'exploitation.
En fait, je crois que j'ai encore plus confiance en Debian qu'avant.
BeOS le faisait il y a 20 ans !
[^] # Re: Mesures qui seront prises ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Oui mais bon en fait de modèle il me semble que le post d'Herodiade ci-dessus ( http://linuxfr.org/comments/931785.html#931785 ) souligne clairement que Debian est à la traîne question sécurité.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
Un problème tout les 2/3 ans. wow.
[^] # Re: Mesures qui seront prises ?
Posté par imalip . Évalué à 5.
Quant a prendre des mesures pour éviter que ca se reproduise, il y en aura surement, mais ce n'est surement pas en 48h et dans la précipitation qu'on va s'amuser a changer l'infrastructure du projet, c'est le meilleur moyen d'augmenter le bordel et les risques d'erreur.
[^] # Re: Mesures qui seront prises ?
Posté par ciol . Évalué à -2.
A ouais ? Et ça c'est quoi :
http://etbe.coker.com.au/2008/05/16/ideas-to-copy-from-red-h(...)
Blam. Si j'étais le DPL ou que Debian m'écoutait, j'aurais déjà fait de cette distro la meilleure de la galaxie.
# Un des premières conséquences...
Posté par Khâpin (site web personnel) . Évalué à 6.
http://xkcd.com/424/
True story: I had to try several times to upload this comic because my ssh key was blacklisted.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.