UNIX(TM) c'est supra vieux qui l'utilise encore
Ne fait pas l'idiot, tu as très bien compris que je parlais des différentes implémentation de Unix (en particulier Linux ou les *BSD)
le buffer overflow n'est pas un concept provenant d'UNIX, c'est un concept générique.
Non mais c'est sous UNIX que les gens ont appris à les exploiter (le premier buffer overflow de l'histoire c'était dans le ver d'internet 89) bien avant l'existence de NT
Trouver un IIS vulnérable est encore bien plus simple.
Pas forcément si simple, avec les vers et compagnie qui peuvent scanner Internet de façon exhaustive, la quasi-totalité des machines vunérables ont déja été exploitée au moins une fois et avec les patchs "tout-en-un" de MS un admin qui met-à-jour contre code Red corrige aussi toutes les autres failles en même temps.
Donc aujourd'hui 90% des IIS sont à jour, je ne suis pas sûr que 90% des vielles RedHat 6.2 qui trainent dans les entreprises soient patchées contre le "rpc.statd" ("remote root" pourtant).
La preuve : 6 mois avant CodeRED, beaucoup de ver Linux (Ex : LionWorm) sont sortis, ils auraient surement connus eux-aussi le succès si le nombre de machine sous RedHat était voisin du nombre de machines NT/IIS.
ligne de commande, celle ci a toujours existé sous Windows.
Je ne vois pas ce qu'un cracker pourrait faire d'une ligne de commande Windows ?
Peut-il compiler ses outils/exploits ? Installer une backdoor qui ouvre un port vers la ligne de commande Dos ?
Le plus rigolo, c'est que dans Windows, on trouve des cheat codes qui court-circuitent la
sécurité.
Rien compris
Je vois ce qui vous permet d'associer le concept de patch à Microsoft.
1) patch est un mot qui appartient à la terminologie Unix (MS parle de Hotfix)
2) les buffer overflows et autres failles étaient déjà légions sous Unix avant que les problèmes ne soient connu sous NT (d'ou l'emploi courant d'un mot d'origine UNIX pour désigner le problème sous Windows)
3) Je me souviens d'une section du site "PacketStorm" intitulée "les 1500 exploits les plus connus sous Unix".
Donc dire qu'il y a plus de buffer overflow sous NT que sous Unix est une affirmation gratuite
En bref, UNIX avait plutôt une réputation de système ciblé par les "cracker".
Pendant longtemps, les gens se sont demandés s'il était possible de transposer ce "savoir" vers NT.
- L'absence d'interface en ligne de commande (et de port telnet/SSH) rendait difficile la manipulation à distance d'une machine compromise par le "cracker".
- il existe depuis longtemps de nombreux rootkits pour Unix, mais l'absence des sources rends beaucoup plus difficile l'élaboration de tels outils pour Windows (même si quelques tentatives ont été faite avec SoftIce comme debugger)
Donc, il me semble que Windows soit surtout utilisé pour la propagation de ver mais qu'un "cracker" désireux de se procurer une nouvelle "box" lui préférait une install par défaut d'une RedHat 6.2, à mon humble avis ?
Mais bon lorsque'Eiffel (un bon exemple de langage OO soit dit en passant) propose "l'optimisation" du code, il ne fait que le transcrire en C
Je ne pense que la génération de code C soit lié à une "optimisation" comme tu le dis, mais simplement au fait que le C est portable.
De cette façon on laisse le compilateur Eiffel se concentrer sur des optimisations de haut-niveau (celles spécifiques au langage Eiffel) alors que le compilateur C s'occupe des optimisations de bas niveau (celle relative à une architecture cible comme par exemple la pénurie de registre sur x86).
L'inconvénient est que l'on perd en qualité du code généré : puisque les deux compilateurs ne peuvent "communiquer" cela nous prive de certaines optimisations.
Mais Eiffel étant un projet universitaire, pense tu que l'équipe qui travaille dessus dispose des fonds nécessaire pour écrire le million de ligne de code supplémentaire qui permettrait de se passer de l'étape C ?
Le C++ a subit le même chemin, son premier compilateur (cfront) générait du code C, alors que tout les compilateurs industriels actuels (Sun pro CC, Visual C++, g++, ..) générent directement de l'assembleur.
Si Eiffel n'a pas cette chance c'est simplement parce que ce langage n'est pas assez populaire.
En tout cas merci de me traiter d'autiste en passant, mais le jour où ton OS et toutes les applis tournent en Java, soit tu dis adieu à la vitesse soit adieu à la couche d'ozone
Le seul avantage d'un langage de bas-niveau comme le C (ou l'assembleur) sur C++, c'est une plus faible consommation de ressource (mémoire) pas une meilleure rapidité.
Dans l'industrie le C (et l'ASM) est toujours utilisé dans le domaine de l'embarqué pour cette raison.
Un noyau peut-être considére comme un programme temps réel d'où la nécessité du C (et puis la plus faible consommation mémoire importe ici)
Quand à Java c'est vrai que la portabilité à forcément une contrepartie en terme de performance. Et puis le code Java est souvent plus lisible donc plus maintenable.
Les langages de bas niveau sont AMHA plus intéressants intellectuellement pour connaître sa machine
On peut programmer en langage de haut-niveau tout en connaissant d'autres langages de bas niveau (perso j'ai fait de l'assembleur Intel avant même si maintenant j'utilise surtout C++)
Je crois qu'il est beaucoup plus dur de maîtriser en langage bas niveau qu'un langage haut niveau
Pourtant la majorité des programmeurs C++ ont fait un ou deux ans de "C pur" avant, donc qui peut le plus peut le moins !
Pour avoir utilisé les deux langages, j'ai l'impression qu'il y a plus de subtilité dans C++ (par exemple connait-tu la différence entre un "static_cast", un "const_cast", un "dynamic_cast" et un "reinterpret_cast" ?) que dans C.
voter Mr. Chirac, au risque de vous sentir pas super bien dans vos pompes au moment de mettre l'enveloppe dans l'urne...
Il ne parait pas forcément évident à tout le monde que voter pour un autre parti politique que le PS soit de nature à "se rendre malade".
(Hors sujet)
Je crois en effet que tes convictions politiques n'ont rien à faire ici !
Est-ce qu'ils contribuent en retour au logiciel ?
Non, ils n'ont pas d'intérêt économique à le faire.
Si ils ont choisi Nessus, c'est pour faire des économies au niveau du développement, donc ils ne développent rien du tout (si ce n'est l'interface) et concentrent toutes leurs ressources sur le marketing.
De plus, si ils développaient quelque chose ça serait quand même idiot de leur part d'en faire cadeau à leurs concurrents.
Ce qui est plus embétant, c'est que :
a) certains d'entre-eux pour des raisons marketing vont prétendre avoir développé un scanner proprio
b) La GPL les contraints à redistribuer le source seulement si ils distribuent le binaire.
En mode ASP (application hébergée accessible via une plateforme internet), le client n'a pas accès au binaire donc ils n'ont pas l'obligation de redestribuer le source voir d'avouer utiliser Nessus.
je vois utiliser gcc sous Linux en TP et bosser sur Visual C++
C'est surement l'IDE de Visual qui les intéresse plus que le compilo, qui pour un petit prog de TP ou les bugs de compilo n'apparaissent pas, se valent tous.
nombre de gens sont victimes du "syndrome de l'inertie au changement"
C'est pas de l'inertie au changement puisque tu dis qu'ils l'utilisent gcc (éventuellement contre leur gré) en TP. Donc si quand on leur laisse le choix (chez eux), ils font l'effort de changer c'est que le nouvel IDE convient mieux à leur besoins.
Et si ils sont aussi nombreux que tu nous le dis à trouver que Visual réponds mieux à leur besoin que l'IDE qu'ils utilisent en TP, on peut donc en déduire que Visual est globalement un bon produit qui réponds assez bien aux attentes de la grande majorités des utilisateurs de ce type de produit.
Les arguments d'ouverture, liberté, etc sont difficiles à faire passer
Tout dépends ce que tu veux faire avec le soft, si tu veux l'utiliser comme un développeur avoir le source est utile, pour un utilisateur tu t'en fous.
Ce n'est pas parce qu'il existe Doom sous licence libre, que les ventes de Quake 3 vont s'effondrer du jour au lendemain. Car, pour la plupart des gens c'est la qualité du logiciel qui prime, et celle-ci est bien meilleure avec Quake 3 bien qu'il ne soit pas libre. Car, même si tu aime développer (comme moi), il faut plusieurs mois d'acclimatation avant de contribuer sur un source et il n'est pas réaliste de contribuer à plus d'un ou deux projets à la fois.
En résumé tu repproche a tes compères de TP d'en avoir rien à faire de la philosophie Open-Source.
Et alors ! Des gens comme Richard Stallman qui sont motivés par des considérations philosophiques représentent une infime minoritée y compris au sein de la communauté des développeurs Linux. La majorité (cf sondage sur les développeurs du kernel) sont plutôt des gens comme Linus, qui développent pour s'amuser, se fichent complétement de la philosophie Open-source (hormis le fait qu'ils ne veulent que d'autre s'enrichissent sur leur dos avec leur travail), utilisent des softs proprio (comme BitKeeper) quand ils les trouvent mieux adaptés à leur besoins, ... bref des gens qui n'hésiterais pas une seul seconde à adopter VC++ si ils le trouvaient pratique
ceux qui osent dire que SVG ne marchera jamais parce que Flash ou je ne sais quoi d'autre a pris de l'avance,
J'espère que tu ne dis pas vrai car j'aime bien SVG
ce sont ceux qui disaient que Mozilla n'arriverait jamais à rien parce que IE avait trop d'avance...
hou la, tu m'inquiéte la
au hasard, je dirais que les IDS Open Source vont réagir beaucoup plus vite que leurs "concurrents" commerciaux...
Objectivement, je ne pense que pas que les softs Open-Source soit forcément à l'abris de ce genre de comportement càd cacher des failles ou prendre son temps pour corriger les bugs.
Ainsi, dans la réponse du développeur de Snort il explique qu'on lui avait envoyé la faille depuis plusieurs mois, mais qu'il ne s'étais pas pressé pour commiter le fix dans le CVS car il pensait qu'il ne serait dévoiler qu'à la prochaine conférence de sécu.
Sauf erreur de ma part, lors du bug d'openSSH, le bug à été fixé <i>en douce<i> dans le CVS longtemps avant que la faille ne soit annoncée.
Enfin, lorsque je lisais Bugtraq, j'avais parfois l'impression que les patchs des distribs étaient tout le temps à la bourre par rapport à l'annonce de la faille et que la Debian était souvent encore plus à la bourre que les autres (j'ai pas de statistiques mais c'est l'impression sincère que ça me donnais).
Je suppose que celà s'explique par le fait que la Debian a des ressource limitée (car elle ne repose sur des bénovoles), et que patcher des bugs n'est pas vraiment excitant donc ils ne doivent pas se bousculer au portillon.
Avec de l'argent on arrive toujours à motiver des gens pour faire un tel travail.
Enfin, toute chose étant égale par ailleurs, avoir le source est forçément une bonne chose, car celà peut te permettre de te faire une meilleure idée de la qualité du soft que tu veux acheter (si tu es capable de le lire, car lire le code d'un programme que tu n'as pas écrit est difficile à moins qu'il soit très propre).
C'est normal, souvent ce sont des etudiants (de tres haut niveau) dont le sujet de cours ou de these est justement de trouver une ou plusieurs failles.
Je crois t'exagère un peu là.
Ne le prends pas mal, mais dès fois je me demande si LinuxFr n'est pas un peu un repaire de gens qui répètent des clichés d'un ton assuré sur des sujets qu'il ne maitrisent pas. (Moi non plus je maitrise rien mais je le dis)
C'est vrai que pour les failles mathématiques dans le domaine de la cryptologie, ça demande effectivement en général pas mal de travail, et ça semble pouvoir être du niveau d'une thèse. J'avais lu un papier sur une attaque concernant SSH suivant une technique dite de l'oracle Breichenbacher, j'avais pas tout compris mais ça avait l'air impossible à appliquer en pratique cae il aurait fallu générer des millions de connexion sur le serveur. Par contre le gars qui a trouvé cela à probablement (car j'y connais rien) du mérite sur le plan mathématique.
Mais pour des failles comme les buffer overflow et les format string, remarquer qu'un programme plante quand j'entre un "AAAAAA..." ou un "%n%n%n%n..." quelque part ne fait pas de moi un Albert Einstein en puissance. Et ce genre de faille est bien plus fréquente que la précedente.
Pareil pour les failles de CGI qui nécessitent juste une connaissance basique des langages associés (Php, Perl, ...). Cela me donne parfois plus l'impression d'un lycéen qui essaye de se faire mousser sur BugTraq avec sa faille minable, que de l' "étudiant de haut niveau" dont tu parlais.
etudiant en maitrise de math de trouver un theoreme
Ou est-ce que tu a lu ça ? Et qu'est-ce que tu entends par un "thérorème", les maths consiste à faire des démonstrations, donc tout travail de matheux est un théorème.
Maintenant si tu parle d'un théorème suffisament intéressant pour être enseigné je crois que tu rève.
un ingenieur mecanicien, de concevoir sur le papier un moteur thermique complet
Dans mon école il y a avait pas de filière méca, mais ça me semble bien irréaliste comme projet de dernière année ton truc.
Je sais que la filière instru (Physique) faisait des petits compteurs, que la filière éléctronique avais fait un GBF=Générateur Basse Fréquence (comme ceux que l'on voit en TP d'éléc au lycée)
Rien d'aussi délirant que ce que tu raconte.
Le NAT n'est pas fait pour faire de la sécurité mais pour lutter contre la pénurie d'adresse.
Les gens qui travaillent sur Ipv6 ont un article qui explique pourquoi il ne faudrait plus l'utiliser (surtout pour faire de la sécurité !). En gros leur argument est que ça fout en l'air la transparence du réseau, que ça empêche l'emergence de nouvelles applications (peer 2 peer, téléphonie sur IP, ...) qui ne fonctionnent plus suivant le modèle client-serveur
J'ai pas lu l'article mais ta phrase sur le pipeline et la prédiction de branchement me semble relativement compréhensible pour quelqu'un qui connait l'assembleur x86, et qui a une petite idée du fonctionnement interne d'un processeur.
C'est le genre de truc que l'on apprends lorsque l'on essait d'optimiser du code par exemple pour faire des jeux ou de la 3D ce qui est quand même la principale motivation pour faire de l'assembleur (chez les etudiants tout du moins).
Maitenant pour quelqu'un qui n'a jamais fait d'ASM c'est sur qu'il ne peut pas comprendre.
Mais c'est comme pour tout les articles un peu développeur, si tu ne sait pas programmer en C, malloc() ça peut être du chinois. Si tu ne connais pas TCP/IP un port ou une IP c'est du chinois aussi.
Sinon, pour la phrase, depuis le 486 les processeurs sont pipelinées, c'est à dire que l'on découpe l'éxécution de l'instruction en tranches par exemple pour le 486 : Fetch (lecture), Decode 1, Decode 2, Execution, et Write (ds les registres). L'avantage c'est que l'on gagne en fréquence, car celles-ci sont limités par la latence des porte-logiques, si tu découpe ton processeur en 5 étapes, tu peux espérer utiliser dans chaque étape 5 fois de portes. Comme tu as 5 fois moins de portes, même si la latence de chaque porte est la même qu'avant (parce que tu grave toujours avec le même process, tu n'est pas passé par exemple du 0.18 micron au 0.13), la durée minimale pour que toute les portes aient le temps de basculer est diviser par 5, donc au lieu que la freq maximale de ton processeur soit de 10 Mhz elle passe à 50 Mhz.
Maintenant, l'inconvénient c'est que des fois tu dois vider ton pipeline par exemple parce qu'il y a un saut conditionnel et que ton pipeline il est remplie avec des instructions que tu n'aurais pas executer. Donc tu jette tout, et tu recommence le fetch, le décodage, l'éxécution ... ce qui te fais perdre un nombre de cycle égal au nombre d'étape du pipeline.
Ex : Le pentium 4 a 20 étages dans son pipeline contre 12 pour le PII/PIII donc il atteint des fréquences plus élevés mais comme le cout d'un vidage de pipeline est plus élévé à fréquence égale ses perf sont inférieures à celles d'un PIII (car il passe plus de cycles à ne rien faire).
Tu m'as mal compris, j'ai dit : "si la phrase est suffisamment longue".
L'intérêt de MD5 est de te permettre d'utiliser une phrase aussi longue que tu veux, donc tu peux compenser le fait que l'entropie moyenne par caractère soit faible (ce auquel tu fait allusion via ton attaque par dictionnaire) en utilisant plus de caractères.
Au contraire avec un mot de passe classique, comme tu est limité dans ton nombre de caractère
(par exemple 7 caractères effectifs pour un mot de passe utilisateur NT 4), tu dois exploiter au maximum la plage de caractère possible, ce qui rends les mots de passe difficilement mémorisable . Qui se souviendra sans l'écrire sur un post-it, d'un password contenant des têtes de mickey, et autre caractères tapés à coup de CTRL-machin.
Alors que la première phrase de la page Y d'un roman, c'est possible de l'apprendre par coeur et si on l'oublie, un bouquin sur une étagère avec une page cornée reste plus discret qu'un post-it sur l'écran.
Une solution serait de demander à l'utilisateur de rentrer une "passphrase", de faire une checksum MD5 dessus (128 bits), et de ne garder que les n bits (Ex n=56 pour DES) de poids faible comme clé.
Si la phrase est longue, l'entropie devrait suffisante pour que cela demande trop de ressource de cracker cela eu égard à la valeur toute relative des données hébergée par un particulier.
Ils ont pas trouvé une faille (off by one je crois) récemment dans SSH (auth.c)
Comment ça se fait qu'OpenBSD n'est pas concerné, ils sont pas vulnérables ou bien c'est quand leur histoire d'install par défaut qui fait que "celle-la elle compte pas" ?
En fait, je crois que c'est plutôt aucun trou de sécurité "remote" dans l'install par défaut.
Pour autant, on ne peut pas dire pour autant que les démons soit parfaitement sécurisés, je crois me souvenir d'une faille sur Bugtraq concernant serveur FTP d'OpenBSD il y a un an. Elle ne comptait pas, car le serveur FTP n'était pas dans
l'install par défaut.
Les multiples race conditions dans le noyau (similaire à celle que l'on avait trouvé dans Linux) ne comptent pas non plus car elles sont "locales".
En fait, j'ai l'impression que l'install par défaut n'installe aucun programme accessible en "remote", d'ou le fameux slogan qui permet de dire : OpenBSD, c'est le serveur ne servant à rien le plus sécurisé de la planète.
Je suis quand même étonné voir des gens dire : "j'ai installé mon le patch O(1) et depuis mon système va bcp plus vite pour lancer Mozilla et StarOffice".
A priori la complexité d'un algorithme a une influence pour n grand (mathématiquement pour le calcul de complexité n est supposé "proche" de l'infini), je comprends que pour un serveur Web avec 8 processeur et un serveur Apache configuré avec un pool de 10000 thread (qui sous Linux sont gérés comme des processus), ce patch puisse jouer sur les performances mais est-ce vraiment le cas pour une utilisation de station de travail classique ?
Tout ça ne réléverait-il pas plutôt de l'effet placébo.
[^] # Re: Patch = MS --> Attention à la mauvaise foi
Posté par Anne Onimousse . En réponse à la dépêche OpenBSD 2.9 is dead. Évalué à 3.
Ne fait pas l'idiot, tu as très bien compris que je parlais des différentes implémentation de Unix (en particulier Linux ou les *BSD)
le buffer overflow n'est pas un concept provenant d'UNIX, c'est un concept générique.
Non mais c'est sous UNIX que les gens ont appris à les exploiter (le premier buffer overflow de l'histoire c'était dans le ver d'internet 89) bien avant l'existence de NT
Trouver un IIS vulnérable est encore bien plus simple.
Pas forcément si simple, avec les vers et compagnie qui peuvent scanner Internet de façon exhaustive, la quasi-totalité des machines vunérables ont déja été exploitée au moins une fois et avec les patchs "tout-en-un" de MS un admin qui met-à-jour contre code Red corrige aussi toutes les autres failles en même temps.
Donc aujourd'hui 90% des IIS sont à jour, je ne suis pas sûr que 90% des vielles RedHat 6.2 qui trainent dans les entreprises soient patchées contre le "rpc.statd" ("remote root" pourtant).
La preuve : 6 mois avant CodeRED, beaucoup de ver Linux (Ex : LionWorm) sont sortis, ils auraient surement connus eux-aussi le succès si le nombre de machine sous RedHat était voisin du nombre de machines NT/IIS.
ligne de commande, celle ci a toujours existé sous Windows.
Je ne vois pas ce qu'un cracker pourrait faire d'une ligne de commande Windows ?
Peut-il compiler ses outils/exploits ? Installer une backdoor qui ouvre un port vers la ligne de commande Dos ?
Le plus rigolo, c'est que dans Windows, on trouve des cheat codes qui court-circuitent la
sécurité.
Rien compris
[^] # Patch = MS --> Attention à la mauvaise foi
Posté par Anne Onimousse . En réponse à la dépêche OpenBSD 2.9 is dead. Évalué à 2.
1) patch est un mot qui appartient à la terminologie Unix (MS parle de Hotfix)
2) les buffer overflows et autres failles étaient déjà légions sous Unix avant que les problèmes ne soient connu sous NT (d'ou l'emploi courant d'un mot d'origine UNIX pour désigner le problème sous Windows)
3) Je me souviens d'une section du site "PacketStorm" intitulée "les 1500 exploits les plus connus sous Unix".
Donc dire qu'il y a plus de buffer overflow sous NT que sous Unix est une affirmation gratuite
En bref, UNIX avait plutôt une réputation de système ciblé par les "cracker".
Pendant longtemps, les gens se sont demandés s'il était possible de transposer ce "savoir" vers NT.
- L'absence d'interface en ligne de commande (et de port telnet/SSH) rendait difficile la manipulation à distance d'une machine compromise par le "cracker".
- il existe depuis longtemps de nombreux rootkits pour Unix, mais l'absence des sources rends beaucoup plus difficile l'élaboration de tels outils pour Windows (même si quelques tentatives ont été faite avec SoftIce comme debugger)
Donc, il me semble que Windows soit surtout utilisé pour la propagation de ver mais qu'un "cracker" désireux de se procurer une nouvelle "box" lui préférait une install par défaut d'une RedHat 6.2, à mon humble avis ?
[^] # Re: Mon dieu !!
Posté par Anne Onimousse . En réponse à la dépêche Dillo 0.6.5. Évalué à 2.
Je ne pense que la génération de code C soit lié à une "optimisation" comme tu le dis, mais simplement au fait que le C est portable.
De cette façon on laisse le compilateur Eiffel se concentrer sur des optimisations de haut-niveau (celles spécifiques au langage Eiffel) alors que le compilateur C s'occupe des optimisations de bas niveau (celle relative à une architecture cible comme par exemple la pénurie de registre sur x86).
L'inconvénient est que l'on perd en qualité du code généré : puisque les deux compilateurs ne peuvent "communiquer" cela nous prive de certaines optimisations.
Mais Eiffel étant un projet universitaire, pense tu que l'équipe qui travaille dessus dispose des fonds nécessaire pour écrire le million de ligne de code supplémentaire qui permettrait de se passer de l'étape C ?
Le C++ a subit le même chemin, son premier compilateur (cfront) générait du code C, alors que tout les compilateurs industriels actuels (Sun pro CC, Visual C++, g++, ..) générent directement de l'assembleur.
Si Eiffel n'a pas cette chance c'est simplement parce que ce langage n'est pas assez populaire.
En tout cas merci de me traiter d'autiste en passant, mais le jour où ton OS et toutes les applis tournent en Java, soit tu dis adieu à la vitesse soit adieu à la couche d'ozone
Le seul avantage d'un langage de bas-niveau comme le C (ou l'assembleur) sur C++, c'est une plus faible consommation de ressource (mémoire) pas une meilleure rapidité.
Dans l'industrie le C (et l'ASM) est toujours utilisé dans le domaine de l'embarqué pour cette raison.
Un noyau peut-être considére comme un programme temps réel d'où la nécessité du C (et puis la plus faible consommation mémoire importe ici)
Quand à Java c'est vrai que la portabilité à forcément une contrepartie en terme de performance. Et puis le code Java est souvent plus lisible donc plus maintenable.
Les langages de bas niveau sont AMHA plus intéressants intellectuellement pour connaître sa machine
On peut programmer en langage de haut-niveau tout en connaissant d'autres langages de bas niveau (perso j'ai fait de l'assembleur Intel avant même si maintenant j'utilise surtout C++)
Je crois qu'il est beaucoup plus dur de maîtriser en langage bas niveau qu'un langage haut niveau
Pourtant la majorité des programmeurs C++ ont fait un ou deux ans de "C pur" avant, donc qui peut le plus peut le moins !
Pour avoir utilisé les deux langages, j'ai l'impression qu'il y a plus de subtilité dans C++ (par exemple connait-tu la différence entre un "static_cast", un "const_cast", un "dynamic_cast" et un "reinterpret_cast" ?) que dans C.
[^] # Re: Justement...
Posté par Anne Onimousse . En réponse à la dépêche Sortie du SGBD Firebird en version 1.0 finale. Évalué à -1.
[^] # Re: Justement...
Posté par Anne Onimousse . En réponse à la dépêche Sortie du SGBD Firebird en version 1.0 finale. Évalué à -1.
Il ne parait pas forcément évident à tout le monde que voter pour un autre parti politique que le PS soit de nature à "se rendre malade".
(Hors sujet)
Je crois en effet que tes convictions politiques n'ont rien à faire ici !
[^] # Re: Ne nous trompons pas d'ennemi
Posté par Anne Onimousse . En réponse à la dépêche Dreamworks choisit Linux. Évalué à -3.
[^] # Re: Ne nous trompons pas d'ennemi
Posté par Anne Onimousse . En réponse à la dépêche Dreamworks choisit Linux. Évalué à -4.
Franchement qu'est ce que ça peut te faire que la part de marché de Windows stagne ?
Personellement, je me fout pas mal de savoir si Peugeot vends moins que Renault ou l'inverse et pour Microsoft c'est la même chose
[^] # Re: Quelques tests
Posté par Anne Onimousse . En réponse à la dépêche Sortie de Nessus 1.2. Évalué à 2.
Non, ils n'ont pas d'intérêt économique à le faire.
Si ils ont choisi Nessus, c'est pour faire des économies au niveau du développement, donc ils ne développent rien du tout (si ce n'est l'interface) et concentrent toutes leurs ressources sur le marketing.
De plus, si ils développaient quelque chose ça serait quand même idiot de leur part d'en faire cadeau à leurs concurrents.
Ce qui est plus embétant, c'est que :
a) certains d'entre-eux pour des raisons marketing vont prétendre avoir développé un scanner proprio
b) La GPL les contraints à redistribuer le source seulement si ils distribuent le binaire.
En mode ASP (application hébergée accessible via une plateforme internet), le client n'a pas accès au binaire donc ils n'ont pas l'obligation de redestribuer le source voir d'avouer utiliser Nessus.
[^] # Re: les etudiants qui utilisent Visual au lieu de GCC
Posté par Anne Onimousse . En réponse à la dépêche Shockwave player sous Linux. Évalué à 1.
C'est surement l'IDE de Visual qui les intéresse plus que le compilo, qui pour un petit prog de TP ou les bugs de compilo n'apparaissent pas, se valent tous.
nombre de gens sont victimes du "syndrome de l'inertie au changement"
C'est pas de l'inertie au changement puisque tu dis qu'ils l'utilisent gcc (éventuellement contre leur gré) en TP. Donc si quand on leur laisse le choix (chez eux), ils font l'effort de changer c'est que le nouvel IDE convient mieux à leur besoins.
Et si ils sont aussi nombreux que tu nous le dis à trouver que Visual réponds mieux à leur besoin que l'IDE qu'ils utilisent en TP, on peut donc en déduire que Visual est globalement un bon produit qui réponds assez bien aux attentes de la grande majorités des utilisateurs de ce type de produit.
Les arguments d'ouverture, liberté, etc sont difficiles à faire passer
Tout dépends ce que tu veux faire avec le soft, si tu veux l'utiliser comme un développeur avoir le source est utile, pour un utilisateur tu t'en fous.
Ce n'est pas parce qu'il existe Doom sous licence libre, que les ventes de Quake 3 vont s'effondrer du jour au lendemain. Car, pour la plupart des gens c'est la qualité du logiciel qui prime, et celle-ci est bien meilleure avec Quake 3 bien qu'il ne soit pas libre. Car, même si tu aime développer (comme moi), il faut plusieurs mois d'acclimatation avant de contribuer sur un source et il n'est pas réaliste de contribuer à plus d'un ou deux projets à la fois.
En résumé tu repproche a tes compères de TP d'en avoir rien à faire de la philosophie Open-Source.
Et alors ! Des gens comme Richard Stallman qui sont motivés par des considérations philosophiques représentent une infime minoritée y compris au sein de la communauté des développeurs Linux. La majorité (cf sondage sur les développeurs du kernel) sont plutôt des gens comme Linus, qui développent pour s'amuser, se fichent complétement de la philosophie Open-source (hormis le fait qu'ils ne veulent que d'autre s'enrichissent sur leur dos avec leur travail), utilisent des softs proprio (comme BitKeeper) quand ils les trouvent mieux adaptés à leur besoins, ... bref des gens qui n'hésiterais pas une seul seconde à adopter VC++ si ils le trouvaient pratique
[^] # Re: Plugin propriétaire mais surtout format fermé
Posté par Anne Onimousse . En réponse à la dépêche Shockwave player sous Linux. Évalué à -3.
J'espère que tu ne dis pas vrai car j'aime bien SVG
ce sont ceux qui disaient que Mozilla n'arriverait jamais à rien parce que IE avait trop d'avance...
hou la, tu m'inquiéte la
[^] # Re: Free software vs Logiciel propriétaire
Posté par Anne Onimousse . En réponse à la dépêche Passez sous le nez de Snort. Évalué à 2.
Objectivement, je ne pense que pas que les softs Open-Source soit forcément à l'abris de ce genre de comportement càd cacher des failles ou prendre son temps pour corriger les bugs.
Ainsi, dans la réponse du développeur de Snort il explique qu'on lui avait envoyé la faille depuis plusieurs mois, mais qu'il ne s'étais pas pressé pour commiter le fix dans le CVS car il pensait qu'il ne serait dévoiler qu'à la prochaine conférence de sécu.
Sauf erreur de ma part, lors du bug d'openSSH, le bug à été fixé <i>en douce<i> dans le CVS longtemps avant que la faille ne soit annoncée.
Enfin, lorsque je lisais Bugtraq, j'avais parfois l'impression que les patchs des distribs étaient tout le temps à la bourre par rapport à l'annonce de la faille et que la Debian était souvent encore plus à la bourre que les autres (j'ai pas de statistiques mais c'est l'impression sincère que ça me donnais).
Je suppose que celà s'explique par le fait que la Debian a des ressource limitée (car elle ne repose sur des bénovoles), et que patcher des bugs n'est pas vraiment excitant donc ils ne doivent pas se bousculer au portillon.
Avec de l'argent on arrive toujours à motiver des gens pour faire un tel travail.
Enfin, toute chose étant égale par ailleurs, avoir le source est forçément une bonne chose, car celà peut te permettre de te faire une meilleure idée de la qualité du soft que tu veux acheter (si tu es capable de le lire, car lire le code d'un programme que tu n'as pas écrit est difficile à moins qu'il soit très propre).
[^] # Re: Allez plus haut
Posté par Anne Onimousse . En réponse à la dépêche Passez sous le nez de Snort. Évalué à 2.
Je crois t'exagère un peu là.
Ne le prends pas mal, mais dès fois je me demande si LinuxFr n'est pas un peu un repaire de gens qui répètent des clichés d'un ton assuré sur des sujets qu'il ne maitrisent pas. (Moi non plus je maitrise rien mais je le dis)
C'est vrai que pour les failles mathématiques dans le domaine de la cryptologie, ça demande effectivement en général pas mal de travail, et ça semble pouvoir être du niveau d'une thèse. J'avais lu un papier sur une attaque concernant SSH suivant une technique dite de l'oracle Breichenbacher, j'avais pas tout compris mais ça avait l'air impossible à appliquer en pratique cae il aurait fallu générer des millions de connexion sur le serveur. Par contre le gars qui a trouvé cela à probablement (car j'y connais rien) du mérite sur le plan mathématique.
Mais pour des failles comme les buffer overflow et les format string, remarquer qu'un programme plante quand j'entre un "AAAAAA..." ou un "%n%n%n%n..." quelque part ne fait pas de moi un Albert Einstein en puissance. Et ce genre de faille est bien plus fréquente que la précedente.
Pareil pour les failles de CGI qui nécessitent juste une connaissance basique des langages associés (Php, Perl, ...). Cela me donne parfois plus l'impression d'un lycéen qui essaye de se faire mousser sur BugTraq avec sa faille minable, que de l' "étudiant de haut niveau" dont tu parlais.
etudiant en maitrise de math de trouver un theoreme
Ou est-ce que tu a lu ça ? Et qu'est-ce que tu entends par un "thérorème", les maths consiste à faire des démonstrations, donc tout travail de matheux est un théorème.
Maintenant si tu parle d'un théorème suffisament intéressant pour être enseigné je crois que tu rève.
un ingenieur mecanicien, de concevoir sur le papier un moteur thermique complet
Dans mon école il y a avait pas de filière méca, mais ça me semble bien irréaliste comme projet de dernière année ton truc.
Je sais que la filière instru (Physique) faisait des petits compteurs, que la filière éléctronique avais fait un GBF=Générateur Basse Fréquence (comme ceux que l'on voit en TP d'éléc au lycée)
Rien d'aussi délirant que ce que tu raconte.
[^] # Re: Le NAT rien de plus efficace
Posté par Anne Onimousse . En réponse à la dépêche Mise en place d'un firewall « fort ». Évalué à 2.
Les gens qui travaillent sur Ipv6 ont un article qui explique pourquoi il ne faudrait plus l'utiliser (surtout pour faire de la sécurité !). En gros leur argument est que ça fout en l'air la transparence du réseau, que ça empêche l'emergence de nouvelles applications (peer 2 peer, téléphonie sur IP, ...) qui ne fonctionnent plus suivant le modèle client-serveur
[^] # Re: Commun des mortels ?
Posté par Anne Onimousse . En réponse à la dépêche Article sur le POWER4 d'IBM. Évalué à 3.
C'est le genre de truc que l'on apprends lorsque l'on essait d'optimiser du code par exemple pour faire des jeux ou de la 3D ce qui est quand même la principale motivation pour faire de l'assembleur (chez les etudiants tout du moins).
Maitenant pour quelqu'un qui n'a jamais fait d'ASM c'est sur qu'il ne peut pas comprendre.
Mais c'est comme pour tout les articles un peu développeur, si tu ne sait pas programmer en C, malloc() ça peut être du chinois. Si tu ne connais pas TCP/IP un port ou une IP c'est du chinois aussi.
Sinon, pour la phrase, depuis le 486 les processeurs sont pipelinées, c'est à dire que l'on découpe l'éxécution de l'instruction en tranches par exemple pour le 486 : Fetch (lecture), Decode 1, Decode 2, Execution, et Write (ds les registres). L'avantage c'est que l'on gagne en fréquence, car celles-ci sont limités par la latence des porte-logiques, si tu découpe ton processeur en 5 étapes, tu peux espérer utiliser dans chaque étape 5 fois de portes. Comme tu as 5 fois moins de portes, même si la latence de chaque porte est la même qu'avant (parce que tu grave toujours avec le même process, tu n'est pas passé par exemple du 0.18 micron au 0.13), la durée minimale pour que toute les portes aient le temps de basculer est diviser par 5, donc au lieu que la freq maximale de ton processeur soit de 10 Mhz elle passe à 50 Mhz.
Maintenant, l'inconvénient c'est que des fois tu dois vider ton pipeline par exemple parce qu'il y a un saut conditionnel et que ton pipeline il est remplie avec des instructions que tu n'aurais pas executer. Donc tu jette tout, et tu recommence le fetch, le décodage, l'éxécution ... ce qui te fais perdre un nombre de cycle égal au nombre d'étape du pipeline.
Ex : Le pentium 4 a 20 étages dans son pipeline contre 12 pour le PII/PIII donc il atteint des fréquences plus élevés mais comme le cout d'un vidage de pipeline est plus élévé à fréquence égale ses perf sont inférieures à celles d'un PIII (car il passe plus de cycles à ne rien faire).
[^] # Suggestion pour les mots de passe trop faible
Posté par Anne Onimousse . En réponse à la dépêche Script de création de répertoires cryptés (FS crypto). Évalué à 5.
L'intérêt de MD5 est de te permettre d'utiliser une phrase aussi longue que tu veux, donc tu peux compenser le fait que l'entropie moyenne par caractère soit faible (ce auquel tu fait allusion via ton attaque par dictionnaire) en utilisant plus de caractères.
Au contraire avec un mot de passe classique, comme tu est limité dans ton nombre de caractère
(par exemple 7 caractères effectifs pour un mot de passe utilisateur NT 4), tu dois exploiter au maximum la plage de caractère possible, ce qui rends les mots de passe difficilement mémorisable . Qui se souviendra sans l'écrire sur un post-it, d'un password contenant des têtes de mickey, et autre caractères tapés à coup de CTRL-machin.
Alors que la première phrase de la page Y d'un roman, c'est possible de l'apprendre par coeur et si on l'oublie, un bouquin sur une étagère avec une page cornée reste plus discret qu'un post-it sur l'écran.
[^] # Re: Interet d'un FS chiffré
Posté par Anne Onimousse . En réponse à la dépêche Script de création de répertoires cryptés (FS crypto). Évalué à 5.
Si la phrase est longue, l'entropie devrait suffisante pour que cela demande trop de ressource de cracker cela eu égard à la valeur toute relative des données hébergée par un particulier.
[^] # Re: OpenBSD
Posté par Anne Onimousse . En réponse à la dépêche Faille de sécurité dans les noyaux Linux. Évalué à 1.
Comment ça se fait qu'OpenBSD n'est pas concerné, ils sont pas vulnérables ou bien c'est quand leur histoire d'install par défaut qui fait que "celle-la elle compte pas" ?
[^] # OpenBSD
Posté par Anne Onimousse . En réponse à la dépêche Faille de sécurité dans les noyaux Linux. Évalué à 1.
Pour autant, on ne peut pas dire pour autant que les démons soit parfaitement sécurisés, je crois me souvenir d'une faille sur Bugtraq concernant serveur FTP d'OpenBSD il y a un an. Elle ne comptait pas, car le serveur FTP n'était pas dans
l'install par défaut.
Les multiples race conditions dans le noyau (similaire à celle que l'on avait trouvé dans Linux) ne comptent pas non plus car elles sont "locales".
En fait, j'ai l'impression que l'install par défaut n'installe aucun programme accessible en "remote", d'ou le fameux slogan qui permet de dire : OpenBSD, c'est le serveur ne servant à rien le plus sécurisé de la planète.
[^] # Re: patch scheduler O(1)
Posté par Anne Onimousse . En réponse à la dépêche Preemption Patch VS Low-Latency Patch. Évalué à 1.
A priori la complexité d'un algorithme a une influence pour n grand (mathématiquement pour le calcul de complexité n est supposé "proche" de l'infini), je comprends que pour un serveur Web avec 8 processeur et un serveur Apache configuré avec un pool de 10000 thread (qui sous Linux sont gérés comme des processus), ce patch puisse jouer sur les performances mais est-ce vraiment le cas pour une utilisation de station de travail classique ?
Tout ça ne réléverait-il pas plutôt de l'effet placébo.