Et ce risque qui est bien présent puisque les sources des logiciels du libre sont diffusés suffit à provoquer une crainte chez le developpeur qui souhaiterait developper un logiciel dans le but de répendre une backdoor.
Quelle crainte ? Je pense plutôt que ça n'interesse pas grand monde d'introduire une backdoor dans un soft, mais je ne vois pas ce qu'il y a à craindre de le faire.
Diffuser des sources affichant clairement une backdoor
A priori si tu mets une backdoor dans un soft tu t'arranges pour que ça ne soit pas clair, justement :-).
Non justement, un logiciel dont les sources ont été distribués et par exemple incorporés à des distributions, est difficile à faire disparaitre.
Je parle des traces "personnelles". C'est pas très compliqué de dissimuler son identité sur le Net. Quand un projet te laisse l'acces à leur CVS, ils demandent juste un login et un password encrypté. Pas une photocopie certifiée conforme de tes papiers d'identité, ni une attestation de domicile. Donc :
- il est possible d'introduire une backdoor dans un soft libre avec un risque très faible qu'elle soit detectée (il n'y a qu'a voir combien de temps il faut pour découvrir certaines vulnérabilités, alors si le gars veut vraiment planquer son truc...)
- ce risque n'imple aucune "crainte" vis à vis d'un esprit mal intentionné, parce qu'il est trivial de faire en sorte qu'on ne puisse jamais remonter à lui personellement.
Notre code est plutôt bien organisé, et bien sur on a une telle doc. Mais évidemment elle est incomplète, même probablement obsolète par endroit, et la maintenir est un boulot de fou...
Certes, cependant le codeur avec son code source libre et accessible sait qu'a n'importe quel momment il peut être relu
Non, justement, dans la plupart des cas il sait qu'il n'est jamais relu. Et quand bien même, qu'est-ce que ça peut faire ? Ça n'est pas bien difficile d'effacer ses traces.
De toute façon, les personnes qui ne comprennent pas les motivations des developpeurs du Libre sont des gens qui ne connaissent pas la passion. Leur vie doit être terriblement vide.
Je ne vois pas le rapport avec la question... Et puis le genre "ceux qui comprennent pas le libre sont des gens petits avec une vie médiocre", c'est un peu grotesque. Parmis les dev du libre il y a aussi de parfaits enfoirés, asociaux ou égocentriques, avec justement une vie totalement vide à part leur petit code cheri.
Ta conclusion est un peu rapide je trouve. Qu'une appli ne soit pas très connue n'implique pas qu'une vulnérabilité dessus n'ai pas de conséquences potentielles graves. Y a pas grand monde qui connait xinetd par exemple. Et même pour une appli connue "de nom", ça ne veut pas dire que le code est régulièrement examiné par plein de monde.
La seule démarche valable en la matière semble être d'auditer le code pour rechercher spécifiquement des vulnérabilités. Avoir simplement le code à disposition n'implique pas que les failles vont te sauter aux yeux.
Pareil ici (130 KLOCs de C++, équipe de 3 personnes plus 2 ou 3 nouveau venus). Le pb est qu'au dela d'une certaine complexité, pour patcher il faut vraiment s'y mettre. On reçoit 2 ou 3 fois par mois un mail d'une bonne âme qui demande "je voudrais aider, qu'est-ce que je peux faire ?", jamais ils ne donnent suite après qu'on leur réponde. Les seuls contributeurs sont ceux qui arrivent avec un patch ou un bout de doc dès de départ (et pourtant on a fait une page exprès avec toutes les indications pour les volontaires).
ESR a tiré ses conclusions de fetchmail qui est un soft relativement simple, pour des projets plus complexes ça se passe différemment. Si tu n'as pas une séparation évidente en modules comme pour le kernel, y a pas de miracles.
Si Windows est moins stable que Linux (encore que la différence soit de plus en plus moindre depuis 2000 et XP), c'est aussi parce que c'est beaucoup, beaucoup plus gros que Linux. Leur procédures de tests sont énormes, sur ce plan là je crois qu'aucun éditeur de soft ne leur arrive à la cheville :
Par contre c'est sur qu'il y a eu un choix marketing qui fait qu'ils se sont interessés à la fiabilité depuis quelques années seulement (quand MS c'est interessé au marché des serveurs).
La légende urbaine c'est que 50 personnes regardent le code en permanence. Ça n'est vrai que pour les plus gros projets (et encore, pas 50, une douzaine tout au plus).
Surtout qu'il est écrit par des mecs qui connaissent bien mieux Unix que 99% des gens ici :-). Simson Garfinkel a écrit entre autres le "Safe book" : "Practical Unix & Internet Security" chez O'Reilly : http://www.oreilly.com/catalog/puis3/(...)
Oups oui, exact. Disons pour être plus général que si tu traces la courbe du temps mis à s'executer en fonction du nombre de données, tu obtiens plus ou moins une courbe en x^2 (sachant que, comme le dit Fabien, on ne tient compte que de la fonction ayant la croissance la plus forte).
La complexité de l'algo, ou l'évolution de sa complexité par rapport à sa charge (sa derivation quoi )???
La complexité c'est, justement, le 'O(x)', et ça indique la croissance du temps mis à accomplir la tache en fonction du nombre de données.
O(1) => temps constant quelque soit la quantité de données
O(n) => temps croissant linéairement avec la quantité de données
Les autres complexités fréquemment rencontrées sont O(N^2), O(exp(n)), O(ln(n)) et O(n ln(n)) (si ma mémoire est bonne, ça fait un bail que j'ai étudié ça en fac :-).
Par exemple un algo en O(n^2) qui met 3 secondes pour processer un tableau de 100 entiers mettra 9 secondes pour en processer 200.
Si je me souviens bien on avait démontré qu'un algo de tri était au mieux en O(n ln(n)).
ou puis-je me renseigner pour comprendre ce jargon ?
C'est pas un jargon, c'est de la théorie algorithmique de base, tu trouvera ça dans n'importe quel bouquin de cours sur le sujet.
Non, écrire un français correct est tout aussi essentiel, surtout sur un site public. Bien sur qu'on fait des fautes, c'est pour ça qu'on se relit avant de poster, c'est le minimum de respect à avoir pour le lecteur.
Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même.
Je sais bien, mais en pratique faire des dtors qui ne sont pas appelés de manière deterministe n'est pas toujours simple.
et le destructeur se charge de l'enregistrer quand on a fini. [...]
Ruby permet aussi ce genre d'idiomes à la C++, par exemple :
File.open("foobar.txt") { |filehandle|
...
}
à la fin du bloc, le fichier est fermé. Et ce genre d'idiome (RAII - Ressource Allocation Is Initialisation) ne peut vraiment fonctionner que si tu as un appel deterministe de ton dtor.
En plus Cédric Foll nous dit qu'il y a bien des finalizers en Ruby, j'aurais du mieux regarder mon pickaxe avant de te répondre :-).
Du peu que j'ai lu sur lui, en particulier sur le site de Shimomura, ses talents ne se bornaient pas à appeler une secrétaire pour arriver à lui faire dire son password. Regarde les transcriptions de ses sessions 'talk' :
La seule traduction que je connais de «hacker», c'est développeur.
Ça ne veut pas dire que ce soit la seule qui existe.
Et Kevin Mitnick est surtout un pro des relations sociales, plutôt «wranker» que «hacker».
Je suppose que tu veux dire "wanker" ? Et sur quoi te bases-tu pour dire ça ? Je crois que si c'était un expert des relations publiques, il n'aurait pas purgé une peine aussi longue, et serait déjà beaucoup plus riche :-).
Mouais. D'après un pote qui bosse chez BEA, leurs concurrents sont MS et IBM. JBoss n'existe pratiquement pas dans l'industrie, il n'y sont jamais confrontés lors d'un appel d'offre.
L'explication étant surtout qu'une boite qui considère JBoss comme une solution ne considère pas BEA, MS ou IBM comme une alternative (parce que trop cher pour eux), et inversement si elle considère une solution comme BEA, etc... JBoss n'est même pas évalué.
Ici :
http://www.xfree86.org/pipermail/forum/2003-March/000168.html
Plus loin il y a aussi un autre post intéressant :
http://www.xfree86.org/pipermail/forum/2003-March/000181.html
The biggest roadblock to Linux being deployed on the desktop to displace
Microsoft software is the same thing it always has been - too MUCH choice.
Too many distributions, too many desktops, etc, etc. IT people don't want
it. Real, consumer end-users don't want it. I think it is hillarious to see
the OS-wars of old (e.g. a million Unix vendors -> OSF vs Unix
International; a bunch of desktop-like things -> Motif vs Open Look -> CDE
"unification") repeat itself yet again in the form of myriad distributions
and GNOME vs KDE.
I'm an OLD-time UNIX guy (started in 1981), and I moved to the Windows world
years ago because I saw this cycle repeating itself.
The only successful desktop UNIX implementation os OS.X, which, BTW, is
pretty closed without a lot of choice.
Personne ne va être d'accord, mais bon... :-)
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 1.
Quelle crainte ? Je pense plutôt que ça n'interesse pas grand monde d'introduire une backdoor dans un soft, mais je ne vois pas ce qu'il y a à craindre de le faire.
Diffuser des sources affichant clairement une backdoor
A priori si tu mets une backdoor dans un soft tu t'arranges pour que ça ne soit pas clair, justement :-).
Non justement, un logiciel dont les sources ont été distribués et par exemple incorporés à des distributions, est difficile à faire disparaitre.
Je parle des traces "personnelles". C'est pas très compliqué de dissimuler son identité sur le Net. Quand un projet te laisse l'acces à leur CVS, ils demandent juste un login et un password encrypté. Pas une photocopie certifiée conforme de tes papiers d'identité, ni une attestation de domicile. Donc :
- il est possible d'introduire une backdoor dans un soft libre avec un risque très faible qu'elle soit detectée (il n'y a qu'a voir combien de temps il faut pour découvrir certaines vulnérabilités, alors si le gars veut vraiment planquer son truc...)
- ce risque n'imple aucune "crainte" vis à vis d'un esprit mal intentionné, parce qu'il est trivial de faire en sorte qu'on ne puisse jamais remonter à lui personellement.
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 1.
Notre code est plutôt bien organisé, et bien sur on a une telle doc. Mais évidemment elle est incomplète, même probablement obsolète par endroit, et la maintenir est un boulot de fou...
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 2.
Non, justement, dans la plupart des cas il sait qu'il n'est jamais relu. Et quand bien même, qu'est-ce que ça peut faire ? Ça n'est pas bien difficile d'effacer ses traces.
De toute façon, les personnes qui ne comprennent pas les motivations des developpeurs du Libre sont des gens qui ne connaissent pas la passion. Leur vie doit être terriblement vide.
Je ne vois pas le rapport avec la question... Et puis le genre "ceux qui comprennent pas le libre sont des gens petits avec une vie médiocre", c'est un peu grotesque. Parmis les dev du libre il y a aussi de parfaits enfoirés, asociaux ou égocentriques, avec justement une vie totalement vide à part leur petit code cheri.
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 1.
Pour ce qui est des procedures, j'ai tendance a croire que si elles existent c'est pour palier a une certaine deficiance.
Mouais. Tu n'as jamais fait de développement logiciel, toi, hein ? :-)
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 2.
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 3.
La seule démarche valable en la matière semble être d'auditer le code pour rechercher spécifiquement des vulnérabilités. Avoir simplement le code à disposition n'implique pas que les failles vont te sauter aux yeux.
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 3.
ESR a tiré ses conclusions de fetchmail qui est un soft relativement simple, pour des projets plus complexes ça se passe différemment. Si tu n'as pas une séparation évidente en modules comme pour le kernel, y a pas de miracles.
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 3.
http://www.winsupersite.com/reviews/winserver2k3_gold2.asp(...)
Par contre c'est sur qu'il y a eu un choix marketing qui fait qu'ils se sont interessés à la fiabilité depuis quelques années seulement (quand MS c'est interessé au marché des serveurs).
[^] # Re: Quelles sont les motivations des développeurs de logiciels libres ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quelles sont les motivations des développeurs de logiciels libres ?. Évalué à 6.
[^] # Re: « The Unix-Haters Handbook » est disponible en ligne
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche « The Unix-Haters Handbook » est disponible en ligne. Évalué à 5.
[^] # Re: Nuance ...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Linux et sa maniabilité. Évalué à -1.
[^] # Re: Avancées technologiques du prochain Kernel
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Avancées technologiques du prochain noyau Linux. Évalué à 1.
[^] # Re: Avancées technologiques du prochain Kernel
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Avancées technologiques du prochain noyau Linux. Évalué à 10.
La complexité c'est, justement, le 'O(x)', et ça indique la croissance du temps mis à accomplir la tache en fonction du nombre de données.
O(1) => temps constant quelque soit la quantité de données
O(n) => temps croissant linéairement avec la quantité de données
Les autres complexités fréquemment rencontrées sont O(N^2), O(exp(n)), O(ln(n)) et O(n ln(n)) (si ma mémoire est bonne, ça fait un bail que j'ai étudié ça en fac :-).
Par exemple un algo en O(n^2) qui met 3 secondes pour processer un tableau de 100 entiers mettra 9 secondes pour en processer 200.
Si je me souviens bien on avait démontré qu'un algo de tri était au mieux en O(n ln(n)).
ou puis-je me renseigner pour comprendre ce jargon ?
C'est pas un jargon, c'est de la théorie algorithmique de base, tu trouvera ça dans n'importe quel bouquin de cours sur le sujet.
[^] # Re: une méthode pour debian
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Pilotes « Open Source » chez Digigram. Évalué à 6.
A l'occasion, ça te dirais de jeter un coup d'oeil à notre truc ?
http://www.all-day-breakfast.com/rosegarden/(...)
(éditeur/séquenceur MIDI sous Linux - pas fini, mais commence à valoir le coup d'oeil)
</pub éhontée>
# Re: Copier un CD
Posté par Guillaume Laurent (site web personnel) . En réponse au journal Copier un CD. Évalué à 1.
[^] # Re: Et la langue française, bordel !
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Fork d'XFree86. Évalué à 10.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 3.
Je sais bien, mais en pratique faire des dtors qui ne sont pas appelés de manière deterministe n'est pas toujours simple.
et le destructeur se charge de l'enregistrer quand on a fini. [...]
Ruby permet aussi ce genre d'idiomes à la C++, par exemple :
File.open("foobar.txt") { |filehandle|
...
}
à la fin du bloc, le fichier est fermé. Et ce genre d'idiome (RAII - Ressource Allocation Is Initialisation) ne peut vraiment fonctionner que si tu as un appel deterministe de ton dtor.
En plus Cédric Foll nous dit qu'il y a bien des finalizers en Ruby, j'aurais du mieux regarder mon pickaxe avant de te répondre :-).
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 2.
C'est vrai, un langage de script où il faudrait soit-même gerer ses ressources, ça manque :-).
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 1.
[^] # Re: Interview de Matz le créateur de Ruby
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 1.
[^] # Re: Les aspects criminologiques des CRackers
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Les aspects criminologiques des hackers. Évalué à 1.
http://www.takedown.com/evidence/transcripts/index.html(...)
[^] # Re: Les aspects criminologiques des CRackers
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Les aspects criminologiques des hackers. Évalué à 0.
Ça ne veut pas dire que ce soit la seule qui existe.
Et Kevin Mitnick est surtout un pro des relations sociales, plutôt «wranker» que «hacker».
Je suppose que tu veux dire "wanker" ? Et sur quoi te bases-tu pour dire ça ? Je crois que si c'était un expert des relations publiques, il n'aurait pas purgé une peine aussi longue, et serait déjà beaucoup plus riche :-).
[^] # Re: Les aspects criminologiques des CRackers
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Les aspects criminologiques des hackers. Évalué à 6.
http://interviews.slashdot.org/article.pl?sid=03/02/04/2233250&(...)
[^] # Re: JBoss partage ses bénéfices avec l'Open Source
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche JBoss partage ses bénéfices avec l'Open Source. Évalué à 5.
Mouais. D'après un pote qui bosse chez BEA, leurs concurrents sont MS et IBM. JBoss n'existe pratiquement pas dans l'industrie, il n'y sont jamais confrontés lors d'un appel d'offre.
L'explication étant surtout qu'une boite qui considère JBoss comme une solution ne considère pas BEA, MS ou IBM comme une alternative (parce que trop cher pour eux), et inversement si elle considère une solution comme BEA, etc... JBoss n'est même pas évalué.
# Réponse de Keith Packard
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Keith Packard viré de XFree86. Évalué à 4.