Tout a fait, tu viens de demontrer par A+B pourquoi il n'y a aucune difference entre un projet libre et un proprio : dans les 2 cas tu ne sauras jamais si c'etait une faille normale ou autre chose.
Sérieusement ? Ça fait des heures et des heures que j'explique qu'on ne sait pas voir que la faille et normale ou pas et que c'est ça la différence entre le libre et le proprio.
Prends Redhat, Ubuntu, Suse, etc... et fais des stats sur combien de code est different.
La seule possibilite de fork viable est si bcp de gens passent sur le nouveau fork.
Ajouter une faille est alors très difficile. Par exemple, on a un complice chez Redhat. Il ajoute la faille. Les types de Ubuntu, Suse, etc ... jettent régulièrement un œil sur ce qui change chez Redhat parce que s'ils améliorent quelque chose, ça le intéresse. Du coup, un ajout suspect sera dénoncé par eux, d'autant plus que cela fera une bonne pub pour eux et une mauvaise pub pour un concurrent.
(si maintenant tu n'as pas confiance en ceux qui bossent sur le noyau, c'est sans doute autre chose, mais pareil: une modification du noyau est suivie par les gens de Redhat, Ubuntu, Suse, ... qui ne cherchent pas les backdoors, mais qui cherchent à comprendre à quoi servent les modifications, et donc découvrent les backdoors)
Si je t'inseres une faille dans le kernel Linux par an, une autre dans Firefox ou KDE/Gnome, personne n'y verra rien
Si t'insères une faille dans le noyau, tu recevras des commentaires de types de chez Intel, Redhat, SystemD, ... te disant: "hé, pourquoi vous avez fait cette modification non justifiée. on doit faire du code qui marche avec le noyau, donc, on vérifie que les modifications sont compatibles avec nous, et cette modification n'a pas de sens."
Si tu l'insères dans Firefox ou KDE/Gnome, tu devras justifier ta modification. Faire une bonne backdoor qui ressemble à une faille n'est pas facile. Faire une bonne backdoor qui ressemble à une faille et qui passe inaperçu quand on regarde uniquement le bout de code modifié est encore plus dur. Fair une bonne backdoor qui ressemble à une faille et qui est une modification justifiée du code est encore plus dur.
[^] # Re: 1994
Posté par j-c_32 . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.
Sérieusement ? Ça fait des heures et des heures que j'explique qu'on ne sait pas voir que la faille et normale ou pas et que c'est ça la différence entre le libre et le proprio.
Ajouter une faille est alors très difficile. Par exemple, on a un complice chez Redhat. Il ajoute la faille. Les types de Ubuntu, Suse, etc ... jettent régulièrement un œil sur ce qui change chez Redhat parce que s'ils améliorent quelque chose, ça le intéresse. Du coup, un ajout suspect sera dénoncé par eux, d'autant plus que cela fera une bonne pub pour eux et une mauvaise pub pour un concurrent.
(si maintenant tu n'as pas confiance en ceux qui bossent sur le noyau, c'est sans doute autre chose, mais pareil: une modification du noyau est suivie par les gens de Redhat, Ubuntu, Suse, ... qui ne cherchent pas les backdoors, mais qui cherchent à comprendre à quoi servent les modifications, et donc découvrent les backdoors)
Si t'insères une faille dans le noyau, tu recevras des commentaires de types de chez Intel, Redhat, SystemD, ... te disant: "hé, pourquoi vous avez fait cette modification non justifiée. on doit faire du code qui marche avec le noyau, donc, on vérifie que les modifications sont compatibles avec nous, et cette modification n'a pas de sens."
Si tu l'insères dans Firefox ou KDE/Gnome, tu devras justifier ta modification. Faire une bonne backdoor qui ressemble à une faille n'est pas facile. Faire une bonne backdoor qui ressemble à une faille et qui passe inaperçu quand on regarde uniquement le bout de code modifié est encore plus dur. Fair une bonne backdoor qui ressemble à une faille et qui est une modification justifiée du code est encore plus dur.