J'ai fait de l'ADA avec GNAT, donc ce n'est pas pour moi un langage, ni un compilateur inconnu.
Je t'ai proposé OCAML ou Lisaac parce que souvent les informaticiens 'universitaire' aime bien OCaml et Lisaac, c'est un peu la mascotte de Linuxfr ;-) Mais personnellement, j'ai rien fait en OCaml car a l'époque, il gèrait super mal le multi-treaded. Et pour moi, un langage doit aujourd'hui être parallèlisable facilement ou alors, autant utiliser un langage de script.
Dans mon unité de recherche, on développe quasiment qu'en Fortran et je pense que c'est le meilleur choix pour notre thématique de recherche. Le C, le C+=, le java ont fait des percées mais les thésards s'en sortent bien mieux en Fortran et Fortran est bien plus portable et parallèlisable facilement que JAVA !
J'ai un chercheur dont le code Fortran 'scale' bien sur 10000 coeurs par exemple. C'était pas gagné avant de faire l'essais.
Donc, tu utilises le langage que tu veux. Je te conseille juste de ne pas te fixer trop vite sur un langage. Parfois, on a des bonnes surprises avec les vieux crus qui viellissent plutôt bien.
Sinon, cela ton application, j'irais voir du coté d'Erlang car cela rajeunie de voir un code Erlang ! C'est bien sur pas pour les mêmes besoins...
Tout a fait d'accord. Lorsque je développais mes propres environnement Perl pour Apache, tout mes scripts perl était en .html
J'avoue que je trouve idiot de donner le nom du langage dans lequel on développe et de dire que la page est dynamique. C'est un problème interne du serveur et dont le client se fiche éperduement.
- le nombre de coeur par OS (toutes les gros centre de calcul bascule sous Linux petit à petit)
- la quantité de RAM par OS
- le nombre de machine virtuelle par OS
- le nombre de Linux embarqué jamais compté ! Pour une machine familial, il y a quasiment un Linux pour les personnes sous ADSL rapide ! Combien de petit NAS tournent sous Linux et ne vont jamais sur le net ?
- ...
Les indicateurs sont basés sur de la navigation web. Sur le parc que je gère, Windows est sous la barre des 50% et pourtant, je suis sur qu'avec ce genre d'indicateur, il est au dessus de 60% !
Ces indicateurs donnent par exemple MAC devant Linux or Linux est devant MAC grace a tous ces systèmes embarqués (a mon avis, mais je n'ai fait aucun calcul).
Bref, Linux est déjà partout, même chez madame michu. Il est effectivement fort possible qu'on assiste un jour au même phénomène que le retour de Firefox sur le devant de la scène, pour la partie comptage web.
Mais quelques essais avec une SLES ne me plaisent pas du tout. Il n'y a rien. Dès que je cherche un paquet, il n'est pas dans la distribution... Un des trucs qui me vient en tête est d'avoir subversion avec le support https. Mais je n'ai pas trouvé iconv... Ce système m'horripille. Je suis certainement manchot de SLES mais effectivement, avec le peu de paquet et le peu d'architecture, c'est plus facile de supporter 7 ans.
Pour debian, savoir qu'il supporte bien plus d'architecture, que c'est un projet qui fonctionne sur le bénévola et les dons ET que les paquets n'évolue pas, contrairement a ce que j'ai cru comprendre chez red-Hat et Suse. Un paquet en version 2.1.7 est encore en fin de vie à la version 2.1.7. J'ai compris que Red-Hat faisait tomber des versions nouvelles des paquets de temps en temps, un peu comme les backports de debian. A mon sens, c'est plus facile de faire un support long avec cette stratégie.
Pour finir, je ne suis pas spécialiste de red-hat et Suse, donc j'ai peut être tout faux !
Je suis d'accord. Je me force en ce moment sur ma lenny perso d'utiliser le bureau gnome standard pour faire comme mes utilisateurs de bureau et c'est une horreur.
- Mode click to focus hyper chiant
- Agrandir la fenêtre pour un terminal agrandi la fenêtre a tout l'écran et non un agrandissement vertical
-...
Il y a plus de 10 ans avec fvwm2, j'étais plus fonctionnel mais moins style WindowsXP.
La seule méthode efficasse est d'avoir les fenêtres en plein écran et la, autant avoir un MAC avec les menus des applications sur la barre du haut.
Par contre, l'utilisateur lambda qui n'a jamais fait de Linux, cela lui plait. Les 3/4 des applications n'apparaissent plus dans les menus et il fonctionne en mono-application. J'exagère à peine.
Heureusement, il y a d'autres bureau que les leaders. Par contre, on risque de ne moins voir d'application couçu pour le FollowMouse comme Gimp.
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.
[^] # Re: réponse
Posté par Sytoka Modon (site web personnel) . En réponse au message Ada -> GNUstep. Évalué à 5.
Je t'ai proposé OCAML ou Lisaac parce que souvent les informaticiens 'universitaire' aime bien OCaml et Lisaac, c'est un peu la mascotte de Linuxfr ;-) Mais personnellement, j'ai rien fait en OCaml car a l'époque, il gèrait super mal le multi-treaded. Et pour moi, un langage doit aujourd'hui être parallèlisable facilement ou alors, autant utiliser un langage de script.
Dans mon unité de recherche, on développe quasiment qu'en Fortran et je pense que c'est le meilleur choix pour notre thématique de recherche. Le C, le C+=, le java ont fait des percées mais les thésards s'en sortent bien mieux en Fortran et Fortran est bien plus portable et parallèlisable facilement que JAVA !
J'ai un chercheur dont le code Fortran 'scale' bien sur 10000 coeurs par exemple. C'était pas gagné avant de faire l'essais.
Donc, tu utilises le langage que tu veux. Je te conseille juste de ne pas te fixer trop vite sur un langage. Parfois, on a des bonnes surprises avec les vieux crus qui viellissent plutôt bien.
Sinon, cela ton application, j'irais voir du coté d'Erlang car cela rajeunie de voir un code Erlang ! C'est bien sur pas pour les mêmes besoins...
[^] # Re: et sinon ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Un module apache pour programmer des applis web en C++. Évalué à 2.
J'avoue que je trouve idiot de donner le nom du langage dans lequel on développe et de dire que la page est dynamique. C'est un problème interne du serveur et dont le client se fiche éperduement.
# Indicateur intéressant
Posté par Sytoka Modon (site web personnel) . En réponse au journal Progression de Linux. Évalué à 3.
- le nombre de coeur par OS (toutes les gros centre de calcul bascule sous Linux petit à petit)
- la quantité de RAM par OS
- le nombre de machine virtuelle par OS
- le nombre de Linux embarqué jamais compté ! Pour une machine familial, il y a quasiment un Linux pour les personnes sous ADSL rapide ! Combien de petit NAS tournent sous Linux et ne vont jamais sur le net ?
- ...
Les indicateurs sont basés sur de la navigation web. Sur le parc que je gère, Windows est sous la barre des 50% et pourtant, je suis sur qu'avec ce genre d'indicateur, il est au dessus de 60% !
Ces indicateurs donnent par exemple MAC devant Linux or Linux est devant MAC grace a tous ces systèmes embarqués (a mon avis, mais je n'ai fait aucun calcul).
Bref, Linux est déjà partout, même chez madame michu. Il est effectivement fort possible qu'on assiste un jour au même phénomène que le retour de Firefox sur le devant de la scène, pour la partie comptage web.
[^] # Re: Une progression qui se confirme
Posté par Sytoka Modon (site web personnel) . En réponse au journal Progression de Linux. Évalué à 2.
Pour debian, savoir qu'il supporte bien plus d'architecture, que c'est un projet qui fonctionne sur le bénévola et les dons ET que les paquets n'évolue pas, contrairement a ce que j'ai cru comprendre chez red-Hat et Suse. Un paquet en version 2.1.7 est encore en fin de vie à la version 2.1.7. J'ai compris que Red-Hat faisait tomber des versions nouvelles des paquets de temps en temps, un peu comme les backports de debian. A mon sens, c'est plus facile de faire un support long avec cette stratégie.
Pour finir, je ne suis pas spécialiste de red-hat et Suse, donc j'ai peut être tout faux !
[^] # Re: Une progression qui se confirme
Posté par Sytoka Modon (site web personnel) . En réponse au journal Progression de Linux. Évalué à 1.
- Mode click to focus hyper chiant
- Agrandir la fenêtre pour un terminal agrandi la fenêtre a tout l'écran et non un agrandissement vertical
-...
Il y a plus de 10 ans avec fvwm2, j'étais plus fonctionnel mais moins style WindowsXP.
La seule méthode efficasse est d'avoir les fenêtres en plein écran et la, autant avoir un MAC avec les menus des applications sur la barre du haut.
Par contre, l'utilisateur lambda qui n'a jamais fait de Linux, cela lui plait. Les 3/4 des applications n'apparaissent plus dans les menus et il fonctionne en mono-application. J'exagère à peine.
Heureusement, il y a d'autres bureau que les leaders. Par contre, on risque de ne moins voir d'application couçu pour le FollowMouse comme Gimp.
[^] # Re: réponse
Posté par Sytoka Modon (site web personnel) . En réponse au message Ada -> GNUstep. Évalué à 4.
GNUStep est en ObjectiveC ;-)
Ada, c'est très bien mais question performance, le compilateur GNU n'est pas en tête. Va plutot voir du coté de OCaml ou même Lisacc !
# 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.