En effet, tout le monde ne fait pas du classique et dans la musique folk, notament l'accordéon diatonique, une grande majorité de personne travaille sur tablature.
Dans lilypond, ce support était très faible il y a quelques temps. A-t-on une chance de voir une évolution ?
> Bien sur qu'il faut les vérifier. Mais il n'y a aucune raison que l'outil pour le faire soit fourni
> et/ou publié par openssh.
Deux phrases en contracdiction.
Si, comme tu le dis, il est évident qu'il faille vérifier les clefs utilisé par ssh, je ne vois pas pourquoi openssh ne fournit pas un outil ! Evidement, cet outil peut utiliser des outils annexe comme ssh utilise ssl...
Cet outil ssh aurait pour fonction d'adapter l'outil de vérification 'ssl' à la spécificité ssh. C'est exactement ce que fait l'outil ssh-vulnkey. Il n'y a aucune raison objective, sauf la mauvaise fois il me semble, a ne pas diffuser ssh-vulnkey avec openssh. Ou est le problème ?
En cas de mauvaise fois, il n'y a la aucune escuse sur un site diffussant le numéro 1 des serveurs ssh a ne pas indiquer ou trouver des outils pour vérifier l'intégrité des clefs puisque nous avons vu que le protocole ssh avait une faiblesse au niveau de la gestion des clefs (pas de date limite, pas de système de révocation... comme dans un système X509).
Bref, il y a des mauvaises clefs dans la nature, en très grand nombre certainement encore. C'est un fait. La responsabilité est établie et reconnue. Je vois que 1 an après, malgré cela, le problème me semble mal cerné par pas mal de gens, tant utilisateurs que par les développeurs amonts (packageur de distribution compris).
Question : sur une base red-hat, suse, mandriva, BSD... a-t'on auourd'hui un outil pour vérifier l'intégrité des clefs lorsqu'on installe ssh ? Pas forcément dans le paquetage openssh mais dans les dépendances de ce paquet (idem pour les ports BSD). Je ne connais pas la response à cette question mais je l'espère positive et dans ce cas, je retire ma phrase sur les développeurs amont et je m'en escuse platement.
Oui, il y a une nombre finit de clef foireuse. Il suffit juste de tester que la clef n'est pas dans la liste. C'est d'ailleurs la dessus qu'est basé les blacklist de debian avec l'hypothèse que la clef fait 1024, 2048 ou 4096 bit de longueur et qu'elle est soit RSA soi DSA.
Il y a les programmes ssh-vulnkey et dowkd.pl
La probabilité d'avoir des clef autres que dans ses listes est asez faible. Pas grand monde devait faire des clef plus grande que 4096 si ce n'est des spécialistes mais ceux-la on déjà refait leur clef.
Il m'arrive d'édité à distance avec vi sans couleur.
Je n'aime pas que les règles de programmation dépendent de la couleur des choses. Un bon exempe d'un langage que j'aime beaucoup mais dont le créateur génial (Chuck Moore) a été, à mon sens, trop loin est colorForth.
> sans même avoir besoin de t'imposer de mettre $ devant tes noms de variables ;
Cela, c'est une connerie.
Je trouve que le $ devant les variables en bash, en perl génial. C'est d'une clarté limpide. En plus, en perl, il y en a toujours (même à l'affectation). Il n'y a aucune confusion avec les mots clef du langage.
L'horreur, c'est le CSH qui est tordu sur l'usage du $.
OK, perl a des problèmes de lisibilité mais ce n'est pas à cause du $ devant les variables.
En fortran 90, j'avais la convention suivante, tous les mots clef du langage en petit caractère et toutes les variables en majuscules. Le code était limpide.
Faire resortir les mots clefs du langage par rapport aux variables, ou inversement, est un excelente idée,
En fortran 90, on peut aussi avoir autant d'operateur que l'on veut avec la syntaxe
.operateur.
C'est très pratique. J'ai deux vecteurs, je veux le produit scalaire
v1 .scalar. v2
J'ai deux tenseurs, je veux aussi le produit scalaire
t1 .scalar. t2
Je me suis battu avec des thésards pour avoir cet opérateur .scalar. et non pas * comme beaucoup pense. *, c'est l'opérateur produit, mais produit de quoi : scalaire, vectoriel... Avec l'opérateur *, on ne sais jamais le type du résultat de l'opération et les formlules mathématiques deviennent imbittables.
En C ou en C++, on ne peut pas faire cela et c'est bien dommage, les formules de math sotn bien moins claires et du coup le risque d'erreur est plus important.
Si on souhaite un langage qui puisse faire "des math", il est important de laisser libre champs aux opérateurs et ne pas se cantonner aux seules méthodes. Les méthodes cassent la symétrie et ne reflète pas la formule
v1.scalar(v2)
est très différent de
v1 .scalar. v2
Dans le second cas, on a bien un produit scalaire entre deux vecteurs, ces deux vecteurs étant au même niveau.
Je crois que c'est une des raisons pour lesquelles perl6 ne sera pas pure objet et que les concepteurs veulent garder l'aspect multi-fonctions.
En dehors des math, je n'ai pas d'opinion et je ne sais pas si cela est aussi important.
Non, la faille est dans toutes les clefs pourris réalisés sur debian et ses dérivées qui, grace à internet, ont été distribués partout.
La faille debian n'est plus dans le serveur debian, elle a été corrigé du jour ou elle a été annoncé. Je pense qu'il n'y a plus beaucoup de serveur pourris qui tournent.
Mais des clefs... combien en reste-t-il qui trainent sur le net ?
Les seuls serveurs protégés sont justement ceux de debian. Quelle ironie !
Ton serveur sous OpenBSD, si un de tes utilisateurs a une clef debian de l'époque ne vaut plus rien, c'est une passoire... Mes serveurs debian ne risquent plus rien !
La faille debian est finalement assez proche de la faille DNS, elle touche tous les serveurs non paché qui ne sont pas capable de blacklister (révoquer) de mauvaise clef. Les clefs SSH n'ayant pas de date limite, la faille peut durer très très longtemps.
C'est pour cela qu'il faut patché tous les serveurs SSH, qu'ils soient debian ou non. Car le protocole SSH a oublié qu'il pouvait y avoir des clefs pourris. C'est une sorte de faille cela. Et les clefs n'ont pas de date limite, c'est encore une espèce de faille...
Avec SSL et les certificats X509, ce cas a été prévu avec les listes de révocation très mal implantés par les clients -> faille des clients.
SSH n'a aucune protection contre cela. Faille du serveur ou du protocole ?
J'ai presque envie de dire, cela aurait du arrivé un jour. C'est debian qui a fait la faute mais ce n'est pas normal que SSH soit aussi sensible a un bogue pareil. Un mec distribue des millions de clefs pourris dans la nature et tu n'as au niveau de ton serveur sous OpenBSD (ou autre) aucun moyen de lutter contre ses clefs si un de tes utilisateurs en a une ?
Si ce n'est pas une faille dans le protocole, c'est quoi ?
Laisse tomber, j'ai expliqué cela en long et en large mais manifestement, ceux qui ne tournent pas sur debian se croit à l'abris et n'en ont rien à foutre.
Moi, si Red-Hat avait fait la même bévue, je serais super content que debian intègre le patch Red-Hat qui me mette à l'abris. Un des points faibles des PKI (et des certificats X509) est la bonne (ou mauvaise) gestion des listes de révocation, notament par TOUS les clients potentiels ! Le système des blacklists mis en place par debian pour OpenSSH, c'est un peu le même esprit. Je regarde à chaque nouvelle version d'OpenSSH mais je suis surpris que ce path ne remonte pas.
Sinon, j'ai comme l'impression que certain se frotte les mains de la bavure debian comme s'ils étaient content que debian se soit lamentablement planté. A vrai dire, je trouve cela désolant mais bon, a chacun ses petits plaisirs.
Allez, pour le plaisir, une dernière petite tirade...
Un autre gros bogue en 2008 a été la faille dans le protocole DNS : "DNS Cache Poisoning Issue". Je suis allé voir du coté d'ISC avec Bind. Leur site en parle
D'ailleurs, le message commence par des remerciements.
Certe, le bogue n'est pas du même type (même origine) mais il touche tous les serveurs de noms et l'ISC ne le cache pas, il est même bien en évidence sur leur site bien que ni l'ISC ni Bind n'ont le moindre tord dans l'affaire.
Encore une fois, le bogue debian touche TOUS les serveurs SSH ! Même les autres serveurs qu'OpenSSH !
J'ai mon matos mais de temps en temps je loue des skis de Telemark (c'est très amusant, je conseille). Là ou je vais, c'est encore suffisament familial et tout est basé sur la confiance. Je laisse juste mon nom et mon adresse, et encore, que la première fois. Maintenant il me connait et ne me demande rien du tout. Il sais que je paye à la fin.
Tu oublies complètement le rôle de publicité, de la diffusion. Si Firefox vit si bien aujourd'hui, c'est que la fondation mozilla a fait un énorme boulot de publicité.
Le fait de distribuer un logiciel, d'en assurer la maintenace sécurité (même si dans le cas présent, il y a eu une bévue), le fait de le proposer aux administrateurs et aux utilisateurs pour une utilisation quotidienne, pour moi, cela fait aussi partie de la vie d'un projet.
Donc, pour moi, les distributions ne font pas que "packager", par la même une relation se forme avec le développement amont et elles participent ainsi fortement à la vie des projets. Tu oublies aussi que debian supporte un grand nombre d'architecture et que ce simple fait permet de remonter plein de problème dans énormément de programme. On ne parle pas ici d'une petite distribution faite dans son coin. Debian est un énorme projet communautaire libre qui a un impact non négligeable, même si toi, tu as l'impression de n'en rien utiliser.
Un autre exemple, GNOME a été fortement aidé par les distributions au début car KDE n'étais pas packager dans bien des distributions, dont debian. Je ne suis pas sur qu'on aurait un GNOME aujourd'hui si Qt avait été dès le début libre.
Idem pour les programmes Java, je suis persuadé que le fait d'avoir du java propre dans les distributions va enfin booster tous les programmes java libre.
Encore une fois, nous n'avons pas le même sens de la communauté, de la solidarité, des remerciements... J'ai bien fait d'arrêter de te répondre hier soir.
> OpenSSH vit grâce aux développeurs d'OpenBSD. Les distributions GNU/Linux ne font
> qu'empaqueter la version portable d'OpenSSH.
Tu sous estimes le boulot des distributions. Sans elles, OpenSSH est mort, au moins virtuellement.
Imagines un instant un autre programme qui remplace OpenSSH et que les distributions majeures n'installent plus OpenSSH ? Crois-tu alors qu'OpenSSH vit encore ? Non, du jour ou il y aura un remplaçant à OpenSSH sous les distributions Linux, de ce jour là, il sera mort.
Un exemple historique. Le programme xv est sortis des distributions il y a une dizaine d'année et pourtant on l'utilisais tous avant. Qui connait xv de nos jours à par les anciens croutons comme moi !
Je met ma clef réalisé sur un serveur debian sur une machine de l'IDRIS et je me connecte dessus... La machine de l'IDRIS est une IBM sous AIX... (Tu remplace IDRIS, IBM et AIX par ce que tu veux)
Bilan : n'importe quel petit malin rentre dans le système IBM qui n'a rien a voir avec debian !
La faille debian touche TOUS les serveurs SSH, même ceux qui n'ont rien a voir avec debian. Debian peut communiquer et l'a fait. Je ne vois pas en quoi il aurait été mal qu'OpenSSH commnunique la dessus. Même les machines sous OpenBSD sont touchés.
Vous pensez peut être que n'utilisant pas debian, vous êtes à l'abris du problème. mais ce n'est pas vrai. Qui vous dis qu'un utilisateur de vos systèmes n'a pas mis une clef foireuse sur vos systèmes ? Et vous la détectée comment la clef foireuse ?
C'est le principe même d'OpenSSH avec ses clefs qui a été mis a mal. La solidarité veut que tout le monde donne un coup de main pour éradiquer le problème le plus vite possible.
Une petite phrase, un lien... Ca leur aurait couté quoi à l'équipe d'OpenSSH ?
Je crois que tu ne saisis pas la portée du bogue. c'est pas comme un bogue dans bind ou dans openssl (tiens encore lui) et que tu met à jour et hop, tu retournes à ton café.
La, la mise a jour n'a pas mis à jour tes clefs... Il y a eu un boulot de fou pour refaire les clefs, les revalider, voire que plein de script ne marchait plus... J'ai même lu l'histoire d'une personne qui a perdus la main sur son cluster de 200 machines, et je pense que ce n'est pas le seul !
Ton trous de sécu dans le noyau Linux, tout le monde s'en fout entre () et cela n'a pas du tout les mêmes conséquences.
Moi je te dis que dans 10 ans, on ne retiendra que "le bogue debian dans Openssh" et rien de la routine que tu évoques dans ton post et que je recois tous les jours dans ma boite mail avec les alertes du CERT.
Je ne confond rien du tout. Relis ce que j'ai écrit ci-dessus dans mes réponses.
Le bogue est dans OpenSSL mais c'est surtout OpenSSH qui a été touché sur une partie des distributions Linux (debian et dérivée).
Quand tu as un programme sensible et réputé pour sa sécurité et qu'un de tes composants est pourris, je suis très géné qu'on ne m'en parle pas. Surtout lorsque le bogue touche principalement ton programme en particulier...
Lors du problème, ma première réacton a été d'aller voir sur le site
openssh.org
pour avoir des informations clefs, pour avoir le point de vu de l'équipe d'OpenSSH sur le bogue et la solution apporté par debian. Rien, rien, rien...
Manifestement, ce silence de l'équipe d'OpenSSH face à ce bogue UNIQUE, me met mal à l'aise mais ne vous pertube pas le moins du monde. Désolé, je dois être trop émotif.
- Oui c'est une erreur debian et non de l'équipe d'OpenSSH. Personne n'a dis que c'était une erreur d'OpenSSH
- Oui, c'est un bogue introduit dans OpenSSL qui a surtout touché OpenSSH (mais pas seulement, aussi les clefs réalisés pour des sites en https, aussi pour cfengine...)
Cependant, le programme le plus touché et le plus sensible a été ssh !
Ce n'est pas un petit bogue, c'est quelque chose d'exceptionnel qui n'arrive on l'espère qu'une fois par décennie. C'est un des évênements majeur de 2008, peut être une des rares choses qu'on se souviendra dans 10 ans : le bogue debian dans OpenSSH (même si c'est dans OpenSSL).
Moi, si je fais un programme a ce point sensible et une distribution majeure me fait un bogue pareil qui touche autant de gens, et bien je pense que la moindre des choses que je ferais serait d'en parler clairement et de dire que le problème est résolu et comment.
Ne pas mettre cette information, faire comme si elle n'a pas exister, même si l'équipe d'OpenSSH n'a rien a se reprocher, cela me parait grave d'un point de vu communication. En tout cas, a moi, cela ne me viendrait pas à l'idée d'ignorer une telle bavure.
OpenSSH vit aussi grace aux distributions GNU/Linux. Demander des remerciements et des dons, c'est bien. Mais il faut aussi renvoyer l'ascensseur. Les distributions aident aussi à diffuser et elle font globalement du super boulot, même si elles sont à base Linux et non de BSD. En plus debian est la seule distribution Linux (à ma connaissance) a vouloir faire un port BSD...
Alors, participer à l'information d'une telle bavue pour éviter que des milliers de gens ne se fassent pirater par ssh, cela me semble faire partie intégrante de l'esprit communautaire libre. Ou est la solidarité, ou est l'entraide ici ?
Pour moi, cette ignorance de la part d'OpenSSH me donne une impression de mépris envers debian et par la même envers toutes les distributions Linux.
Encore une fois, on ne parle pas d'un non évênement car je fais le pari que ce sera l'évênement top 1 de l'année 2008 plus tard. Ce sera même un cas d'école très certainement cité dans plein de cursus universitaire...
En France, les écoles reçoivent la taxe d'apprentissage, en espèce ou en nature.
Avec le système que Sarko nous met en place (autonomie des universités), une partie des salaires va finir par être payés par les sommes percues a ce titre...
Puisque je suis dans ce sujet, je viens d'apprendre que les présidents d'université pourraient toucher une prime de plus de 20kE ! Notre ministre voudrait aussi englober les vice-président... Tout ceci va nous mettre le système du pognon du privé dans le public et me semble plus que malsain. Pour ceux qui pensent que 20kE, c'est peu de chose, un président touche normalement entre 2500 et 4500E par mois comme salaire.
> Le problème d'OpenBSD, c'est que presque aucune entreprise n'a de monde qui bosse
> dessus à plein temps. C'est peut-être lié au manque d'utilisateurs, mais OpenBSD, c'est
> OpenSSH qui est très critique dans énormément d'entreprises
Justement, le problème n'est-il pas là.
Je m'explique après avoir fait un tour sur le site d'OpenSSH. OpenSSH est très lié, peu être trop lié a OpenBSD.
Pourquoi une boite va t'elle faire un don a OpenBSD alors qu'elle ne l'utilise pas et que ce n'est pas dans ses projets. Personnellement, je me suis posé la question mais a ce moment, il était hors de question d'avoir un port Xen d'OpenBSD.
Or, sur le site d'OpenSSH, il est bien spécifié que les dons doivent être donné a OpenBSD et que tout est mélangé car le développement est fait par la même équipe. Je cite
"
Donations are handled via OpenBSD, since OpenBSD is the environment and community where OpenSSH is developed
"
Pas étonnant alors que peu de monde développe OpenSSH si c'est a ces conditions...
Bref, j'adore OpenSSH que j'utilise tous les jours mais je ne suis pas spécialement intéressé par OpenBSD ni les déclarations de son leader.
Qui ne se souvient de la faille introduite par debian l'an passé... et du patch debian avec le blacklisting de clef. une fonctionalité que debian a rajouté. On aime ou on n'aime pas mais debian a proposé une solution au mal qu'elle a fait. Et bien, avec une petite recherche sous Google chez nos amis d'OpenSSH sur le sujet avec tout simplement
debian site:openssh.org
Le résultat est rien sur ce sujet. Rien, rien, rien....
Une faille énorme dans OpenSSH qui a touché des milliers de machines de plusieurs distributions Linux et rien, rien, rien sur leur site /a priori/.
Ben moi, je me dis que le développement d'OpenSSH n'est pas bien communautaire et beaucoup trop lié a celui d'OpenBSD.
Du coup, je donne de argent a d'autre projet libre ... ma bourse n'est pas non plus infini.
OK, j'avoue que je gère le parc sans aucune passion pour .NET donc je contaste juste ce que je vois avec un regard un peu 'candide'. Donc merci pour tes explications.
Enfin, c'est un peu fou ce que l'on trouve dans les clefs de registre 'ajout suppression de programme' sur .NET. Entre tes explications limpides et ses clefs, il y a un monde... Peut être faudrait-il que Microsoft embauches des linguistes pour nommer leur objet ;-)
> Tu peux avoir ton propre depot independant de MS, ta machine ne communiquera jamais avec
> un serveur MS
Je sais bien mais avec debian, sans faire de mirroir, debian ne me pompe aucune info, Microsoft non. Combien de PME ont leur propre WSUS ?
> Il y a Microsoft Update si tu aimes rester a travers le web (je ne vois aucune raison d'utiliser
> Windows Update ou Microsoft Update) qui fait les 2
Oui, j'aime faire un update via le web pour avoir un controle visuel. J'ai vu trop de poste que l'on croit à jour et qui ne le sont pas.
En plus, avec un contrôle visuel, on peut éventuellement rajouté des paquets.
Sinon, pour ton information, Microsoft Update ne prend pas en charge Office 2000, mais le site Office Update oui. Je ne parle dans mon post que de celui-la, pour les autres versions d'Office, je sais très bien que cela marche. Pour ton information, je gère un parc qui a plus que 10 machines Windows...
En plus, Windows update veut toujours me vendre sa sauce, par exemple Silversight dont je n'ai que faire mais n'est pas capable de me dire ce qui est obsolète et qui ne sers à rien (.Net version 1 peut être, quand sais-je ?).
> Depuis quand est-ce qu'il faut reformater un Windows pour le passer a la version suivante ?
> Ils supportent tous les upgrades sans probleme.
Tu répond à coté de la question. Je parle d'un upgrade d'un coup et d'un seul reboot (et en plus, tout en réseau).
> Niveau qualite des mises a jour permet moi d'etre d'un avis totalement contraire. Regardons
Mauvais interprétation de ma phrase qui pouvait effectivement porter à confusion. Justement, je ne voulais pas rentrer dans le débat de la qualité des patch... Je voulais juste parler de l'outil.
Enfin, tu me parles de GPO pour déployer des patch et que tout le monde fait cela. Pourquoi Microsoft n'utilise pas les GPO pour ses propres mises à jour, pourquoi deux systèmes... Et puis, si tu n'as pas d'AD, tu fais comment ? Et puis chez moi, le partage réseau n'est pas installé et l'expérience me montre que j'ai bien moins de soucis que mes voisins... Bref, a trop centraliser, on rigidifie, on balance tout sur le port 445... Moi, j'aime bien l'esprit UNIX ou on essaye de faire des concepts orthogonaux.
Je conçois bien que je n'ai aucune influence sur la politique de Microsoft mais je me donne le droit de ne pas la partager.
Oui, le système apt-get + les paquetages .deb (idem avec yum + rpm) est bien plus puissant a mon sens. Tant l'OS que tout les autres logiciels passe dans le même système.
> .Net 3 et 3.5 utilisent tous les deux la CLR 2.0. Ca fait donc 2 versions
Désolé mais ta phrase doit avoir un mot en moins. Je ne comprends pas le sens.
Alors, OK, .NET 3.5 et .NET 3.0, c'est la même chose.
Il n'empêche, j'ai des machines avec trois version de .NET alors que je n'ai jamais eu de version d'UNIX avec deux version de Perl.
Certes, Perl6 sera sur ma machine en parallèle de Perl5 mais Perl6 est un autre langage et la communauté ne s'amuse pas tout les 4 matins a changer l'API.
Enfin, j'ai donc 3 machines .NET sur une partie de mes machines et je n'ai de la part de Windows aucune indication pour savoir si oui ou non je peux les enlever. Aucune gestion des dépendances et ainsi de suite.
Donc oui je suis nul et je l'assume mais le parc que je gère fonctionne depuis des années sans grave panne... et madame michu chez elle, il m'étonnerais qu'elle se débrouille mieux que moi ;-)
Enfin, je commence a en avoir un peu marre de .Net et de java. Soi-disant, c'était portable et tout et tout.
En pratique, chaque mise a jour de java n'enlèva pas la précédente version de java sous Windows.
Mes postes sous Windows XP Pro ont si mes souvenirs sont bons :
.Net 1
.Net 2
.Net 3
.Net 3.5
C'est sur qu'avec quatre version, on peut faire des choses portables... et je ne sais même si je peux enlever une version sans tout casser.
J'ai des scripts perl qui ont dix ans et qui marche toujours sur la dernière version de Perl... Je n'ai jamais mis plus d'un interpréteur Perl sur une machine.
# Support des tablatures
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Frescobaldi, vous connaissez ?. Évalué à 4.
En effet, tout le monde ne fait pas du classique et dans la musique folk, notament l'accordéon diatonique, une grande majorité de personne travaille sur tablature.
Dans lilypond, ce support était très faible il y a quelques temps. A-t-on une chance de voir une évolution ?
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 2.
> et/ou publié par openssh.
Deux phrases en contracdiction.
Si, comme tu le dis, il est évident qu'il faille vérifier les clefs utilisé par ssh, je ne vois pas pourquoi openssh ne fournit pas un outil ! Evidement, cet outil peut utiliser des outils annexe comme ssh utilise ssl...
Cet outil ssh aurait pour fonction d'adapter l'outil de vérification 'ssl' à la spécificité ssh. C'est exactement ce que fait l'outil ssh-vulnkey. Il n'y a aucune raison objective, sauf la mauvaise fois il me semble, a ne pas diffuser ssh-vulnkey avec openssh. Ou est le problème ?
En cas de mauvaise fois, il n'y a la aucune escuse sur un site diffussant le numéro 1 des serveurs ssh a ne pas indiquer ou trouver des outils pour vérifier l'intégrité des clefs puisque nous avons vu que le protocole ssh avait une faiblesse au niveau de la gestion des clefs (pas de date limite, pas de système de révocation... comme dans un système X509).
Bref, il y a des mauvaises clefs dans la nature, en très grand nombre certainement encore. C'est un fait. La responsabilité est établie et reconnue. Je vois que 1 an après, malgré cela, le problème me semble mal cerné par pas mal de gens, tant utilisateurs que par les développeurs amonts (packageur de distribution compris).
Question : sur une base red-hat, suse, mandriva, BSD... a-t'on auourd'hui un outil pour vérifier l'intégrité des clefs lorsqu'on installe ssh ? Pas forcément dans le paquetage openssh mais dans les dépendances de ce paquet (idem pour les ports BSD). Je ne connais pas la response à cette question mais je l'espère positive et dans ce cas, je retire ma phrase sur les développeurs amont et je m'en escuse platement.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 3.
http://wiki.debian.org/SSLkeys
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 2.
Il y a les programmes ssh-vulnkey et dowkd.pl
La probabilité d'avoir des clef autres que dans ses listes est asez faible. Pas grand monde devait faire des clef plus grande que 4096 si ce n'est des spécialistes mais ceux-la on déjà refait leur clef.
[^] # Re: Une pétition ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Il faut sauver le soldat %. Évalué à 1.
Je n'imprime pas en couleur mes listings.
Il m'arrive d'édité à distance avec vi sans couleur.
Je n'aime pas que les règles de programmation dépendent de la couleur des choses. Un bon exempe d'un langage que j'aime beaucoup mais dont le créateur génial (Chuck Moore) a été, à mon sens, trop loin est colorForth.
http://en.wikipedia.org/wiki/ColorForth
http://www.colorforth.com/
[^] # Re: Une pétition ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Il faut sauver le soldat %. Évalué à 3.
Cela, c'est une connerie.
Je trouve que le $ devant les variables en bash, en perl génial. C'est d'une clarté limpide. En plus, en perl, il y en a toujours (même à l'affectation). Il n'y a aucune confusion avec les mots clef du langage.
L'horreur, c'est le CSH qui est tordu sur l'usage du $.
OK, perl a des problèmes de lisibilité mais ce n'est pas à cause du $ devant les variables.
En fortran 90, j'avais la convention suivante, tous les mots clef du langage en petit caractère et toutes les variables en majuscules. Le code était limpide.
Faire resortir les mots clefs du langage par rapport aux variables, ou inversement, est un excelente idée,
[^] # Re: C Uber Alles
Posté par Sytoka Modon (site web personnel) . En réponse au journal Il faut sauver le soldat %. Évalué à 3.
.operateur.
C'est très pratique. J'ai deux vecteurs, je veux le produit scalaire
v1 .scalar. v2
J'ai deux tenseurs, je veux aussi le produit scalaire
t1 .scalar. t2
Je me suis battu avec des thésards pour avoir cet opérateur .scalar. et non pas * comme beaucoup pense. *, c'est l'opérateur produit, mais produit de quoi : scalaire, vectoriel... Avec l'opérateur *, on ne sais jamais le type du résultat de l'opération et les formlules mathématiques deviennent imbittables.
En C ou en C++, on ne peut pas faire cela et c'est bien dommage, les formules de math sotn bien moins claires et du coup le risque d'erreur est plus important.
Si on souhaite un langage qui puisse faire "des math", il est important de laisser libre champs aux opérateurs et ne pas se cantonner aux seules méthodes. Les méthodes cassent la symétrie et ne reflète pas la formule
v1.scalar(v2)
est très différent de
v1 .scalar. v2
Dans le second cas, on a bien un produit scalaire entre deux vecteurs, ces deux vecteurs étant au même niveau.
Je crois que c'est une des raisons pour lesquelles perl6 ne sera pas pure objet et que les concepteurs veulent garder l'aspect multi-fonctions.
En dehors des math, je n'ai pas d'opinion et je ne sais pas si cela est aussi important.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 7.
La faille debian n'est plus dans le serveur debian, elle a été corrigé du jour ou elle a été annoncé. Je pense qu'il n'y a plus beaucoup de serveur pourris qui tournent.
Mais des clefs... combien en reste-t-il qui trainent sur le net ?
Les seuls serveurs protégés sont justement ceux de debian. Quelle ironie !
Ton serveur sous OpenBSD, si un de tes utilisateurs a une clef debian de l'époque ne vaut plus rien, c'est une passoire... Mes serveurs debian ne risquent plus rien !
La faille debian est finalement assez proche de la faille DNS, elle touche tous les serveurs non paché qui ne sont pas capable de blacklister (révoquer) de mauvaise clef. Les clefs SSH n'ayant pas de date limite, la faille peut durer très très longtemps.
C'est pour cela qu'il faut patché tous les serveurs SSH, qu'ils soient debian ou non. Car le protocole SSH a oublié qu'il pouvait y avoir des clefs pourris. C'est une sorte de faille cela. Et les clefs n'ont pas de date limite, c'est encore une espèce de faille...
Avec SSL et les certificats X509, ce cas a été prévu avec les listes de révocation très mal implantés par les clients -> faille des clients.
SSH n'a aucune protection contre cela. Faille du serveur ou du protocole ?
J'ai presque envie de dire, cela aurait du arrivé un jour. C'est debian qui a fait la faute mais ce n'est pas normal que SSH soit aussi sensible a un bogue pareil. Un mec distribue des millions de clefs pourris dans la nature et tu n'as au niveau de ton serveur sous OpenBSD (ou autre) aucun moyen de lutter contre ses clefs si un de tes utilisateurs en a une ?
Si ce n'est pas une faille dans le protocole, c'est quoi ?
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 3.
Moi, si Red-Hat avait fait la même bévue, je serais super content que debian intègre le patch Red-Hat qui me mette à l'abris. Un des points faibles des PKI (et des certificats X509) est la bonne (ou mauvaise) gestion des listes de révocation, notament par TOUS les clients potentiels ! Le système des blacklists mis en place par debian pour OpenSSH, c'est un peu le même esprit. Je regarde à chaque nouvelle version d'OpenSSH mais je suis surpris que ce path ne remonte pas.
Sinon, j'ai comme l'impression que certain se frotte les mains de la bavure debian comme s'ils étaient content que debian se soit lamentablement planté. A vrai dire, je trouve cela désolant mais bon, a chacun ses petits plaisirs.
Allez, pour le plaisir, une dernière petite tirade...
Un autre gros bogue en 2008 a été la faille dans le protocole DNS : "DNS Cache Poisoning Issue". Je suis allé voir du coté d'ISC avec Bind. Leur site en parle
https://www.isc.org/node/387
D'ailleurs, le message commence par des remerciements.
Certe, le bogue n'est pas du même type (même origine) mais il touche tous les serveurs de noms et l'ISC ne le cache pas, il est même bien en évidence sur leur site bien que ni l'ISC ni Bind n'ont le moindre tord dans l'affaire.
Encore une fois, le bogue debian touche TOUS les serveurs SSH ! Même les autres serveurs qu'OpenSSH !
# Change de station
Posté par Sytoka Modon (site web personnel) . En réponse au journal [HS]Location: L'abus de caution nuit aux clients. Évalué à 7.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
Tu oublies complètement le rôle de publicité, de la diffusion. Si Firefox vit si bien aujourd'hui, c'est que la fondation mozilla a fait un énorme boulot de publicité.
Le fait de distribuer un logiciel, d'en assurer la maintenace sécurité (même si dans le cas présent, il y a eu une bévue), le fait de le proposer aux administrateurs et aux utilisateurs pour une utilisation quotidienne, pour moi, cela fait aussi partie de la vie d'un projet.
Donc, pour moi, les distributions ne font pas que "packager", par la même une relation se forme avec le développement amont et elles participent ainsi fortement à la vie des projets. Tu oublies aussi que debian supporte un grand nombre d'architecture et que ce simple fait permet de remonter plein de problème dans énormément de programme. On ne parle pas ici d'une petite distribution faite dans son coin. Debian est un énorme projet communautaire libre qui a un impact non négligeable, même si toi, tu as l'impression de n'en rien utiliser.
Un autre exemple, GNOME a été fortement aidé par les distributions au début car KDE n'étais pas packager dans bien des distributions, dont debian. Je ne suis pas sur qu'on aurait un GNOME aujourd'hui si Qt avait été dès le début libre.
Idem pour les programmes Java, je suis persuadé que le fait d'avoir du java propre dans les distributions va enfin booster tous les programmes java libre.
Encore une fois, nous n'avons pas le même sens de la communauté, de la solidarité, des remerciements... J'ai bien fait d'arrêter de te répondre hier soir.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
> qu'empaqueter la version portable d'OpenSSH.
Tu sous estimes le boulot des distributions. Sans elles, OpenSSH est mort, au moins virtuellement.
Imagines un instant un autre programme qui remplace OpenSSH et que les distributions majeures n'installent plus OpenSSH ? Crois-tu alors qu'OpenSSH vit encore ? Non, du jour ou il y aura un remplaçant à OpenSSH sous les distributions Linux, de ce jour là, il sera mort.
Un exemple historique. Le programme xv est sortis des distributions il y a une dizaine d'année et pourtant on l'utilisais tous avant. Qui connait xv de nos jours à par les anciens croutons comme moi !
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 2.
Je met ma clef réalisé sur un serveur debian sur une machine de l'IDRIS et je me connecte dessus... La machine de l'IDRIS est une IBM sous AIX... (Tu remplace IDRIS, IBM et AIX par ce que tu veux)
Bilan : n'importe quel petit malin rentre dans le système IBM qui n'a rien a voir avec debian !
La faille debian touche TOUS les serveurs SSH, même ceux qui n'ont rien a voir avec debian. Debian peut communiquer et l'a fait. Je ne vois pas en quoi il aurait été mal qu'OpenSSH commnunique la dessus. Même les machines sous OpenBSD sont touchés.
Vous pensez peut être que n'utilisant pas debian, vous êtes à l'abris du problème. mais ce n'est pas vrai. Qui vous dis qu'un utilisateur de vos systèmes n'a pas mis une clef foireuse sur vos systèmes ? Et vous la détectée comment la clef foireuse ?
C'est le principe même d'OpenSSH avec ses clefs qui a été mis a mal. La solidarité veut que tout le monde donne un coup de main pour éradiquer le problème le plus vite possible.
Une petite phrase, un lien... Ca leur aurait couté quoi à l'équipe d'OpenSSH ?
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 3.
Assez trollé avec toi, je sais que cela ne mène nulle pars, je préfère aller voir ma sirène bien au chaud ;-)
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
La, la mise a jour n'a pas mis à jour tes clefs... Il y a eu un boulot de fou pour refaire les clefs, les revalider, voire que plein de script ne marchait plus... J'ai même lu l'histoire d'une personne qui a perdus la main sur son cluster de 200 machines, et je pense que ce n'est pas le seul !
Ton trous de sécu dans le noyau Linux, tout le monde s'en fout entre () et cela n'a pas du tout les mêmes conséquences.
Moi je te dis que dans 10 ans, on ne retiendra que "le bogue debian dans Openssh" et rien de la routine que tu évoques dans ton post et que je recois tous les jours dans ma boite mail avec les alertes du CERT.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 2.
Le bogue est dans OpenSSL mais c'est surtout OpenSSH qui a été touché sur une partie des distributions Linux (debian et dérivée).
Quand tu as un programme sensible et réputé pour sa sécurité et qu'un de tes composants est pourris, je suis très géné qu'on ne m'en parle pas. Surtout lorsque le bogue touche principalement ton programme en particulier...
Lors du problème, ma première réacton a été d'aller voir sur le site
openssh.org
pour avoir des informations clefs, pour avoir le point de vu de l'équipe d'OpenSSH sur le bogue et la solution apporté par debian. Rien, rien, rien...
Manifestement, ce silence de l'équipe d'OpenSSH face à ce bogue UNIQUE, me met mal à l'aise mais ne vous pertube pas le moins du monde. Désolé, je dois être trop émotif.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
- Oui c'est une erreur debian et non de l'équipe d'OpenSSH. Personne n'a dis que c'était une erreur d'OpenSSH
- Oui, c'est un bogue introduit dans OpenSSL qui a surtout touché OpenSSH (mais pas seulement, aussi les clefs réalisés pour des sites en https, aussi pour cfengine...)
Cependant, le programme le plus touché et le plus sensible a été ssh !
Ce n'est pas un petit bogue, c'est quelque chose d'exceptionnel qui n'arrive on l'espère qu'une fois par décennie. C'est un des évênements majeur de 2008, peut être une des rares choses qu'on se souviendra dans 10 ans : le bogue debian dans OpenSSH (même si c'est dans OpenSSL).
Moi, si je fais un programme a ce point sensible et une distribution majeure me fait un bogue pareil qui touche autant de gens, et bien je pense que la moindre des choses que je ferais serait d'en parler clairement et de dire que le problème est résolu et comment.
Ne pas mettre cette information, faire comme si elle n'a pas exister, même si l'équipe d'OpenSSH n'a rien a se reprocher, cela me parait grave d'un point de vu communication. En tout cas, a moi, cela ne me viendrait pas à l'idée d'ignorer une telle bavure.
OpenSSH vit aussi grace aux distributions GNU/Linux. Demander des remerciements et des dons, c'est bien. Mais il faut aussi renvoyer l'ascensseur. Les distributions aident aussi à diffuser et elle font globalement du super boulot, même si elles sont à base Linux et non de BSD. En plus debian est la seule distribution Linux (à ma connaissance) a vouloir faire un port BSD...
Alors, participer à l'information d'une telle bavue pour éviter que des milliers de gens ne se fassent pirater par ssh, cela me semble faire partie intégrante de l'esprit communautaire libre. Ou est la solidarité, ou est l'entraide ici ?
Pour moi, cette ignorance de la part d'OpenSSH me donne une impression de mépris envers debian et par la même envers toutes les distributions Linux.
Encore une fois, on ne parle pas d'un non évênement car je fais le pari que ce sera l'évênement top 1 de l'année 2008 plus tard. Ce sera même un cas d'école très certainement cité dans plein de cursus universitaire...
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 3.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
Avec le système que Sarko nous met en place (autonomie des universités), une partie des salaires va finir par être payés par les sommes percues a ce titre...
Puisque je suis dans ce sujet, je viens d'apprendre que les présidents d'université pourraient toucher une prime de plus de 20kE ! Notre ministre voudrait aussi englober les vice-président... Tout ceci va nous mettre le système du pognon du privé dans le public et me semble plus que malsain. Pour ceux qui pensent que 20kE, c'est peu de chose, un président touche normalement entre 2500 et 4500E par mois comme salaire.
[^] # Re: Les entreprises payent ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 0.
> dessus à plein temps. C'est peut-être lié au manque d'utilisateurs, mais OpenBSD, c'est
> OpenSSH qui est très critique dans énormément d'entreprises
Justement, le problème n'est-il pas là.
Je m'explique après avoir fait un tour sur le site d'OpenSSH. OpenSSH est très lié, peu être trop lié a OpenBSD.
Pourquoi une boite va t'elle faire un don a OpenBSD alors qu'elle ne l'utilise pas et que ce n'est pas dans ses projets. Personnellement, je me suis posé la question mais a ce moment, il était hors de question d'avoir un port Xen d'OpenBSD.
Or, sur le site d'OpenSSH, il est bien spécifié que les dons doivent être donné a OpenBSD et que tout est mélangé car le développement est fait par la même équipe. Je cite
"
Donations are handled via OpenBSD, since OpenBSD is the environment and community where OpenSSH is developed
"
Pas étonnant alors que peu de monde développe OpenSSH si c'est a ces conditions...
Bref, j'adore OpenSSH que j'utilise tous les jours mais je ne suis pas spécialement intéressé par OpenBSD ni les déclarations de son leader.
Qui ne se souvient de la faille introduite par debian l'an passé... et du patch debian avec le blacklisting de clef. une fonctionalité que debian a rajouté. On aime ou on n'aime pas mais debian a proposé une solution au mal qu'elle a fait. Et bien, avec une petite recherche sous Google chez nos amis d'OpenSSH sur le sujet avec tout simplement
debian site:openssh.org
Le résultat est rien sur ce sujet. Rien, rien, rien....
Une faille énorme dans OpenSSH qui a touché des milliers de machines de plusieurs distributions Linux et rien, rien, rien sur leur site /a priori/.
Ben moi, je me dis que le développement d'OpenSSH n'est pas bien communautaire et beaucoup trop lié a celui d'OpenBSD.
Du coup, je donne de argent a d'autre projet libre ... ma bourse n'est pas non plus infini.
[^] # Re: ROhhhhhhh
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GNU Bash 4.0. Évalué à 3.
Enfin, c'est un peu fou ce que l'on trouve dans les clefs de registre 'ajout suppression de programme' sur .NET. Entre tes explications limpides et ses clefs, il y a un monde... Peut être faudrait-il que Microsoft embauches des linguistes pour nommer leur objet ;-)
[^] # Re: Critique = faut que ça marche sans bug et tout le temps
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Thales met à disposition un framework à composants logiciels visant les systèmes critiques. Évalué à 3.
> un serveur MS
Je sais bien mais avec debian, sans faire de mirroir, debian ne me pompe aucune info, Microsoft non. Combien de PME ont leur propre WSUS ?
> Il y a Microsoft Update si tu aimes rester a travers le web (je ne vois aucune raison d'utiliser
> Windows Update ou Microsoft Update) qui fait les 2
Oui, j'aime faire un update via le web pour avoir un controle visuel. J'ai vu trop de poste que l'on croit à jour et qui ne le sont pas.
En plus, avec un contrôle visuel, on peut éventuellement rajouté des paquets.
Sinon, pour ton information, Microsoft Update ne prend pas en charge Office 2000, mais le site Office Update oui. Je ne parle dans mon post que de celui-la, pour les autres versions d'Office, je sais très bien que cela marche. Pour ton information, je gère un parc qui a plus que 10 machines Windows...
En plus, Windows update veut toujours me vendre sa sauce, par exemple Silversight dont je n'ai que faire mais n'est pas capable de me dire ce qui est obsolète et qui ne sers à rien (.Net version 1 peut être, quand sais-je ?).
> Depuis quand est-ce qu'il faut reformater un Windows pour le passer a la version suivante ?
> Ils supportent tous les upgrades sans probleme.
Tu répond à coté de la question. Je parle d'un upgrade d'un coup et d'un seul reboot (et en plus, tout en réseau).
> Niveau qualite des mises a jour permet moi d'etre d'un avis totalement contraire. Regardons
Mauvais interprétation de ma phrase qui pouvait effectivement porter à confusion. Justement, je ne voulais pas rentrer dans le débat de la qualité des patch... Je voulais juste parler de l'outil.
Enfin, tu me parles de GPO pour déployer des patch et que tout le monde fait cela. Pourquoi Microsoft n'utilise pas les GPO pour ses propres mises à jour, pourquoi deux systèmes... Et puis, si tu n'as pas d'AD, tu fais comment ? Et puis chez moi, le partage réseau n'est pas installé et l'expérience me montre que j'ai bien moins de soucis que mes voisins... Bref, a trop centraliser, on rigidifie, on balance tout sur le port 445... Moi, j'aime bien l'esprit UNIX ou on essaye de faire des concepts orthogonaux.
Je conçois bien que je n'ai aucune influence sur la politique de Microsoft mais je me donne le droit de ne pas la partager.
Oui, le système apt-get + les paquetages .deb (idem avec yum + rpm) est bien plus puissant a mon sens. Tant l'OS que tout les autres logiciels passe dans le même système.
[^] # Re: Est-ce que je dois rire
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Thales met à disposition un framework à composants logiciels visant les systèmes critiques. Évalué à 2.
> "sucks" :-)
Pas si sur... Je ne suis pas sur qu'il existe un seul OS de nos jours qui n'ai pas du code open-source libre dedans.
Donc, même chez Microsoft, ils connaissent la valeur du logiciel libre. Après, le troll est toujours possible ;-)
[^] # Re: ROhhhhhhh
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GNU Bash 4.0. Évalué à 3.
Désolé mais ta phrase doit avoir un mot en moins. Je ne comprends pas le sens.
Alors, OK, .NET 3.5 et .NET 3.0, c'est la même chose.
Il n'empêche, j'ai des machines avec trois version de .NET alors que je n'ai jamais eu de version d'UNIX avec deux version de Perl.
Certes, Perl6 sera sur ma machine en parallèle de Perl5 mais Perl6 est un autre langage et la communauté ne s'amuse pas tout les 4 matins a changer l'API.
Enfin, j'ai donc 3 machines .NET sur une partie de mes machines et je n'ai de la part de Windows aucune indication pour savoir si oui ou non je peux les enlever. Aucune gestion des dépendances et ainsi de suite.
Donc oui je suis nul et je l'assume mais le parc que je gère fonctionne depuis des années sans grave panne... et madame michu chez elle, il m'étonnerais qu'elle se débrouille mieux que moi ;-)
[^] # Re: ROhhhhhhh
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de GNU Bash 4.0. Évalué à 6.
En pratique, chaque mise a jour de java n'enlèva pas la précédente version de java sous Windows.
Mes postes sous Windows XP Pro ont si mes souvenirs sont bons :
.Net 1
.Net 2
.Net 3
.Net 3.5
C'est sur qu'avec quatre version, on peut faire des choses portables... et je ne sais même si je peux enlever une version sans tout casser.
J'ai des scripts perl qui ont dix ans et qui marche toujours sur la dernière version de Perl... Je n'ai jamais mis plus d'un interpréteur Perl sur une machine.