Sécurité : Découverte d'une faille de sécurité critique dans OpenSSL de Debian
Posté par Amaury (). Modéré le 15 mai 2008.
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.
![[en]](../images/en.png)
Le Debian Security Advisory (769 hits)-
Dowkd.pl - A télécharger absolument en cas de doutes ! (1755 hits)
-
Metasploit a généré les clefs faibles (680 hits)
![[fr]](../images/fr.png)
Journal Linuxfr déja paru à ce sujet (832 hits)-
Wiki Debian :à lire si vous ne savez pas quoi faire (810 hits)
-
... (225 hits)
> Lire la dépêche (329 commentaires, moyenne: 2,2).
Vous avez demandé le commentaire #931313.
Run by 
Cette page a été générée par Templeet en 0.1296s (dont 0.0136 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] Limite du développement bénévole
Au risque d'apparaitre iconoclaste, les professionnels utilisant Debian et ses dérivés devraient pourtant savoir que Debian n'en est pas à son premier gros problême de sécurité.
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….
Slackware depuis 1996
[^]Re: Limite du développement bénévole
Ton analyse pourrait paraitre sensée si seulement les OS commerciaux faisaient mieux... or c'est loin d'être le cas !
Corto
[+] [^]Re: Limite du développement bénévole
Une pareille boulette ne s'est pas emcore produite chez RedHat, Novell/Suse, Mandriva....
Slackware depuis 1996
[^]Re: Limite du développement bénévole
>Une pareille boulette ne s'est pas emcore produite chez RedHat, Novell/Suse, Mandriva....
On ne peut pas savoir.
[^]Re: Limite du développement bénévole
Redhat a aussi une politique très ouverte concernant la sécurité. Cette société ne plaisante pas avec la sécurité et ne cache ni nie les bugs de ses distributions surtout les RHEL
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.
Slackware depuis 1996
[^]Re: Limite du développement bénévole
> Ils testent donc soigneusement leur produits
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
d' accord ou pas avec toi, je suis un de plus à te moinsser, désolé.
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
> J' aurai envie de dire "ok le mainteneur à ch**** dans la colle mais pourquoi personne ne l' a vu et pourquoi pendant si longtemps ?"
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
> Moi j'imagine que PLEIN de personnes ont vu ce patch.
Ce "patch" est noyé dans d'autres patchs (le tout fait 3876 insertions(+), 722 deletions(-)).
[^]Re: Limite du développement bénévole
Pour le paquet aujourd'hui dans sid, il y a 5671 lignes dans le patch, mais 4337 sont pour le répertoire debian/ qui ne touche pas au code d'OpenSSL (et la majorité de ces lignes consiste en de la traduction).
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
> On ne peut pas savoir.
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
Mais pour information, Red Hat emploie Mark J. Cox qui est un des quatres "core team" d'OpenSSL.
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
> Forcément, là ça change tout.
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
la même non, mais il y en a d'autres...
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
Pas dans le même style, mais pour avoir utiliser longtemps des Mandriva(drake à l'époque), des boulettes maousses il y en a eu...dont une qui a aussi affecté Suse je crois...genre les fameuses versions qui flinguaient les lecteurs de CD/DVD (ou graveur, je ne me souviens pas très bien) lors de l'installation.
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
a sécurité d'un serveur, d'un réseau ou de données est ce qu'il y a de plus précieux dans une entreprise. Le matériel lui en comparaison ne coute rien.
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.
Slackware depuis 1996
[^]Re: Limite du développement bénévole
N'importe quoi, ce que t'appelles une boulette de la part de Mandriva et SUSE c'est une boulette qui provient de la programmation pourrie du firmware de ces lecteurs LG, qui interpretaient l'opération flush_cache de travers.
C'est une boulette de LG, qui fait du matériel de merde.
[^]Re: Limite du développement bénévole
tu parleur de ses lecteurs qui avaient des firmwares qui ne respectait pas les normes ?
lg a merdé pas mandrake
pour protester contre la dadvsi , je n'achete plus de produit soumis au droit d'auteur ou voisins
[+] [^]Re: Limite du développement bénévole
Faut pas exagerer non plus. D'accord LG a fait un produit merdique, mais il me semble que Mandrake etait la seule distrib a les detruire, en appliquant une methode de tests pas dans les normes non plus. Oui, les erreurs de Mandrake on mis en lumiere un probleme des lecteurs LG, mais c'etait quand meme une bourde de Mandrake.
[^]Re: Limite du développement bénévole
non.
[^]Re: Limite du développement bénévole
faux, les utilisateurs de Gentoo en ont souffert avant. il se trouve juste qu'ils ne comprenaient pas bien ce qu'il se passait alors, et que c'est Mandrake qui a "formalisé" ces problèmes
Windows has no users. It has hostages.
[^]Re: Limite du développement bénévole
ah tiens encore un qui réécrit l'histoire, donc bon pour être clair encore une fois :
- 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
> Une pareille boulette ne s'est pas emcore produite chez RedHat, Novell/Suse, Mandriva....
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
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.
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.
If you are the big tree,
We are the small axe...
[^]Re: Limite du développement bénévole
> Les paquets avec un gros patch debian/ + upstream n'existent quasiment plus
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
J'ai regardé pour iceweasel (2.0.0.14), ça ne semble toujours pas le cas
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
> 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.
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
> 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.
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
> C'est d'ailleurs pour ça que debian utilise iceweasel et non pas Firefox
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
A propos de FF3, j'ai entendu dire (rien de vérifié) qu'il inclut dans son magasin de certificats une autorité de certification qui a utilisé debian ou un de ses dérivés pour générer sa clé privée... *phear*
[^]Re: Limite du développement bénévole
> 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.
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
Une pareille boulette ne s'est pas emcore produite chez RedHat, Novell/Suse, Mandriva....
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
Ubuntu est developpe par une societe commerciale
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 ......
Slackware depuis 1996
[^]Re: Limite du développement bénévole
Petite correction: ubuntu est la distribution et canonical la société commerciale.
[^]Re: Limite du développement bénévole
La aussi Debian montre les limites du développement bénévole.
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
L'erreur est certe humaine, mais la première cause de l'erreur est du fait du manque de bénévoles ce genre de paquets sensibles ne sont pas audités et laissé sous la responsabilité d'un seul qui a modifié à la légère un composant de sécurité essentiel.
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 !
Slackware depuis 1996
[+] [^]Re: Limite du développement bénévole
Il me semble que tu fais une erreur de parler de manque de bénévoles.
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
En glanant des info ici et là il apparait que ce mainteneur n'a pas fait son boulot. et que son patch malheureux n'aurait jamais du être intégrer.
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....
Slackware depuis 1996
[^]Re: Limite du développement bénévole
Mais bien sûr,
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.