Merci d'intervenir ; je suis intéressé par toute discussion constructive qui pourrait faire progresser mes connaissances, surtout lorsque c'est fait sans agressivité.
Pas de probleme, j' essaye de ne pas être agressif, mais tu sais quand on est convaincu de ce qu' on dit . . . on a parfois l' air agressif, trop critique ou condescendant . . .
Non, je n'ai jamais eu l'intention de troller quoique ce soit. Bien au contraire, je n'imaginais pas que suggérer sur FrsAG qu'exécuter un processus en root ne serait pas une bonne pratique au niveau sécurité peut déclencher une telle réaction.
Oui, mais le fait est que tu avais tort, il est possible et assez facile, de gérer ça sans que le processus soit root, ton installation par défaut n' est pas la vérité ultime. De plus, meme en root, quand un peut lire et comprendre le script facilement et rapidement . . . le probleme reste moins grave qu' une boîte noire, que tu exécutes sans avoir aucune idée du code qui s'exécute.
La tu attaque l open source. Je suppose que tu n es QUE sysadmin et pas du tout codeur ? ( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe )
Pas du tout, je "n'attaque" pas l'open source et je suis surtout "codeur". Je pense simplement que ce n'est pas le fait que le code soit "open" qui le rend plus sûr. Par contre je redis qu'il faut qu'il soit open pour être libre.
Tu insinue le fait qu' un code open source est plus vulnérable et dangereux car on peut lire le code. c' est là le troll ( sournois , mais je ne t en veux pas , tu n es pas le premier a te poser ce genre de questions ) que je suis obligé de combattre. Un troll qui a été débunké à tous les niveaux, notamment pas les FAITS ces 20 dernières années.
Oui avec l open source il est facile de decouvrir une faille ! Ah, au moins un point où on est presque d'accord. Il est plus facile de découvrir une faille en analysant un code que l'on peut lire qu'un code qu'on ne peut pas lire :-)
Certes, et c' est toute la force de l' open source, si il y a une faille ou une backdoor, on va la niquer vite fait, et on passera a la suite. Ceci dit, tu restes libre de croire que c' est mieux de laisser la faille se répandre pendant 20 ans avant que la moitié de la planète ne se fasse pirater betement par une boite noire auquel tout le monde fait confiance vu qu on peut pas voir le code.
DONC :
- Il est tres probable que la faille sera decouverte RAPIDEMENT ,
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
Plusieurs raisons sont possibles, dans le cas d un logiciel comme openssh le plus probable c est : * optimisation * respecter des specs complexes et de tres nombreux cas particuliers
Si tu veux plonger dans le code d un logiciel comme openssh ou bitcoin . . . ca va prendre d temps, il ne suffit d etre un bon codeur.
Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde… Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche.
Je comprends tout a fait ca, ca mest arrivé. On a essayé d expliquer a bull que ca serait plus rapide de tout réécrire proprement, ils ont refusé, je me suis battu pour me faire licencier. Ce genre de chose ne devrait pas arriver, il existe des outils comme valgrind, qui me permettent d'être sûr à 99.99% que quand je livre un code, il n y a aucune fuite mémoire, aucun buffer overflow, aucun null pointer dereference . . .
plein de gens qui sont aussi paranos que toi et moi, vont jeter un oeil au code, et les plus autiste d entre nous y passeront peut etre plusieurs jours ( ou nuits ),
J'ai un gros doute sur le fait que plein de gens (bienveillants) passent du temps à chercher des failles dans les logiciels open source. Je sais par ma première expérience évoqué ci- dessus que c'est un travail très compliqué. Qui les payerait pour cela ? Mais je ne demande qu'à me tromper ; ce serait une bonne nouvelle. Par contre l'utilisation massive de logiciels open source me semble un facteur bien plus rassurant sur leur fiabilité. Cela multiplie les opportunités de remarquer des failles (ou des bugs).
C' est le cœur de ton problème, tu ne peux pas imaginer qu' il existe des gens bienveillants, trop intelligents ou trop autistes pour rentrer dans l' arnaque globale du système dans lequel nous vivons. C est vrai que ce genre de gens bienveillants, ou neutres, trop intelligents ou trop autistes finissent souvent cancres, clochards ou suicidés avant 20 ans, mais certains survivent . . . et ce genre de débiles autistes survivants sont ceux qui ont fait l open source, linux, la GPL, bitcoin, internet, et j' en passe.
Ce n'est pas une question de croyance, c'était juste un constat. Mon installation standard de cerbot aboutissait à un processus lancé par root.
Le fait est que tu avais tort, dorénavant tu sais qu' il y a moyen de ne pas tourner en root. Tu avais tort par ignorance ou feignantise, admets le STP !
- Le mec qui voudrait mettre une backdoor dans un logiciel choisira la
boite noire, car si il a un minimum d intelligence, il sait que sa backdoor sera vite decouverte et qu il perdra au minimum sa reputation, et au maximum . . . beaucoup plus.
Il n'y a pas que l'insertion volontaire d'une faille ; elle peut s'y trouver à l'insu du codeur ; cf. le bug de la fonction time() évoquée plus haut.
C est pareil, backdoor ou pas, quand on OSE faire de l open source on tient a sa reputation et on essaye de ne pas faire de la merde, de ne pas livres des fuites memoires, des buffer overflow . . .
Il y a aussi eu un concours organisé pour ce genre de sport : http://www.underhanded-c.org/ ; tiens c'est marrant, le lien https ne fonctionne pas pour ce site :-0
sauf que la je parle de redhat, de la N SA, de GCC, de la libc et du kernel :p
/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable :) Also, bypass of mmap_min_addr via SELinux vulnerability! (where having SELinux enabled actually increases your risk against a large class of kernel vulnerabilities) */
Liste de diffusion du %(real_name)s http://www.frsag.org/